137 replies to this topic

[Blackcrack]

Misty, a lil/couple question/s

it is possible to make a program, who can put g4d in CDRom(folder) as iso and/or "install"
to USB-Stick with a emty "isos" folder, where it is possible to put different iso's in this folder
where make it possible to read in the ./isos folder and list this iso's in a bootmenu
and starts via svbus-host-adapter as live-cd ..
like linux.iso's or WinNT.iso and PE's in this single folder.

if there a folder with iso's as example ./boot-menu-isos/* take this folder and create a bootable iso from it..
i think on a Administration-tool DVD/blueray/USB-Stick with different iso's for a DVD or blueray or something
on a USB-Stick do i think on minisd's (with 64-128 or more Gig)
where be supported by USB-Stick
https://images-na.ss...mTL._SY355_.jpg
or
https://i.ebayimg.co...GfOx/s-l225.jpg

where it is really easy possible to have a huge usb.. therewith also the possible to have many iso's
on it where it is possible to "catch" and boot so creating a Application who make :

[ ]add/install G4D to the usb-stick and make it possible to boot to the Menu
[ ]create a bootmenu via array out from the ./isos by booting (menu-generating/creating by starting of G4D)
[ ]start the iso via svbus-vsha via selecting and starting the readed Iso-Filename (press enter)

as single exe..
is that interesting for you ?

best regards
Blacky

[misty]

@Blackcrack
I'm not sure if I have understood correctly.

If you are asking me if I am able to create an application/executable to complete the tasks in your post then the answer is most definitely no. Please do not be fooled by my Developer status - I'm no programmer.

The scope of your suggestions is huge. Let's take the autocreation of a grub4dos bootmenu from a range of .iso files copied to the proposed ./isos folder - which grub4dos settings are required? Different .iso files will likely require different grub4dos settings. Even using RTM windows builds, Windows NT5 and Windows NT6 are significantly different and require a completely different approach if trying to install Windows from a Grub4dos mapped .iso using SVBus. Generating a boot menu on the fly based on .iso files that are likely to have random names is a recipe for disaster.

Your post also mentioned linux.iso's - this has no relevance to SVBus.

Sorry if I have misunderstood any of your points.

One last comment - I prefer manual approaches to creating multiboot systems (including multiboot USB drives) as this helps me to understand the steps involved and helps to develop my skills and knowledge.

Regards,

Misty

[Wonko the Sane]

...."install"
to USB-Stick with a emty "isos" folder, where it is possible to put different iso's in this folder
where make it possible to read in the ./isos folder and list this iso's in a bootmenu
and starts via svbus-host-adapter as live-cd ..
like linux.iso's or WinNT.iso and PE's in this single folder..

You just described Easy2boot:

http://www.easy2boot.com/

by our friend Steve6375

 

SVBUS is a (Windows NT) virtual disk driver (with a particular capability to "hook" grub4dos mapped images), it is NOT a "host adapter" and it will ONLY work on Windows NT family OS's and PE's.

 

Wonko

[Blackcrack]

misty, on 20 Jul 2019 - 12:08 PM, said:
Your post also mentioned linux.iso's - this has no relevance to SVBus.

ah okey, was only a idea burb belch *s*


Wonko, it supports not to read out the name of the iso's via array and
not a folder where you can place easy a couples of iso's where should be able to boot..

but well.. was only a burb belch..

best regards
Blacky

edit: uppss not burb.. a belch, have confused the words, sorry..

[Wonko the Sane]

ah okey, was only a idea burb *s*


Wonko, it supports not to read out the name of the iso's via array and
not a folder where you can place easy a couples of iso's where should be able to boot..

but well.. was only a burb..

best regards
Blacky

You keep using that word

https://www.thefreedictionary.com/burb

 

 

 

burb   (bûrb)

n. Informal

A suburb.

[Short for suburb.]

 

 

Wonko

[Blackcrack]

thy for hint Wonko, have confused the words ..

 

it's easily to hot today ..

[Wonko the Sane]

thy for hint Wonko, have confused the words ..

 

it's easily to hot today ..

Yep, still not hot enough to cause an eruption :  

https://www.dictiona...om/browse/belch

 

Seriously, I don't think you can use "belch" the way you used (I mean without putting a hand before your mouth ), you probably meant more like burst or outburst?

 

https://www.dreamsti...d-image28514472

 

Wonko

[steve6375]

hiccup or brain fart?

[Wonko the Sane]

hiccup or brain fart?

No, hiccup or brain fart have a negative meaning,  what BlackCrack was trying to say is - I believe - that he had a sudden inspiration/intuition and spoke/wrote about it on the spur of the moment, without analyzing it/thinking about it much.

 

Wonko

[Wonko the Sane]

This is not syntatically correct (besides making little sense generally):

chainloader hd0,SVBusBoot.img

 

should be:

chainloader (hd0)+1

 

Breakout:

 

find --set-root /SVBusBoot.img <- find image files SVBusBoot.img in the root directory of *any* device and establish current root to it
map /SVBusBoot.img (hd0) <- map the (relative to the current root path) image to device hd0 (first hard disk)
map --hook <- hook, i.e. make it "definitive" the new mapping above, from now on device hd0 is SVBusBoot.img (to be more exact the whole contents of /SVBusBoot.img are now accessible as device hd0)
rootnoverify (hd0,0) <- establish root (without any verification) to the first volume of (hd0): this makes nothing useful

 

chainloader (hd0)+1 <- continue booting the first sector of (hd0), i.e. its MBR, i.e. the MBR of the SVBusBoot.img image (mapped to hd0)

 

As always it is strongly NOT suggested to pre-make a menu.lst entry, this should be done only after having tried succesfully the intended sequence of commands on the command line.

 

The last two lines:

 

rootnoverify (hd0,0)

chainloader (hd0)+1

 

Should actually be:

rootnoverify (hd0)

chainloader +1

 

And most probably a single line:

chainloader (hd0)+1

would do as well.

 

Wonko

[Wonko the Sane]

The blinking cursor is typically the result of either:

1) bad code in the MBR or in the PBR

2) bad offset to the PBR

3) bad geometry of the device (IF CHS access is used)[1]

4) mismatched geomety in the PBR [1]

 

But in the case of your particular setup it may well be due to other reasons, no idea on how actually the BestCrypt code in the MBR works.

 

If I were you, since you had a USB stick that is working, I would try making an image of the stick "as is" and use that as "SVBusBoot.img".

 

Or anyway make a test with a "big enough" image, i.e. one larger than 1024*255*63*512=8422686720 bytes, and see what happens.

 

If the large image works then the issue is connected with CHS (items #3 or #4 in the above list).

 

Wonko

 

[1] most BIOSes will assume a given geometry as a function of the size of the (virtual) device, very small devices will likely be mapped with 16/63 geometries or in some cases even "smaller" ones.

[Wonko the Sane]

@Wonko: Did you read my 2 prior posts? I already did make an img of my flash drive with RMPrepUSB. Are you saying that i will need to use an unnecessarily large img to get this to work?

Yes, for testing only purposes.

 

An image that exceeds the upper limit of the CHS addressing will be accessed by the BIOS as having a 255/63 HS geometry (which is the default geometry since XP and  that most probably was used when your USB stick has been formatted and the Bestcrypt MBR installed to) and LBA access will be used.

 

If that is the issue, then we will later find a way to reduce the size of the image.

 

Wonko

[steve6375]

maybe try the smaller .img and use

 

map --heads=255 --sectors-per-track=63 /SVBusBoot.img (hd3)

 

??

 

You did make the smaller images using  start=0 and length=P1 ?

[Wonko the Sane]

From what I can see in the disk manager screenshot you posted the issue is not SVBUS, but rather BestCrypt.

 

I mean the SVBUS:

1) mounted the device just fine
2) passed it to the mount manager (that gave it the S: drive letter) just fine

3) the disk manager sees it just fine (Healthy, System, Active)

 

but if the volume is encrypted (and for some reasons Bestcrypt doesn't hook it and decrypts it automatically) the result is RAW.

 

Maybe (no idea if this is actually possible) Bestcrypt has a manual command to forcefully "hook" and decrypt a volume?

 

Or maybe (just like BIOS) it expects a different CHS geometry for smaller volumes?

 

Right now, with the "--heads=255 --sectors-per-track=63" you are "forcing" grub4dos to mount the image with that geometry, and SVBUS should hook it with that geometry (or maybe geometry is not relevant for it ) but that doesn't mean that another program expects the "right" geometry for the actual image size.

 

Is the PBR BPB actually encrypted by Bestcrypt?

 

Wonko 

[Wonko the Sane]

The (possible) issue with geometry, at least at BIOS level is (would be ) not linked to the size of the volume but to the size of the device (the whole thing).

 

I.e. if you make an image of the whole USB stick when there is only the 1 GB volume in it (but the image remains some 8 GB in size) it should behave the same as when you had a larger 8 GB volume (and image).

 

What is "strange" is that once the thingie has booted the CHS geometry should be irrelevant, as *anything* in NT should be accessed via LBA.

 

It is possible that for some reasons CHS address and LBA don't match?

 

I doubt it, but if the volume PBR is not encrypted, post a copy of the PBR (only first sector is needed) and of the MBR.

 

Anyway if the issue is with the geometry, instead of forcing grub4dos to use the 255/63 one, the solution would be to correct the geometry to what the *whatever* is appropriate (16/63 will be too little, maybe 128/63? )

 

What is the exact message about CHS that you get in grub4dos (without using the heads/sectors parameters)?

 

 

Wonko