Jump to content











Photo
- - - - -

Windows To Go 8.1 on ‘Removable’ Easy2Boot Drive BOTH MBR ‘&’ UEFI ‘Possible’


  • Please log in to reply
33 replies to this topic

#1 Noer5

Noer5

    Member

  • Members
  • 34 posts
  •  
    Tahiti

Posted 21 January 2015 - 12:31 AM

WinToGo 8.1 working on a ‘Removable’ Easy2Boot USB Drive -- VHD within a imgPTN file.
Stick has a FAT32 PTN1 (for my boot loaders) and a large NTFS PTN2 (for e2b, ISOs & imgPTN files).

Has anyone been able to get a WinToGo 8.1 stick so that it will boot on BOTH MBR ‘&’ UEFI hardware?

My current Win81TG.imgPTN file was built on NTFS (>4GB), but if I understand correctly,

it would need to have been built on FAT32 to boot on UEFI hardware.  Is this correct?
Would love to keep using this Win81TG.imgPTN file if possible.

Thanks



#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 7284 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 21 January 2015 - 12:46 AM

Windows can only see the first partition on a removable USB drive.

There are some 'notes' at the bottom of the Tutorial http://www.rmprepusb.com/tutorials/129

but I have not tried it and am not at all sure it will work.

The BCD would have to be on the FAT32 partition and reference the VHD file on the (invisible) NTFS partition...???

 

You could try a 64-bit WinToGo on a single NTFS .imgPTN file and use Clover to boot from it. If you want Clover 32-bit support, you would have to add the clover 32-bit efi file + 32-bit drivers.



#3 Noer5

Noer5

    Member

  • Members
  • 34 posts
  •  
    Tahiti

Posted 21 January 2015 - 05:23 PM

Thanks Steve,
Would it make any difference to inject a filter driver into the WinToGo system?
Or could I make an image of my FAT32 PTN1 (in top post),

name that image “WinToGo81” (no extension),

and place it next to the WinToGo81.imgPTN file in my NTFS PTN2 (top post, while in E2B normal mode)?
 


Edited by Noer5, 21 January 2015 - 05:27 PM.


#4 steve6375

steve6375

    Platinum Member

  • Developer
  • 7284 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 21 January 2015 - 05:31 PM

not sure a filter driver would work, the drivers will be inside the VHD won't they?

 

You can try having a FAT32+NTFS arrangement with 

 

ptn 1: NTFS with VHD   .imgptn

ptn 3: FAT32 with BCD+bootmgr  (no file extension)

 

You may need a special menu to chainload to ptn 3 (hd0,2).

You will need to swap partitions over to get ptn3 as the first partition, check the BCD, save it and then make ptn1 the first ptn again, before testing.



#5 Noer5

Noer5

    Member

  • Members
  • 34 posts
  •  
    Tahiti

Posted 29 January 2015 - 11:21 PM

I have not yet tried doing any of the filter driver options.
Still trying to create 2 partitions – on UFD -- that WTG has access to.
On last try, did not add any files to the second partition image file – just what was added by dragging Empty folder onto ‘MakePartImage.cmd’ in the "MPI_Tool_Pack_Plus_CloverLite_041” folder.

So have these in MAINMENU folder:
WTG81u3.imgPTN
WTG81u3

WTG81u3.imgPTN boots fine to WTG and there is another partition created (not lettered) on the UFD, but get instant blue screen when use BOOTICE to make this new partition accessible.
Thus since windows only sees one partition on a UFD, the partition with the VHD that WTG was booted from becomes invisible to WTG.
WTG becomes invisible to itself.

Is there a way to make this new partition accessible from WTG?
Or back to needing a filter driver?

I do get this message at the end of the MakePartImage.cmd process:

INFORMATION: LABEL occurs in .LST files
UUID          should use 0CC0-EA7D
CDLABEL       should be  LABEL
LABEL         should use V
'media=cdrom' should be 'media=usb'

AUTO-CORRECT these? ([Y]/N) : y

Thanks



#6 Akeo

Akeo

    Frequent Member

  • Developer
  • 344 posts
  •  
    Ireland

Posted 05 February 2015 - 11:44 PM

Has anyone been able to get a WinToGo 8.1 stick so that it will boot on BOTH MBR ‘&’ UEFI hardware?


Not sure if this will fit what you're looking for, but the upcoming version of Rufus (ALPHA here) will happily create a dual BIOS and UEFI Windows To Go bootable UFD, even from an ISO that may contain a >4GB file, as long as you select "MBR for BIOS or UEFI computer" and NTFS in the options.

The UFD should then seamlessly boot Windows To Go in either UEFI or BIOS mode.

 

Rufus accomplishes this by applying the Windows To Go image on an NTFS partition, and then adding a 128KB ESP at the very end (UEFI specs mandate that UEFI compliant systems should handle an ESP anywhere, not just only as the first partition) that contains an NTFS UEFI driver as well as a custom EFI bootloader (only x86_64 for now, I may add x86_32 or even ARM if there is demand for it) that automatically:

  • loads the embedded NTFS driver
  • locates the bootx64.efi bootloader on the NTFS partition
  • launches it.

And since the first NTFS partition is also set for bootmgr boot, you then end up with a dual bootable Windows To Go drive.

Oh and this is applied for both REMOVABLE and FIXED drives, though I have yet to see success booting Windows To Go on anything but FIXED...

 

I have done some limited testing, and it seems to work OK, but I wouldn't mind some more people checking it out if interested.

 

One thing I should mention however is that you need Windows 8 or later to be able to access the Windows To Go option in Rufus.


  • devdevadev likes this

#7 devdevadev

devdevadev

    Silver Member

  • Advanced user
  • 504 posts
  •  
    India

Posted 06 February 2015 - 03:56 AM

Hi 'Akeo'

 

First million of thanks for adding 'WTG' feature in your awesome 'Rufus-2.0.0_ALPHA'. But I want a little bit more feature from Rufus...

 

Actually I prefer to create 'WTG + VHD' combination by using WinNTSetup because WTG81U3 is not possible without VHD. I have to use VHD partition as Installation Drive and NTFS Partition as Boot Drive. So Can I expect following feature in upcoming Rufus ?

 

Currently your Rufus format all Partition in the Removable/Fixed USB Drive which I don't like too much. I think there should be individual options for choosing Boot Drive and Installation Drive for Fixed USB Drives if we choose WTG option. So that we can use any NTFS/FAT32 Partition for Boot Drive and any other NTFS Partition/VHD Partition for Installation Drive. And then add then add a 128KB ESP at the very end that contains an NTFS UEFI driver as well as a custom EFI bootloader.

 

If It is not possible to add a 128KB ESP at the very end of already multi-partitioned USB Drive then you can provide us an advanced options for 'WTG' option  to create Multiple-Partitions in the USB Drive and can adjust ESP Partition at the very end during Multi-Partitioning of USB Drive. You can provide Multi-Partition option similar to BOOTICE.

 

I think If upcoming Rufus would allow us to create Multi-Partition based WTG by adding 'WinNTSetup' and 'BOOTICE' required features then it will be better.......AM I WRONG ?

 

What you think about it........If possible then please add above described features in upcoming Rufus....

 

Please also add x86_32 (ntfs_x32.efi driver) and even ARM along with x86_64 in Rufus ESP Partition.

 

Queries-

 

1- What if I create ESP Partition at the very end of Removable USB Drive manually by using any tool and then add files of your ESP Partition within it.......Will It also boot 'WTG' in Pure Secure UEFI mode similar to your Rufus method ?

 

2- Is it necessary to keep ESP Partition at the very end of USB Drive ? Can I not use PTN3 of my USB Drive as 'ESP' PTN ?

 

3- Suppose I have a Fixed USB Drive and then I will create three partition as follows with the help of BOOTICE and then use 'WinNTSetup' in order to create WTG+VHD combination within NTFS PTN2 and then will add 'EFI' folder of your ESP Partition within my 128 KB small FAT12 PTN3 as follows -

 

PTN1 - FAT32  -  5 GB   - DATA Partition - For Storage Purpose
PTN2 - NTFS   - 50 GB   - WTG + VHD
PTN3 - FAT12 - 128 KB  - ESP Partition - containing only an NTFS EFI driver and the UEFI:TOGO EFI bootloader.

Will all UEFI machines ignore first FAT32 partition and second NTFS partition in above configuration and will execute UEFI:TOGO bootloader within from the third small FAT12 ESP Partition in UEFI mode So that UEFI:TOGO loads an NTFS EFI driver that exists on the FAT12 PTN3, opens the NTFS PTN2 and hands over to the Windows To Go EFI bootloader that resides there. 
? Is it possible according to your theory ?

 

Thanks in Advance

 

Regards....



#8 devdevadev

devdevadev

    Silver Member

  • Advanced user
  • 504 posts
  •  
    India

Posted 06 February 2015 - 05:31 AM

Hi 'Akeo'

 

I have used 'Windows10_TechnicalPreview_x32_EN-US_9926' in order to create 'WTG10' by using Rufus but It always gives " Error: ISO Image extraction failure ". Your Rufus also does not show 'Windows to GO' option if ISO Image contains 'install.esd'. 

 

WinNTSetup v3.7.5 support 'install.esd' based ISO for WTG. I think It will be Nice if you also provide 'install.esd' support in Rufus 'WTG' option.

 

Suppose if install.wim/install.esd contains multiple Windows Installation Indexes then which Index Rufus will use for creating WTG ?

 

There should also be an additional option to choose desired Windows Installation Image Index in order to extract desired Installation Images Index for creating WTG. Most of us uses AIO type ISO and Official Windows ISO also contains at least two Installation Indexes....So please also provide an option to choose desired Installation Index for WTG creation....

 

Thanks in Advance

 

Regards...



#9 steve6375

steve6375

    Platinum Member

  • Developer
  • 7284 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 06 February 2015 - 10:04 AM

*
POPULAR

Nice work!

 

A ntfs_x32.efi driver would be nice to have added because the 32-bit OS is usually smaller and will run on a wider range of systems.

 

P.S. Win8.1 will not MBR-boot from an NTFS Removable drive (unless it is in a VHD file) - you just get an everlasting spinning circle of dots!

Win7 and Win8 will boot from a Removable drive however.


  • alacran, Akeo and devdevadev like this

#10 Akeo

Akeo

    Frequent Member

  • Developer
  • 344 posts
  •  
    Ireland

Posted 06 February 2015 - 12:14 PM

Actually I prefer to create 'WTG + VHD' combination by using WinNTSetup.


OK. Then to cut a long story short, I don't think I will provide this in Rufus, because this is too targeted at power users/sys admins, and Rufus is primarily aimed at the general public. In most cases, Rufus tries to follow the standard implementation, so that users of the feature can feel right at home, and the standard implementation of Windows To Go (AFAIK) is not to use a VHD.

So I think I'll leave the realm of VHD Windows To Go support to WinNTSetup and other tools, which, if they're not doing a good enough job already, will probably be able to do so in the future. Specialized installs are better left to specialized tools.

I also have no plans for Rufus to help with multipartition setups. There again, this is power user/sysadmin stuff, so I reckon that people who want such a setup should either be knowledgeable enough to be able to create this by themselves, or just stick with regular setups if they think they need an automated tool to do that for them. And I do understand that a lot of people, especially on a forum like reboot.pro, may disagree with this stance, but I have to state that, in my experience, advanced features such as this one are (most of the time) troublesome to implement because:

  • The people who want them are never quite satisfied with what the automation does (there's always one more tweak to add to satisfy person X, which will be different from another tweak that person Y want to help with their slightly different process).
  • It quickly becomes super time consuming to ensure that all these special paths in the code work... and keep working!
  • It also is super time consuming to try to educate people, who think they may have some use for the advanced features, but don't know enough about it to understand its use and therefore ask the develop of the app about it (and it doesn't matter how many hours you try to sink in documenting the feature, it's never clear enough).

So, as far as I'm concerned, Multi-Partition based WTG by adding 'WinNTSetup' and 'BOOTICE', with not make things better. It will add complexity, multiply points of failure, and be used by too few people to make it worthwhile.

 

I think that, if you want a custom setup such as what you describe above, you shouldn't ask for an automated tool to do that for you, as this will require a lot of involvement for a developer, and developers always have to cut features due to lack of time, even more so if they provide an application entirely for free.
 

Please also add x86_32 (ntfs_x32.efi driver) and even ARM along with x86_64 in Rufus ESP Partition.


I'll probably add x86_32 support in due time, but this will increase the size of Rufus (which I try to avoid), and I also need to investigate a few things with x86_32 drivers first. For instance, right now, all the efifs drivers seem to work for x86_32, except exFAT (whereas it works fine for x86_64), and I'd like to understand if maybe there isn't something to fix, that may also have an impact on NTFS x86_32. Again, my development time is fairly limited, so I can't add things as fast as everyone would like...
 

Will It also boot 'WTG' in Pure Secure UEFI mode similar to your Rufus method?

 

If you select GPT for UEFI in the Rufus options, you can boot in Restricted Boot (a.k.a. Secure Boot), as Rufus will not install its custom bootloader then, but create a Windows To Go drive in the exact fashion Microsoft recommends (with 100MB MSR, ESP and all). But then you lose the dual BIOS/UEFI ability. But then again, if you are that concerned about Restricted Boot, you want to use it in an environment where BIOS boot is not available (else you completely compromised your "security").

I have been considering getting the Rufus custom bootloader (UEFI:TOGO) signed by Microsoft, but this is tricky because:

  • It's expensive and there are requirements, such as keeping your signing key on a certified secure machine, that are difficult to match for independent Open Source developers.
  • Microsoft's Restricted Boot terms and conditions explicitly prohibit the signing of components that contain GPLv3 code, and the NTFS driver is GPLv3 (now I guess you're starting to understand why I am using Restricted Boot...). So I'd first have to rewrite the part that accesses the NTFS data not to use the NTFS driver...

Is it necessary to keep ESP Partition at the very end of USB Drive ?


If you want any hope of dual booting a removable W2G and access its content from Windows, it is.

But if you create a drive manually, you can put it anywhere (which is pretty much what the UEFI specs say). Rufus just puts it at the very end because it suits multiple purposes there.
 

Suppose I have a Fixed USB Drive and then I will create three partition as follows (...)


As far as I could see from the UEFI specs, a compliant UEFI system will look for the ESP anywhere, and boot from it, wherever it resides. Since the ESP has a specific ID (MBR)/GUID (GPT), whatever FAT partition you have, that doesn't have the specific ID should be ignored by compliant systems if an ESP is found. My understanding is that, it's only if an ESP is not found that an UEFI system can try to take a look at FAT partitions, in the order they exist on the disk, to see if they contain a bootable EFI file, and enable booting from them. But the ESP is meant to always have precedence.

Now, UEFI:TOGO is designed specifically for the partitioning scheme created by Rufus, so it is tied to look for an NTFS partition as the first partition (and will fail if it doesn't find one there). There again, I wish I had all the time in the world to add additional features, such as looking for the NTFS partition wherever, but, believe it or not, I have to keep a regular (non Open Source related) 9 to 5 job, so that I can keep providing all these apps and drivers for free, which in turn means that the amount of time I can spend on adding non essential features is severely restricted.

Then again, it's Open Source, so if anyone wants to send improvements for UEFI:TOGO, I'll happily apply them... :)
 

I have used 'Windows10_TechnicalPreview_x32_EN-US_9926'


So far, I have NOT been able to create a working Windows To Go drive using any of the Windows 10 preview images, regardless of the standard method used (including the Windows To Go creation utility from the latest Win10 Enterprise Preview).

 

That's actually something I wanted to post about on this forum: Has anyone ever managed to get a working regular Windows 10 To Go drive using the MS Preview ISOs?

 

Right now, until Windows 10 is officially released, and I get some info on how the heck one is supposed to create a standard (i.e. non VHD) working Windows 10 To Go drive, Windows 10 To Go is UNSUPPORTED in Rufus.

This being said, I only have one physical UEFI system I can test with, and it's x86_64, so I haven't tried x86_32. I'll see if I can take a look to figure out that error, as it doesn't happen for x86_64.
 

Your Rufus also does not show 'Windows to GO' option if ISO Image contains 'install.esd'.


Do official Microsoft ISOs contain 'install.esd'?

 

If not, I'll probably have to push that request at the bottom of the "nonstandard stuff, that power users/sysadmins requested" list of things I'm not planning to implement in Rufus, unless I magically get a lot of time on my hands...
 
Still, if you can point me to an official Windows image that contains an .esd, I'm definitely interested...
 

Suppose if install.wim/install.esd contains multiple Windows Installation Indexes then which Index Rufus will use for creating WTG ?


I've never seen any official Microsoft Windows ISO (or Windows To Go creation guide) use anything but index 1 for the install.wim, so that's what Rufus is hardcoded to use.

 

As usual, the day someone points me to an image that doesn't match this expectation, I'll look into modifying the code. I should point out that I am not planning to go out of my way to support AOI as these are custom non official images, and I expect people who create those to have the sysadmin skills and tools required to use them as they see fit.
 

Win8.1 will not MBR-boot from an NTFS Removable drive (unless it is in a VHD file) - you just get an everlasting spinning circle of dots!


Yup, that's my frustrating experience... :frusty:

 

Since this is a forum dedicated to figuring out this kind of things, wouldn't it be nice if someone could take a look at the Windows boot process and try to come up with a patch to make 8.1 W2G also boot on removable?...
 

Win7 and Win8 will boot from a Removable drive however.


I didn't know that. Thanks for the info!

I mostly focussed on 8.1, and expected 8.0 and 7 to be equally restricted, so I only tested those with a fixed drive.

 

Even more reason for someone to try to figure out how to patch that 8.1 restriction, that didn't exist for earlier versions (and yeah, I know it would break Restricted Boot, but I think there are a lot of people out there who'd like Windows 8.1 To Go to work from removable).



#11 steve6375

steve6375

    Platinum Member

  • Developer
  • 7284 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 06 February 2015 - 01:03 PM

I tested with source = build 9600 Windows 8.1 90-day eval 64-bit ISO 9600.17050.WINBLUE_REFRESH.140317-1640_X64FRE_ENTERPRISE_EVAL_EN-US-IR3_CENA_X64FREE_EN-US_DV9.ISO

I ran Rufus 2.0.0 Alpha using my Win 8.1 64-bit system

I installed to a Corsair Voyager GT 32GB removable flash drive.

Both UEFI and MBR booting worked fine under VBox 64-bit VM (USB drive appears as a Fixed-disk under VM).

As expected, it would not UEFI-boot from a real system.

:1st:


  • Akeo likes this

#12 steve6375

steve6375

    Platinum Member

  • Developer
  • 7284 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 06 February 2015 - 01:03 PM

I tested with source = build 9600 Windows 8.1 90-day eval 64-bit ISO 9600.17050.WINBLUE_REFRESH.140317-1640_X64FRE_ENTERPRISE_EVAL_EN-US-IR3_CENA_X64FREE_EN-US_DV9.ISO

I ran Rufus 2.0.0 Alpha using my Win 8.1 64-bit system

I installed to a Corsair Voyager GT 32GB removable flash drive.

Both UEFI and MBR booting worked fine under VBox 64-bit VM (USB drive appears as a Fixed-disk under VM).

As expected, it would not UEFI-boot from a real system.

:1st:

 



#13 devdevadev

devdevadev

    Silver Member

  • Advanced user
  • 504 posts
  •  
    India

Posted 06 February 2015 - 01:05 PM

I'll probably add x86_32 support in due time, but this will increase the size of Rufus (which I try to avoid), and I also need to investigate a few things with x86_32 drivers first. For instance, right now, all the efifs drivers seem to work for x86_32, except exFAT (whereas it works fine for x86_64), and I'd like to understand if maybe there isn't something to fix, that may also have an impact on NTFS x86_32. Again, my development time is fairly limited, so I can't add things as fast as everyone would like...

Thanks for maintaining the hope.......

 

As far as I could see from the UEFI specs, a compliant UEFI system will look for the ESP anywhere, and boot from it, wherever it resides. Since the ESP has a specific ID (MBR)/GUID (GPT), whatever FAT partition you have, that doesn't have the specific ID should be ignored by compliant systems if an ESP is found. My understanding is that, it's only if an ESP is not found that an UEFI system can try to take a look at FAT partitions, in the order they exist on the disk, to see if they contain a bootable EFI file, and enable booting from them. But the ESP is meant to always have precedence.

Thanks for describing this hidden secret......I was really not aware about this....

 

Now, UEFI:TOGO is designed specifically for the partitioning scheme created by Rufus, so it is tied to look for an NTFS partition as the first partition (and will fail if it doesn't find one there). There again, I wish I had all the time in the world to add additional features, such as looking for the NTFS partition wherever, but, believe it or not, I have to keep a regular (non Open Source related) 9 to 5 job, so that I can keep providing all these apps and drivers for free, which in turn means that the amount of time I can spend on adding non essential features is severely restricted.

Then again, it's Open Source, so if anyone wants to send improvements for UEFI:TOGO, I'll happily apply them...  :)

Please allow UEFI:TOGO so that It can also look for at least 2nd NTFS Partition if possible...... AFAIK, you are the only one which gives us hope for Booting WTG within from NTFS Partition of Removable USB Drive in UEFI mode. I have lots of expectation for this feature after reading your post. So PLEASE try to provide this unique feature in UEFI:TOGO whenever you have some spare time........I have enough patience to get this feature from you in few Years/Months/Days.......... :worship:

 

Thanks for giving your precious time......

 

Regards...

 

 



#14 Akeo

Akeo

    Frequent Member

  • Developer
  • 344 posts
  •  
    Ireland

Posted 06 February 2015 - 01:19 PM

Please allow UEFI:TOGO so that It can also look for at least 2nd NTFS Partition


OK, I'll see what I can do... ;)

 

By the way, I should also point out that Rufus 2.0 installs the UEFI:TOGO bootloader when creating UEFI bootable UFDs that are set to have their file system as NTFS (which Rufus will use by default if it detects a >4GB file).

This means that you should also be able to seamlessly boot Windows installation UFDs, that contain >4GB files, in EFI mode.


  • devdevadev likes this

#15 devdevadev

devdevadev

    Silver Member

  • Advanced user
  • 504 posts
  •  
    India

Posted 06 February 2015 - 02:19 PM

I think it will be useful if we can create both 'Standard Windows Installation' and 'Windows To GO' in a single Fixed/Removable USB Drive simultaneously which will boot in both MBR and UEFI mode...

 

Can upcoming Rufus allow us to choose both 'Standard Windows Installation' and 'Windows To GO' options so that we can keep best of Rufus in a single USB Drive.....

 

May it be non-standard but many of us can like it.........Is it possible ?

 

Regards...

Attached Thumbnails

  • Win_Installer + WTG.png


#16 Akeo

Akeo

    Frequent Member

  • Developer
  • 344 posts
  •  
    Ireland

Posted 06 February 2015 - 04:09 PM

That would require dual boot, which Windows can do, but which I have no plans to support.

Once again, this is a very specific scenario, that I don't believe a lot of people will actually require.

 

Besides, assuming that you are actually using Windows To Go as a lasting Windows drive (i.e. you're going to use it for more than a couple months), you'd probably want to change the Windows install files when Microsoft puts on a new release, and next thing you'll be asking is for Rufus to preserve your ToGo setup while upgrading the install files...

 

If you want to create such a drive, I'd invite you to become familiar with bcdedit and the tools and utilities that system administrators use to create custom images, because that's what you really are after here...

Or just buy a 2nd USB Flash Drive... ;)

 

As a side note, I can't help but be surprised by the number of request I get from people who seem hell bent on trying to use a single UFD to do everything at once, and end up wasting so much time that, they would actually be a lot more productive if they were to recreate the drive every time, even more so as you can do something else while the drive is being created by Rufus, and with a fast USB 3.0 UFD, converting a Windows install ISO takes less than 2 minutes.

 

To me, it seems a bit like inventory management in RPGs: While it's tempting to keep everything ("Who says I'm never gonna need to install Vista x32 in a hurry?"), after a while, you'll realize that you're wasting a lot of time rearranging your inventory, instead of just playing... B)



#17 devdevadev

devdevadev

    Silver Member

  • Advanced user
  • 504 posts
  •  
    India

Posted 06 February 2015 - 04:58 PM

Sorry for disturbing you too much....Actually I can add BCD entry for 'Standard Windows Installation' within both BIOS BCD and UEFI BCD of WTG with the help of Bootice-> BCDEdit option and can extract the content of ISO to the NTFS partition along with WTG files manually...I was just asking if it would possible with the help of Rufus. Actually I should already had to read your FAQ.......Really sorry for wasting your precious time...

 

Thanks once again for providing NTFS EFI driver and the UEFI:TOGO EFI bootloader....

 

Regards...



#18 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15393 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 February 2015 - 06:07 PM

As a side note, I can't help but be surprised by the number of request I get from people who seem hell bent on trying to use a single UFD to do everything at once, and end up wasting so much time that, they would actually be a lot more productive if they were to recreate the drive every time, even more so as you can do something else while the drive is being created by Rufus, and with a fast USB 3.0 UFD, converting a Windows install ISO takes less than 2 minutes.

 

To me, it seems a bit like inventory management in RPGs: While it's tempting to keep everything ("Who says I'm never gonna need to install Vista x32 in a hurry?"), after a while, you'll realize that you're wasting a lot of time rearranging your inventory, instead of just playing... B)

 

Or - as I sometimes like to call them - as they are strangely common among the good Linux guys (or more exactly self-proclaimed or wannabe Linux guys), Distro collectors, basically it seems like the game is about having the more different distro's (each one of them having 95% the EXACT SAME software/tools, sometimes more than that, with only some slight GUI difference) and go as far as managing to get to the desktop and call it a score...

JFYI ;):

http://reboot.pro/to...sb-perfect-key/

Particularly starting from here:

http://reboot.pro/to...ct-key/?p=97348

 

:duff:

Wonko



#19 Akeo

Akeo

    Frequent Member

  • Developer
  • 344 posts
  •  
    Ireland

Posted 06 February 2015 - 06:39 PM

@devdevdev, no worries - asking is free :D

@Wonko, most of the multiboot requests I get tend to have at least one Windows component, but I definitely hear you!

 

Oh, and since we're talking multiboot, this is as good an opportunity as any to indicate that Rufus 2.0 can install GRUB 2.0 or Grub4DOS.

As with Syslinux, you need to be in Advanced mode (white triangle), before the option becomes available. And just like Syslinux, this will install a blank bootloader, meaning that you'll still need to provide the conf files and modules as required...



#20 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15393 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 February 2015 - 07:15 PM

@Wonko, most of the multiboot requests I get tend to have at least one Windows component, but I definitely hear you!

Yep :), but the point I was trying to make is that due to the Closed Source / Proprietary/Undocumented (or simply missing/lacking) nature of Windowses and Windows based PE's it is objectively - in some cases - *needed* to have more than one Windows Install or PE, in the Linux world (where the REAL good Linux guys live :)) there are no such limits, and anyone can put together a single distro containing ALL the tools actually *needed* and even more.

 

Oh, and since we're talking multiboot, this is as good an opportunity as any to indicate that Rufus 2.0 can install GRUB 2.0 or Grub4DOS.
As with Syslinux, you need to be in Advanced mode (white triangle), before the option becomes available. And just like Syslinux, this will install a blank bootloader, meaning that you'll still need to provide the conf files and modules as required...

Just to disambiguate (correct me where/when needed):
Syslinux.exe installs:
  • a bootsector code (chainloading LDLINUX.SYS) to the bootsector or PBR/VBR and booting to the partition/volume is something that is done by the MBR code (which can be *any* "plain" MBR code, including the DOS/Windows ones or the provided one included in Syslinux, i.e *any* MBR code chainloading the "Active" partition or *any* other MBR code - part of a bootmanager - that can do the same chainloading of the partitio/volume bootsector).
grub4dos can be "installed" to
  • EITHER the bootsector (i.e. similarly to the above the bootsector code is invoking the grldr file on the volume and booting from the volume is done by the MBR code)
  • OR to the MBR (+ a few hidden sectors) by copying to it the grldr.mbr and the grldr is directly chainloaded (first instance found) completely bypassing the bootsector of any partition/volume.
I believe (but cannot say for sure) that GRUB2 can be as well installed BOTH to the MBR and to the bootsector (but wouldn't swear by it), though it is almost universally deployed to the MBR :unsure:.

Also - unless something has changed recently and of which I ma not aware of - the "core" file of grub4dos (grldr) is "portable" and essentially "monolithic" whilst the "core" file fr Syslinux (LDLINUX.SYS) is specifically configured for the specific device/install and has in common use a number of external "modules", and as well the GRUB2 "core" file is "core.img", it is specifically built and has as well a whole lot of external "modules".

The "CONF" files amount to menu.lst (for grub4dos) Syslinux.cfg (for Syslinux) and grub.cfg (for GRUB2), grub4dos menu.lst can be put in any among ROOT, /boot/grub/ or /grub/, syslinux.cfg should be in the *WHATEVER* path provided on SYSLINUX.EXE command line at install time, grub.cfg should be in /boot/grub.

So it would be nice if you could more exactly describe the method/way RUFUS uses when installing them... and where to manually add the modules and conf files ...
(... at least for syslinux it is IMHO needed to know where to put the syslinux.cfg)

:duff:
Wonko

#21 Akeo

Akeo

    Frequent Member

  • Developer
  • 344 posts
  •  
    Ireland

Posted 06 February 2015 - 11:24 PM

Syslinux.exe installs:


Just for the record, I don't invoke syslinux.exe from Rufus, but I have my own version of the syslinux installer in the source.

Now, onto the Syslinux installation, Rufus 2.0 uses:

  • The Syslinux MBR from ms-sys
  • The VBR/PBR from Syslinux 4.x or 6.x
  • The ldlinux.sys from 4.x or 6.x, which is copied to the partition as a hidden file
  • For 6.x, ldlinux.c32 (the module base library), copied to the partition, which Rufus asks users to download from the internet, as this file is a bit large and only needed for bare installs.

This should give the bare minimum for a syslinux.cfg file to be parsed, which in turn can call on more .c32 modules to be loaded. The files being used come from the official distribution, so the search paths for the config file will reflect the default (starting with \syslinux.cfg). If you want to know the full sequence of config files being searched, and from which directory, you'll have to check the Syslinux official doc, as Rufus doesn't do anything fancy but reuse the official binaries and options here.
 
I'm also going to point out that Syslinux 5.x and later break module compatibility between versions (or, more annoyingly, even between the same version of a pre-release, as this forced me to add specific Syslinux versioning code and keep way too many versions of 6.03)
 
For more on the Syslinux files embedded in Rufus, and especially if you want to check that these are indeed the same as the official ones, you can always check the note from https://github.com/p...er/res/syslinux, where I openly describe how I got the files.
 

 

With regards to Grub4DOS, first of all you're absolutely correct that it doesn't use modules. The modules I was talking about are for Syslinux and GRUB 2.0.
 
At the moment, Rufus uses Grub4DOS 0.4.5 (and will display the version it uses in the dropdown, so that people know what they install). The version I used was recompiled from the github source as indicated at https://github.com/p...master/res/grub. I may update it before release, depending on the new features that were added.
 
The bare install of Grub4DOS, done by Rufus 2.0 is fairly straightforward:

  • MBR and hidden sectors (which I call SBR for "Secondary Boot Record" in Rufus) are picked from grldr.mbr
  • grldr, that gets copied onto the partition and is quite large (by Rufus' standards) is downloaded from the internet

There again, the config file will be whatever the default Grub4DOS settings state it should be, since the version Rufus uses was recompiled without any specific options (and that's really what a "bare" install means: you're either supposed to know the rest, or be able to pick the missing info from the official project)
 
Note that any file that gets downloaded by Rufus is obtained from a subdirectory of http://rufus.akeo.ie/files/, where each subdirectory should contain a readme indicating how the files were either obtained or built, for validation.
 

Finally, the GRUB 2.0 install is close to the Grub4DOS one in that it uses:

  • MBR (boot.img) + SBR/hidden sectors (core.img)

...and that's it. This is because the core.img I use, which there again is something I compiled from source (as detailed at https://github.com/p...aster/res/grub2) includes the FAT, NTFS and exFAT modules, which is just enough to allow loading a config/modules from such a partition, and I also wanted to make it fit within the minimum 31.5K hidden sectors that Rufus keeps after the MBR.
 

The "CONF" files amount to menu.lst (for grub4dos) Syslinux.cfg (for Syslinux) and grub.cfg (for GRUB2), grub4dos menu.lst can be put in any among ROOT, /boot/grub/ or /grub/, syslinux.cfg should be in the *WHATEVER* path provided on SYSLINUX.EXE command line at install time, grub.cfg should be in /boot/grub.

So it would be nice if you could more exactly describe the method/way RUFUS uses when installing them... and where to manually add the modules and conf files ...


Well, you pretty much already described the whole lot. :thumbsup:

 

The Syslinux installer used by Rufus does not specify a path, so you should put syslinux.cfg in the root directory. But from what I recall, you should also be able to put it in some of the extras subdirectories that are being looked up by default, but for which I'd have to look in the code or the doc to tell you what they are...

 

Once again, I'm going to sidestep any contractual documentation obligations by saying that, if you used the bare installers from the advanced mode, which is deliberately hidden by default, I will assume that you know what you are doing... :ph34r:

 

I should also indicate that, the main reason GRUB 2.0 and Grub4DOS were added, was not so that users could install a bare version (that's just a bonus for advanced users), but so that useful ISOs, such as the latest FreeNAS or Super Grub2 Disk, are now compatible with Rufus.



#22 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15393 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 February 2015 - 11:45 AM

Very good. :thumbsup:
I usually tend to know what I am doing (more or less ;)) but I wanted to know what Rufus does (and you nicely supplied the needed info).

To sum up, you (or Rufus) are as victim as all the rest of the world of the madness that permeated lately Syslinux (or the good Peter Anvin) or both :(, BUT you managed *somehow* to grub4dosize :w00t: the GRUB2, which is an exceptionally good piece of news :thumbsup: though - to be picky (as I am) - there are two slightly "deceiving" pieces of info.

You are not actually using grub4dos 0.4.5 , simply because it does not really-really exist, or, better, there exist any number of grub4dos 0.4.5c versions, the good news being that changes in 0.4.5c tend to be lately only in the grldr itself (and not in the grldr.mbr that is what is deployed to MBR + hidden sectors) so that - in case of need the user can simply replace the grldr with latest-latest version and the grldr.mbr that Rufus deploys will be able to load it in most cases. :)

 

You are not actually using GRUB2, but rather using a "custom built" GRUB2 with an exceptionally good - I am repeating myself - more self-contained approach :thumbup: that  while possibly - due to size constraints - somehow limits it capabilities, allows for a much "cleaner" minimal install.

 

AFAIK/AFAICR, the path where Syslinux (actually LDLINUX.SYS) looks for Syslinux.cfg is ROOT unless a directory - often used is /SYSLINUX - is specified on command line of Syslinux.exe at install time, so if your installer sets it to ROOT, I believe it is perfectly fine.

 

Still to be picky, reading the info in:

https://github.com/p...master/res/grub

and here:

https://github.com/p...aster/res/grub2

they seem to me EXTREEMINGLY confusing as you use the grub name (that actually means grub4dos) and you seemingly mention having added GRUB 2.0 to grub4dos :unsure: and reference to core.img (when talking of grub/grub4dos) while you actually use grldr (for grub4dos)...

 

 

:duff:

Wonko



#23 Akeo

Akeo

    Frequent Member

  • Developer
  • 344 posts
  •  
    Ireland

Posted 07 February 2015 - 03:39 PM

You are not actually using grub4dos 0.4.5 , simply because it does not really-really exist


I could nitpick and say it depends of whether you are considering 0.4.5 to be the sourcecode branch of the current release, which is accurate, or to be a binary release. But to be honest, there's only so much real-estate I can use in Rufus to provide the version info (I had to spend time editing 30+ translations just to grow that field so it could display the version, for crying out loud!), so 0.4.5 is more than good enough.
 
Now, if I really wanted to be pedantic, I'd use the git SHA1 for the version I'm installing, as this is the only accurate number, but that would not help anybody.

The exact version I use is in the readme. If people are unhappy about me using 0.4.5, they can fetch the information from here.
 

the good news being that changes in 0.4.5c tend to be lately only in the grldr itself (and not in the grldr.mbr that is what is deployed to MBR + hidden sectors) so that - in case of need the user can simply replace the grldr with latest-latest version and the grldr.mbr that Rufus deploys will be able to load it in most cases. :)


That's good to know. :good:
 

You are not actually using GRUB2, but rather using a "custom built" GRUB2


Yeah, yeah. But I also know that I'm never going to be able to satisfy both the general public (who will prefer to see a common version number they can refer to, even if it's approximate) and pedantic people. So I'll leave the pedantic folks track the readme in the source repo, if they are so inclined, as it provides the full details about the version I use...
 

Still to be picky, reading the info in:
https://github.com/p...master/res/grub
and here:
https://github.com/p...aster/res/grub2
they seem to me EXTREEMINGLY confusing as you use the grub name (that actually means grub4dos)


Well:

  • I somehow need to convey that Grub4DOS, which is based on the Grub 0.x code, is anterior to the Grub 2.0 code. For instance, if I were to use grub2 and grub4dos, then I'd get the grub4dos MBR listed after the grub2 one in ms-sys, which, at least to me, doesn't look good at all. The ms-sys choice of MBR header name is actually what prompted the subdirectory name in res\.
  • There's no guarantee that somebody else isn't going to create another fork of the Grub 0.x code and call it whatever, and I might then replace my Grub4DOS artifacts with that. As far as I could see Grub4DOS changed maintainership quite a few times already... Not to say that chenall isn't doing a tremendous job at the moment, but Open Source projects and forks come and go.
  • How I decide to name the subrepositories in my source is really my own business. For all you care, I could have called these subdirs "Bumblebee" and "Megatron", and it wouldn't make an ounce of difference. :geek:

and you seemingly mention having added GRUB 2.0 to grub4dos


Huh?
 
I think you're confusing a git commit message title with actual dedicated info on a file.
In other words, if you see something like:

grldr.mbr 	[grub] add Grub 2.0 support

on github, it only means that the last commit that modified this file (b3947fc0263f2301d29d26742539751ba2cc1b28 - how's that for a proper version number? ;)) had the title "[grub] add Grub 2.0 support". And as you should understand, the info you can place in a commit title is limited, so if you're modifying multiple elements, you're only going to mention the major one.
 
Now, if you click on that info (it's an hyperlink), you will be brought to the actual commit mentioned above, and its full message, where you will find that it contained the a change that:

Also moves secondary Grub boot record as a resource

So that's why you seemingly find mentions of Grub 2.0 on Grub4DOS files. I simply happened to use a commit that pertained mostly to Grub 2.0 to move grldr.mbr into a res/grub/ subdirectory in the source, and as a result, github will display the title of the git commit where the change occurred, whatever that title is.

 

The next time I modify that file through a commit, the data suffixed to the filename will change to the title of that new commit.



#24 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15393 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 February 2015 - 04:03 PM

Yep :), that why I extensively used the verb seem and the adverb seemingly. ;)

 

I know it is a mess - specifically the naming/mis-naming of GRUB/GRUB2, and of course you are not at all the cause of it :), nor particularly about the queerness of github, but try putting yourself for a moment in the shoes of an "average" user, that you point (for explanations) to  https://github.com/p...master/res/grub, I will bet that 95 out of 100 will get the message that 

 

[grub] add GRUB 2.0 versioning and enable external core.img download …
latest commit e90eaa4abc
pbatard authored on Dec 30, 2014 ..
grldr.mbr [grub] add Grub 2.0 support 3 months ago
 grub_version.h [grub] add GRUB 2.0 versioning and enable external core.img download a month ago
 readme.txt [grub] switch to the more compatible Grub 2.00-22 3 months ago

 

that - say - you added to grldr.mbr, clearly a part of [grub], Grub 2.0 support :w00t: and that grub can now download external core.img :ph34r:

 

Honestly, even  grldr.mbr [Bumblebee] add Grub 2.0 support would have been slightly less confusing ... :whistling:

 

:duff:

Wonko



#25 Akeo

Akeo

    Frequent Member

  • Developer
  • 344 posts
  •  
    Ireland

Posted 07 February 2015 - 04:10 PM

Gonna call bullshit on that one.

 

The average user will not read the extra info after the file name. They will read the readme.txt data and ignore the rest.

 

Pedantic people on the other hand... :D

 

If I were to try to satisfy the potential requests of pedantic people while developing, I'd have zero time for actual development.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users