10 replies to this topic

[alacran]

File Name: SVBus_V1.2 signed
File Submitter: alacran
File Submitted: 12 Dec 2020
File Updated: 17 Jan 2021
File Category: Boot tools

On the picture you can see a Mini-10x64 VHD of a minimum size running on Ram, the info to create your own is on this topic: http://reboot.pro/in...showtopic=22383
There is also a tool made by our fellow wimb to automate and make all the process in a couple of minutes, a link for it is available on same topic.

This filter driver is used to let us boot Win OSs from Ram (on MBR/CSM and UEFI) by means on grub4dos and fthe new grub4dos for UEFI usually it works fine from Vista to 10 but there are some reports about it can be installed also on the good old XP.

It has same funcionality as WinVBlock by Shao Miller and Firadisk by karionix filter drivers, that do not work fine on Win 10.
This is a signed version of SVBus driver developed by schtrom.

His topic on the forum is: http://reboot.pro/in...showtopic=21787

And this is the driver page on Sourceforge.net:https://sourceforge....projects/svbus/
I'm only uploading it here to keep it handy if a signed version is required.

Our fellow a1ve was very kind in share this signed version with us: http://reboot.pro/in...e=5#entry217253

Password is: reboot.pro

NOTE: I want to let you know Avast AV made a big fuss, when I extracted it, as same tools and procedure used to sign it, is often used on some malware programs to also sign them, so if you want to use it, I suggest to dissable your AV when extracting and installing it, and create an exception on your AV for svbusx86.sys and/or svbusx64.sys files as required.

If you want to make any comment about this download, please go to: http://reboot.pro/in...showtopic=22422

Download link is not working fine, please use this link to wimb's repository on github: https://github.com/w...-signed_2-E.zip
alacran

Click here to download this file

[AnonVendetta]

The last link doesnt work....."The requested URL was not found on this server".

 

Is the file you're providing 100% identical (completely unmodified) to what is provided on  Schtrom's SourceForge page?

[AnonVendetta]

Ignore, I got it installed. Just had to temp disable driver signature enforcement, install driver, reboot. The driver stays loaded even when DSE is enabled and testsigning is disabled. Eventually, I'll get around to my first ever run of W10 in a ram disk. My next step is to clone my C drive into a VHD and try to get Grub4DOS/SVBus to boot that.

[Wonko the Sane]

The file is ok, the issue is the new board not being yet "tuned" with the same (BTW stupid) approach used till now (but not always, in spots).

 

See:

http://reboot.pro/in...showtopic=22430

 

The link working right now is:

http://reboot.pro/in...ds&showfile=625

 

i.e. generically:

hxxp://reboot.pro/index.php?app=downloads&showfile=<file #>

 

Wonko

[AnonVendetta]

i noticed there is an extra .reg file in the signed archive. Schtrom's original SVBus 1.2 archive doesnt have this. I've already integrated the signed driver with dism. I've also integrated Samsung's NVMe driver, obtained from the win-raid forum. Now I just need to know whether I also need to mount my custom install.wim and import the reg file into the offline Registry.

[alacran]

From: http://reboot.pro/in...e=4#entry217631

 

Update USB_FORMAT-54 and UEFI_MULTI-54 plus Addons and VHD_WIMBOOT-49

 

Download:  from wimb GitHub  -   USB_FORMAT-54 and UEFI_MULTI-54 and VHD_WIMBOOT-49

 

Manual:  VHD_WIMBOOT.pdf - Download File E = Encrypted Password = bootwimb 

 

- Update UEFI Grub4dos - G4E

- Update UEFI Grub2 and Grub2 FileManager

 

- Always Shut-Off AntVirus Software and Disable Windows Defender when working with signed SVBus driver

 

Follow instructions on VHD_WIMBOOT.pdf file

 

alacran

[AnonVendetta]

@Alacran: Too late, I've already integrated the .reg file. And confirmed its' existence in the installed OS's Registry. It doesn't seem to have helped or hurt anything. And unlike the driver from the SVBus SourceForge page, your version appears as signed in Device Management. But the unsigned driver loaded fine too after integration.

I will probably RAMload a VHD file, but at first I won't be using wimboot. Just SVBus signed/Samsung NVMe drivers integrated, Grub4DOS (uncertain whether i should use regular/official G4D or the NVMe/AHCI speed patched version), and a VHD.

[alacran]

NVMe/AHCI speed patch is valid only for grub4dos 0.45c old version, which is only MBR bootable and not UEFI capable, and also not capable to boot non contiguous files.

 

The VHD_WIMBOOT program by wimb lets you make Wimboot mode, Compact mode or Normal installations.

 

alacran

[AnonVendetta]

@alacran: That's fine, I'll only be booting in legacy/CSM mode anyway. I suppose the only way to find out which G4D is best for me, is to try both and see which one loads faster. I'll start with regular G4D, then try the AHCI/NVMe speed patch version. However, I'm of the opinion that the only difference should be in the booting time, once the VHD is loaded from the NVMe drive into RAM then they should run at the same speed. Correct?

How do you make a VHD file contiguous?

[antonino61]

@Vendetta

yes, with only one caveat - svbus and, for that matter, firadisk, as filedisks, feature 1-second-longer booting times than ordinary bootmgr. as ramdisks, there is no way of, or no point in, comparing, as u cannot do without svbus or firadisk anyway. I did sorta report this a few years ago, when I found that out, maybe to spur some intention or other to look into bootmgr better or to see what could be done to make svbus or firadisk "quicker", and the replies I got are of the following fashions:

1) Microsoft mysteries;

2) nothing doing from the end of the preramloading (when it is the case) stage onwards;

3) no reply at all.

[alacran]

@alacran: That's fine, I'll only be booting in legacy/CSM mode anyway. I suppose the only way to find out which G4D is best for me, is to try both and see which one loads faster. I'll start with regular G4D, then try the AHCI/NVMe speed patch version. However, I'm of the opinion that the only difference should be in the booting time, once the VHD is loaded from the NVMe drive into RAM then they should run at the same speed. Correct?

How do you make a VHD file contiguous?

 

Yes, the difference will be only the time required to load to Ram the VHD.

Yes, once loaded to Ram then all will be done on Ram, and only limited by SVBus driver speed, with the only exception of Wimboot mode installation, where there is still the need to read info from the linked WIM file located on a drive outside of the VHD.

 

If a VHD file is created as fixed size, it will be contiguous, but if it is created expandable, very possible it will not be contiguous, to make it contiguous we can use Wincontig and/or Defraggler and defragment the VHD file if required, of course it is also a good practice to also defragment the content of the VHD when booting from it or when attached.

 

grub4dos 0.46a for MBR works very fine on fixed size or expandable VHDs, it is said it theoretically supports to work with a file with upto 64 fragments, but other people say in real life the limit is 32 fragments.

 

Expandable VHDs load faster on Ram than fixed size VHDs.

 

lz4 compressor     (Valid for grub4dos 0.46a for MBR and grub4dos for UEFI) lz4 compressed VHDs load faster on Ram than expandable VHDs, but this only apply to fixed size VHDs, expandable VHDs lz4 compressed DO NOT boot.

 

 

alacran