On Mon, 7 Mar 2016, Pete Batard via Syslinux wrote:> On 2016.03.07 17:55, Ferenc W?gner wrote: >> Why not install instead an arbitrary version of Syslinux and replace all >> .c32 files with the modules of the installed version? > > I mentioned that in my previous mail. But I reckon it was easy to miss > as that mail was rather long: > > > "One solution to avoid that would be to embed in Rufus all possible .c32 > modules from Syslinux, alongside with the 'ldlinux.sys' version we have, > and replace them on the USB. This is not very realistic however (the > application size would explode, and as more version of Syslinux get > releases, we'd have more modules to embed)" > > > One thing you may not realize is that Rufus is less than 1MB in size, > and I'd rather keep it that way (for various reason, one being the > bandwidth costs associated with circa 2M downloads/month) and that the > Syslinux files are only one of the various binaries I have to embed in > it (there's also some FreeDOS, GRUB and Grub4DOS binaries, a FAT12 > UEFI:NTFS image as well as and other stuff).What I don't get is why do you have to rebuild the boot loader in the first place. Most of these isos (including the Tails one) are hybrid which should work if you just dd/rawrite it on the USB drive. Rufus seems to do something much more complicated than this, risking breaking the boot loader of the iso while rebuilding it. If the iso already supports booting from USB no rebuilding should be needed, if it does not changing it automatically for something it was not intended to do could either work if you're lucky or fail if you're not. Regards, BALATON Zoltan
Hi Zoltan, On 2016.03.07 20:58, BALATON Zoltan via Syslinux wrote:> What I don't get is why do you have to rebuild the boot loader in the > first place. Most of these isos (including the Tails one) are hybrid > which should work if you just dd/rawrite it on the USB drive.1. As you know, many ISOs aren't ISOHybrids. 2. Regardless, Rufus is smart enough to detect ISOHybrids and prompt the user if they want to write in DD mode, or extract the files to FAT32 and make the drive bootable with the process I described. So it's not like it's not giving users the choice. 3. Yet, the reason why some people might not be too kind to ISOHybrid should be quite apparent here [1]. When written to USB in DD mode, most ISOHybrids that support UEFI will either have 2 partitions, with only the ESP visible from Windows, or worse, a single partition using a Linux filesystem that Windows will not see at all. So, from the perspective of a Windows user (remember Windows is a Rufus app), who might not be that tech savvy and who is attempting to run a Linux live system or install for the first time, all they see is that their USB flash drive has suddenly shrunk in capacity or disappeared from their file explorer altogether. And I hope you'll spare me a "well, it's a user's problem - they should know", because, in the many downloads that Rufus sees, quite a few people are likely to be confused by this as we're not dealing with a a handful of computer savvy people here. So my point is: A Windows' user first Linux experience should be made friendly, not scary, and as cool as the ISOHybrids concept is, they aren't all that great in that respect, at least from a Windows perspective... Also with regards to #3, what if a user needs to copy a wifi firmware blob to get connectivity on after installing my Linux system (and that blob won't fit in the ESP)? Or want to modify the distro packages? Or want to copy files/doc/whatever on that USB? Don't you think that a user might feel more at ease if they can still access the whole content of their drive from Windows, instead of just a small part... if there's a small part to even access at all?> Rufus > seems to do something much more complicated than this, risking breaking > the boot loader of the iso while rebuilding it.Because, sometimes that's what it takes to make an ISO to USB conversion process more intuitive for users who aren't familiar at all with booting, partitioning, Linux filesystems and other stuff. Even prompting, as Rufus does, to decide between DD mode or ISO extract mode for ISOHybrid is likely to be very confusing for a lot of users.> If the iso already > supports booting from USB no rebuilding should be needed, if it does not > changing it automatically for something it was not intended to do could > either work if you're lucky or fail if you're not.From what I could also see on reddit, a few people seem to have trouble with the tails recommended way creating an USB flash drive, or even when using straight DD mode, and there have been a few instances where Rufus non DD mode seemed to sort them out (which may very well have been due to BIOS/UEFI settings, or something else that suddenly became irrelevant when using Rufus, but still). I could also say something about the ISOHybrid _HACK_, which clearly is not something that was ever intended by the people who designed ISO-9660, and that could "either work if you're lucky or fail if you're not". Looking at the recent history of this mailing list, it does seem to me like ISOHybrid can be a bit of a headache... Regards, /Pete [1] https://www.reddit.com/r/techsupport/comments/499b5c/usb_stick_capacity_shrunk_to_2mb/
On Mon, 7 Mar 2016, Pete Batard via Syslinux wrote:> I could also say something about the ISOHybrid _HACK_, which clearly is not > something that was ever intended by the people who designed ISO-9660, and > that could "either work if you're lucky or fail if you're not". Looking at > the recent history of this mailing list, it does seem to me like ISOHybrid > can be a bit of a headache...Yes I agree it's not a perfect solution. The difference is that the headache in this case is for those tech savvy people creating the hybrid iso who should be able to figure it out so the non-tech savvy end users should not have a problem with it as long as used as intended. If the end users start to modify an iso without knowing what they are doing they could easily end up with problems. If Rufus can do it automatically for them then they are lucky, if not then they just broke something they were not supposed to change. I mean, trying to do something that was not intended by those that designed it can be a valid problem but not easy to solve cleanly. If you're already rebuilding the boot loader on the iso you could also replace all of syslinux with a known working version that you have all the matching modules for and only keep the config. (This is what Ferenc has suggested.) This might save you having to keep all possible versions of syslinux ever appeared in the wild and avoid the need to detect the version of syslinux on the iso. But can break with patched syslinux versions or if they have custom modules. (But then trying to use a substitute part from a release for this customised version would likely break too.) I'm not sure if the config file is more portable between syslinux versions than modules but I guess it would be so for this keeping fewer versions could be enough. I was also thinking about storing hashes of files that you have modules for and try to idenfify the version by comparing the hashes instead of trying to extract a version number from the binary, but this may be problematic as well because building with different compilers will result in different hashes and you don't know what was used by those created the iso. I don't see a way to solve this problem in a way that is fool-proof and cannot break as this is inherently fragile because you can't know what's on the iso. It can be anything, even containing custom modules or patched, unreleased versions. Also I'm surprised that isos converted this way still work and the software on them is not confused by having its files on a different filesystem loosing case sensitivity, access rights, links, etc. For simple live CDs running entirely from an initrd this could work but for anything more complex than that I wonder how it does not break. Regards, BALATON Zoltan