137 replies to this topic

[schtrom]

Download-Link: https://sourceforge....projects/svbus/

 

 

SVBus Virtual SCSI Host Adapter for GRUB4DOS

Today we present a new virtual SCSI driver for use with GRUB4DOS named SVBus. The
driver is used like WinVBlock and FiraDisk to access GRUB4DOS mapped drives from
Windows. At the moment VHD file disk and RAM boot are supported. The supported OS
platforms are Windows 2000 up to the newest Windows 10 on x86 and x64 architectures.
For interested developers the source code is included and licensed under the GPL.

Many thanks and much respect go out to the authors of WinAoE, WinVBlock (Shao Miller),
FiraDisk (Panot Joonkhiaw), DSEFix and of course to the reboot community, which made
the VHD RAM and disk boots in Windows possible!

Greets
Kai Schtrom

[blackbalfur]

Thanks i will test this one for sure!!!

[Wonko the Sane]

Interesting.

 

Care to list which differences/features it has (as compared to Firadisk and/or Winvblock)?

 

Wonko

[erwan.l]

Very interesting to see some testings and more details around how it compares with winvblock/firadisk.

[Vortex]

Hi schtrom,

 

Thanks for your SVBus Virtual SCSI Host Adapter for Grub4dos. Here is my report.

 

Booting off  from Win7PE 32-bit :

title Windows 7

chainloader /bootmgr7

title Win7PE 32-bit

map --mem (hd0,1)/Win7PESE_x86.ISO (hd32)
map --hook
chainloader (hd32)

C:\bootmgr7 is the renamed Windows 7 boot loader.  bootmgr is the grubdos loader grldr extracted from grub4dos-0.4.5c-2016-01-18.7z  : grldr is renamed to bootmgr

 

I have a Windows 7 installation on my root partition. 

 

After attaching my VHD disk in the Win7PE environment, the installation starts like the following :

C:\Win7-32bit>sources\setup.exe /noreboot

All the setup files were copied to the root partition of my drive. Since the Windows installer overwrites the C:\boot folder and the C:\bootmgr file, I backed up them to another folder.

 

The attached VHD file Win7.vhd is associated with the drive letter F

 

Adding the SVBus driver to the Windows 

 

C:\Svbus\bin>dism /add-driver /driver:svbus.inf /image:F:\


Deployment Image Servicing and Management tool
Version: 6.1.7601.17514


Image Version: 6.1.7601.23403


Found 1 driver package(s) to install.
Installing 1 of 1 - C:\Svbus\bin\svbus.inf: The driver package was successfully
installed.
The operation completed successfully.

Creating the BCD record :

C:\Svbus\bin>bcdboot F:\Windows /s F:
Boot files successfully created.

After detaching the virtual drive F, I restored the folder C:\boot  and the file C:\bootmgr file as they were modified by setup.exe

 

Booting the Windows 7 instance stored in the VHD file :

 

title Windows 7 - FILEDISK
find --set-root --ignore-floppies /win7.vhd
map /Win7.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

Everything worked fine and the installation completed successfully. schtrom, the procedure you described in the Readme file worked too.

 

Thanks again for this nice driver.

[Vortex]

Hello,

 

A quicker setup experiment. Again, booted off from Win7PE 32-bit. I attached the virtual disk Win7.vhd using the disk management console.

 

The index number 4 represents the Professional version of Windows 7. F indicates the virtual partition F hosted by Win7.vhd

X:\Windows\System32\Tools\imagex2>imagex.exe /apply C:\Win7-32bit\sources\install.wim 4 F:

ImageX Tool for Windows
Copyright (C) Microsoft Corp. All rights reserved.
Version: 6.1.7600.16385

[ 100% ] Applying progress

Successfully applied image.

Total elapsed time: 6 min 6 sec

Creating the BCD store :

X:\Windows\System32\Tools\imagex2>bcdboot F:\Windows /s F:
Boot files successfully created.

Injecting the SVBus driver :

X:\Windows\System32\Tools\imagex2>reg LOAD Hklm\sys F:\Windows\System32\config\SYSTEM
The operation completed successfully.

X:\Windows\System32\Tools\imagex2>reg IMPORT D:\SvBus.reg
The operation completed successfully.

X:\Windows\System32\Tools\imagex2>reg unload HKLM\sys
The operation completed successfully.

C:\Svbus\bin>copy svbus.inf F:\Windows\inf
        1 file(s) copied.

C:\Svbus\bin>copy svbusx86.sys F:\Windows\System32\drivers
        1 file(s) copied.

SvBus.reg :

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\sys\ControlSet001\Control\CriticalDeviceDatabase\DETECTED#svbusx86]
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"
"DriverPackageId"="svbus.inf_x86_neutral_b29b9ca0ca57a291"
"Service"="svbusx86"

[HKEY_LOCAL_MACHINE\sys\ControlSet001\Control\CriticalDeviceDatabase\ROOT#svbusx86]
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"
"DriverPackageId"="svbus.inf_x86_neutral_b29b9ca0ca57a291"
"Service"="svbusx86"

[HKEY_LOCAL_MACHINE\sys\ControlSet001\services\svbusx86]
"DriverPackageId"="svbus.inf_x86_neutral_b29b9ca0ca57a291"
"ErrorControl"=dword:00000001
"Group"="SCSI Miniport"
"ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,00,\
  72,00,69,00,76,00,65,00,72,00,73,00,5c,00,73,00,76,00,62,00,75,00,73,00,78,\
  00,38,00,36,00,2e,00,73,00,79,00,73,00,00,00
"Start"=dword:00000000
"Type"=dword:00000001

Two registry shots before and after the driver installation with the dism command were enough to produce the .reg file above.

<First registry capture>
dism /add-driver /driver:svbus.inf /image:F:\
<Second registry capture>

Edit : Using this second method, the remark unknow device can appear in the device manager. Reinstalling the driver is solving this issue.

[schtrom]

Hi guys,

sorry I had been busy lately.

@Wonko:

I did code another virtual GRUB4DOS HDD driver, because I had some problems with WinVBlock version 0.0.1.8 and the file disk stuff. On huge virtual HDDs I get BSODs and can't even boot. This seems to be related to WinVBlock and the location of the VHD file on the disk and maybe also the size of the VHD. I normally boot Windows 10 VHD with a size of at least 20 GB to RAM. This is very good for surfing the internet. You simply reboot and all changes and potential viruses are gone. WinVBlock has also some problems on Windows 10. If you watch what is going on in the kernel debugger, you see that there are write errors on the physical HDD where the virtual disk file is stored. This is related to Microsoft which block write operations to volumes and disks in newer operating systems. SVBus uses the flag SL_FORCE_DIRECT_WRITE, which bypasses the check in file system and storage drivers. Therefore we have no write errors anymore in Windows 10. SVBus is also the first virtual driver that shows the floppy disk symbol in Windows Explorer correctly. This was done by supporting MODE PAGE FLEXIBLE DISK command. In addition I ran a lot of professional code analysis stuff like warning level W4, PreFast, PC-Lint and VS2017 code analysis. This should make the driver even more stable and reliable. I can not even rethink all of the optimizations I did to the driver in the past.

In the end I simply wanted to create my own code which should be as stable and clean as possible. I think it is always better to have more alternatives for a virtual HDD driver in case one of the drivers does not work for some users, they could simply try the other. I did a lot of tests with SVBus and worked on it for nearly a year until release. I tested every possible OS I got from Windows 2000 to Windows 10. I learned a lot during development. Because I was so amazed by the work Firadisk, WinVBlock, WinAoE and their authors did, I thought I should give back something to the community. Because of this I shared the code on sourceforge, so everyone can learn and improve it.

@Vortex:

I would like to thank you for all the testing of SVBus. Much appreciated!

 

I also did some preformance tests lately on the driver. In Windows 2003 Server this looks like the OS is on speed!

https://imgur.com/a/SuPiSt9

 

Keep up this good community!

Kai Schtrom

[Wonko the Sane]

Thanks schtrom  ,

now it is clear.

 

In a nutshell, older drivers had some issues with Windows 10 while this new one is OK with Windows 10 (while I presume being still compatible, besides 8 and 7 also with Vista, 2003, XP and even 2000, very good ).

 

And your note about SL_FORCE_DIRECT_WRITE is very interesting, as I have seen - here and there - reports of this or that old tool causing "random" write errors on 10, that could be explained by this ...

 

 

Wonko

[SoItIs]

since I was updating a w7 x86 ultimate ram image, I decided to try SVBus and it booted up with no problems here.

 

menu.lst I used:

 

title RAM W7

find --set-root /w7.img

map --mem /w7.img (hd0)

map --hook

find --set-root /bootmgr

chainloader /bootmgr

 

thanks schtrom for another great Grub4Dos tool!

Edited by SoItIs, 02 August 2018 - 08:43 PM.

[schtrom]

SVBus V1.1 Virtual SCSI Host Adapter for GRUB4DOS

Today we present the new virtual SCSI driver SVBus version 1.1 for use with GRUB4DOS. SVBus V1.0 was not working in combination with TrueCrypt V7.1a full system disk encryption. We changed the way SVBus V1.1 searches the GRUB4DOS signature string. If we can not find the GRUB4DOS signature inside the actual INT13 handler we try to search the entire 640 KB RAM area. This way we can even detect the GRUB4DOS loader if INT13 got hooked by another program.

Use the following menu.lst entries to boot the VHD file with TrueCrypt:

title Windows 10 - RAMDISK
find --set-root --ignore-floppies /win10.vhd
map --mem /win10.vhd (hd0)
map --hook
rootnoverify (hd0,0)
chainloader (hd0)+1

title Windows 10 - FILEDISK
find --set-root --ignore-floppies /win10.vhd
map /win10.vhd (hd0)
map --hook
rootnoverify (hd0,0)
chainloader (hd0)+1

 

To download the newest version use the link in my first post.

 

Greets
Kai Schtrom

[maanu]

SVBus V1.1 Virtual SCSI Host Adapter for GRUB4DOS

Today we present the new virtual SCSI driver SVBus version 1.1 for use with GRUB4DOS. SVBus V1.0 was not working in combination with TrueCrypt V7.1a full system disk encryption. We changed the way SVBus V1.1 searches the GRUB4DOS signature string. If we can not find the GRUB4DOS signature inside the actual INT13 handler we try to search the entire 640 KB RAM area. This way we can even detect the GRUB4DOS loader if INT13 got hooked by another program.

Use the following menu.lst entries to boot the VHD file with TrueCrypt:

title Windows 10 - RAMDISK
find --set-root --ignore-floppies /win10.vhd
map --mem /win10.vhd (hd0)
map --hook
rootnoverify (hd0,0)
chainloader (hd0)+1

title Windows 10 - FILEDISK
find --set-root --ignore-floppies /win10.vhd
map /win10.vhd (hd0)
map --hook
rootnoverify (hd0,0)
chainloader (hd0)+1

 

To download the newest version use the link in my first post.

 

Greets
Kai Schtrom

Thank you very much for developing a new driver for good old Grub4dos 

 

2 questions if i may.

 

1- is 64bit driver signed ?

 

2- can we boot a VHD or WIM file (Like Windows to Go ) directly from grub4dos via USB ,WITHOUT adding the SVBus driver first to the windows , and instead loading it as separate floppy disk image, like we used to boot RAM BASED WINXP IMG from USB, by first loading WINVBLOCK IMG into memory ?

 

something like we used to do , while installing windows xp from iso ,directly via USB, by first loading winvblock , ( of course grub4dos being the loader) .

 

 

Regards

Maanu

 

 

Thanks i will test this one for sure!!!

 good to see you here my old friend!!!

[L A M A]

I don't expect drivers to be signed but the way TrueCrypt is possible, I'm hoping for a possibility to monitor MemDisk changes and save changes to .VHD itself or save some "SavedChange01.lz4" (all by SVBus drv?)
?? something that could be added to grub4dos menu.lst??? that can overwrite and remap only changes????

 

Img_xp_update maybe doing great job of saving changes but when it comes to making experimental changes, its very annoying to clone (or decompress .vhd.lz4) then save changes to VHD and test it. After this, if the change is unacceptable, the whole VHD gets flushed.

[misty]

I managed to get my hands on a Lenovo Thinkpad W530 on Wednesday evening - with a whopping 32GB of RAM.

I'm not a stranger to RAM booting, having previously used Firadisk and WinVBlock to boot a full Windows XP and various flatboot WinPE versions from RAM. Hardware limitations (in regards to RAM) have stopped me experimenting with a full Windows 7/8/10 RAM boot - that and me not having the required technical knowledge to trim Windows 7/8/10 enough to fit in a disk image that I could boot on the hardware I had access to.

My new system has enough RAM to allow me to experiment with a full Windows 7 and Windows 10 from RAM, using SVBus - what fortuitous timing!

@schtrom
Very. Nice. Work.

I no longer use setup.exe to install Windows - a combination of wimlib-imagex apply and bcdboot is my preferred method. I vaguely recall issues with setup refusing to continue with the installation if the target partition/VHD does not meet a minimum size requirement. I can't recall what this minimum size is, however experimentation may be useful - and then updating the Readme in the SVBus download.

I deviated from some of your instructions and used a custom WinPE (to avoid shameless self promotion I will not name this build) and wimlib-imagex to complete some tasks, following by bcdboot to create the boot files, and bcdedit to edit the resulting BCD store. Tip - run the following command to automatically display advanced boot menu options (usedful when installing the unsigned SVBus driver) -

bcdedit /store C:\boot\BCD /set {default} advancedoptions yes

My system used a small FAT formatted boot partition - on my system/setup renaming grldr as bootmgr failed to boot grub4dos. This is a known limitation when attempting to boot grldr using this renaming trick on a FAT filesystem.

As an alternative, I manually added a boot.ini file with entries for Grub4dos to my FAT (boot) partition - this was automatically parsed by the Windows 7 boot manager (bootmgr) and I was able to successfully boot grub4dos without modifying the BCD store.

Contents of boot.ini

[boot loader]
default=C:\grldr
[operating systems]
C:\grldr="Grub4Dos"

Using bootmgr from Windows 10 source (1607 and 1709 versions were tested) - boot.ini was not parsed and it was not possible to use this method.

Using bootmgr from Windows 8.1 source - boot.ini was parsed and an entry for Grub4Dos was availble in the Windows boot menu.

Using bootmgr from Windows 7 (SP1) source - boot.ini was parsed and an entry for Grub4Dos was availble in the Windows boot menu.

Adding an entry for grldr.mbr to the BCD store should work in all versions.

A tip on disabling hibernation - edit the following registry key after Windows has installed and prior to running from a RAM disk -
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power - edit the HibernateEnabled entry and change the value/data to 0.

Or alternatively, mount the registry hive whilst the system is offline and edit the same value in the SYSTEM hive, ControlSet001\Control\Power key.

Great work schtrom - thank you very much for this very nice addition to the world of "...virtual SCSI driver for use with GRUB4DOS...". I've been increasingly using UEFI systems in pure UEFI mode - this release has prompted booting in compatibility mode and a welcome return to Grub4dos. It felt like visiting a long lost friend!



Misty

[misty]

BTW, I haven't done any real benchmarks, however running 64-bit Windows 7 (SP1) from a RAM disk and also copying a 4GB file from my internal SSD to the RAM disk were subjectively very fast/responsive. Real world speed for copying the 4GB file was around 500MB per second. Awesome!!!!!

Any thoughts on running the pagefile on the RAM disk? I'm talking here about a small pagefile as some programs may not function without one.

Adding the pagefile to the RAM disk could result in a fully sanitized system on every boot - I'm thinking Windows to go from a ramdisk with no trace left on the host system - using the forensic registry settings.

Misty

[antonino61]

I have just tried it! Works like a charm in pre-ramloading and in native booting. the driver installation process is much much less laborious and the booting is a little faster than it was the case with firadisk, also thanks to the wonderful tutorial provided above. I could not get filedisk booting to work though - inaccessible boot device - i did not follow all the procedures in the tutorial thereof out of laziness. but i can do fine with native booting. if there is just a little thing missing in the filedisk booting and the filedisk booting is so much faster as to make it worthwhile my righting it, pls let me know what i gotta do. 

Edited by antonino61, 24 November 2018 - 12:27 AM.

[tinybit]

My system used a small FAT formatted boot partition - on my system/setup renaming grldr as bootmgr failed to boot grub4dos. This is a known limitation when attempting to boot grldr using this renaming trick on a FAT filesystem.

 

 

Windows NTFS and FAT32 boot record code could load the whole bootmgr file.  The FAT12/16 boot code only load the first sector of bootmgr. So if you use FAT32, you should not encounter failure.

[misty]

...My system used a small FAT formatted boot partition - on my system/setup renaming grldr as bootmgr failed to boot grub4dos. This is a known limitation when attempting to boot grldr using this renaming trick on a FAT filesystem....

Windows NTFS and FAT32 boot record code could load the whole bootmgr file. The FAT12/16 boot code only load the first sector of bootmgr. So if you use FAT32, you should not encounter failure.

@tinybit
Thanks for the response and clarification. Unfortunately, I'm a bit lazy. The boot.ini workaround saved the need to reformat my boot partition.

When I mentioned "a known limitation" I was referring to some of your other posts including -

why it doesn't like FAT16?

Because the MS NTLDR boot sector of an FAT12/16 partition only loads one sector, i.e., the first sector of the NTLDR file. If this NTLDR was our GRLDR, then this will fail to boot. On the other hand, the MS NTLDR boot sector of an FAT32/NTFS partition will load the whole NTLDR file into memory, and thus our GRLDR(renamed to NTLDR) can boot OK.

Grub4dos is my favourite all time boot loader/manager. Thanks as always for all of the time and effort you put into Grub4dos. And also the support you continue to provide in this forum. Outstanding work.



Misty

[tinybit]

@Misty

 

Thank you very much. Thanks, schtrom. Thanks everyone.

 

 

 

Yamingw (a member of bbs.wuyou.net) said, use a tool at github to modify system file, and then you will be able to use unsigned drivers.  The tool is here:

 

https://github.com/h...PGDSED/tree/dev

 

 

 

Should anyone be interested, Yamingw also gives a signed 64-bit SVBus driver on this page:

 

http://bbs.wuyou.net...a=page=1&page=2

 

The file name is svbus.zip.

 

I also attach it here. Note:  Original date was 2018-11-11 when yamingw uploaded it at bbs.wuyou.net.

Attached Files

•  svbus.zip   17.47KB   1708 downloads

[antonino61]

I have eventually managed to boot it from filedisk ok as well, apparently by deleting the no verify (second last) line from menu.lst. 

[Wonko the Sane]

I have eventually managed to boot it from filedisk ok as well, apparently by deleting the no verify (second last) line from menu.lst. 

Yes and NO.

Meaning that if you deleted that, you chainloaded the BOOTMGR external to the VHD (and not the one in the VHD for which the entry was made for):

title Windows 10 - FILEDISK
  find --set-root --ignore-floppies /win10.vhd
  map /win10.vhd (hd0)
  map --hook
  rootnoverify (hd0,0)
  chainloader /bootmgr

Wonko

[antonino61]

thank you ever so much, wonko. you were dead right! my initial inability to boot from filedisk was probably due to an apparently overlapping pair of commands, namely rootnoverify (hd0,0) and root (hd0,0), as I had added the former without deleting the latter. now that I have deleted it, rootnoverify (hd0,0) works fine. Previously it gave me the inaccessible-boot-device error. are my previous failure and present success both consistent with what I am reporting? now it boots fine with the menu.lst entry you have posted.

so thanks in advance, as I am always keen on getting your precious feedback.

[tinybit]

thank you ever so much, wonko. you were dead right! my initial inability to boot from filedisk was probably due to an apparently overlapping pair of commands, namely rootnoverify (hd0,0) and root (hd0,0), as I had added the former without deleting the latter. now that I have deleted it, rootnoverify (hd0,0) works fine. Previously it gave me the inaccessible-boot-device error. are my previous failure and present success both consistent with what I am reporting? now it boots fine with the menu.lst entry you have posted.

so thanks in advance, as I am always keen on getting your precious feedback.

 

No, no.....

 

root (hd0,0) and rootnoverify (hd0,0) both offer the same functionality. The difference is that root (hd0,0) will confirm/ensure the existence and availability of (hd0,0), whereas rootnoverify (hd0,0) will directly set (hd0,0) as root no matter whether or not it exists.

 

You said root (hd0,0) failed. That means (hd0,0) does not exist, or it is not accessible.

 

If your VHD has no MBR (partition table), it would be the case. And thus you might want to use root (hd0) instead.

 

If the correct partition is, for example, (hd0,1), then you should use root (hd0,1).

 

 

[Wonko the Sane]

The whole point (that I usually fail to convince people of) is that one should NEVER use a pre-made menu.lst when experimenting, BUT rather use the command line to send commands one by one (this way one can see which error - if any - or other feedback grub4dos produces).

Once the manual commands have success, then (and only then) putting them in a menu.lst entry is a convenient way to make it repeatable.

More generally the rule of thumb is that whenever a "root" needs to be established, one should always try first the "root" command (that attempts to parse the target and provides feedback) whilst the "rootnoverify" should be only used in a few selected cases where it is actually needed.


Wonko

[antonino61]

sorry, wonko, I said that rootnoverify (hd0,0) had initially failed in conjunction with root (hd0,0), in the following fashion:

 

title Windows 10 - FILEDISK
find --set-root --ignore-floppies /win10.vhd
map /win10.vhd (hd0)
map --hook
rootnoverify (hd0,0)

root (hd0,0)
chainloader /bootmgr

 

both this

 

title Windows 10 - FILEDISK

find --set-root --ignore-floppies /win10.vhd
map /win10.vhd (hd0)
map --hook
rootnoverify (hd0,0)
chainloader /bootmgr

 

and this

 

title Windows 10 - FILEDISK

find --set-root --ignore-floppies /win10.vhd
map /win10.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

 

have never failed!

 

I have always had my vhd with mbr as C: on what appears as D: but it is in fact the physical c: (first hdd)

 

a couple of days ago I replaced firadisk with svbus in order to try it out and followed the instructions whereby one should rename grldr as bootmgr and the real boot manager as bootmgr10 on the host drive (the physical c: which is OS-wise d:), test ramdisk and filedisk and then if both work delete boot dir and bootmgr10 from the host drive. in the vhd, boot dir and bootmgr have always been left as they were before. Have I been any clearer now? I am at pains trying to make out the (hd0) and (hd0,1) scenarios, so I do not know if they apply to me. I have only one partition and 2 VHDs on the host drive. Would either apply? 

Edited by antonino61, 26 November 2018 - 09:48 AM.

[Wonko the Sane]

Have I been any clearer now? I am at pains trying to make out the (hd0) and (hd0,1) scenarios, so I do not know if they apply to me. I have only one partition and 2 VHDs on the host drive. Would either apply?

Unforunately, everything ws clear BEFORE you posted the "explanation", now it has become - to say the least - murky.
 

I am at pains trying to make out the (hd0) and (hd0,1) scenarios, so I do not know if they apply to me. I have only one partition and 2 VHDs on the host drive. Would either apply?

I really cannot understand what (the heck) you are talking about.
After these commands are executed:
map /win10.vhd (hd0)
map --hook
the VHD is (to all practical effects) hd0 (or first hard disk).
The first line maps the VHD to hd0, the seconds "hooks" (or if you prefer makes the previous mapping effective/persistent).

What is inside the VHD may be either a first partition or volume inside it (i.e. hd0,0) or a second partition/volume inside it (i.e. hd0,1), etc. it only depends on the contents.

You seem to be confusing (don't worry, most people do the same at all times) partition/volumes with hard disks.

It DOES NOT exist something like "physical C:", C: is logical only, and it is a drive letter assigned to a volume or partition.

It exists \\.\PhysicalDrive0 (first disk or hd0) and \\.\C: or C: (usually, but not necessarily, first partition on first physical disk, i.e. hd0,0)


Wonko