Slax with rufus

[Tomas-M]

Hi, I am creator of Slax Linux.
Lots of people complain that they use rufus to put Slax on USB device and it does not work for them.
Well basically Slax is not meant to be flashed to USB disk with rufus.
Would it be possible for you to update your software, and if it detects that the ISO contains Slax, it refuses to flash it to USB device and it informs users to use supported way described at Slax website?

I do not know how your software works in general, but Slax requires FAT32 filesystem on the device and then user needs to run /slax/boot/bootinst.bat script to make it bootable with syslinux. Slax actively uses the FAT32 filesystem to store sessions and so on, so if you expect to flash it as an isohybrid filesystem then the result will not be as users expect. Furthermore it may not boot at all.

I hope you can fix your software to either support Slax the right way, or to inform users that rufus is not for Slax.

Thanks
Tomas M
slax.org

[pineapple63]

From what I can tell, rufus does seem to default to using a FAT32 file system, at least with the 32GB drive I tested with
I think the problem likely lies with how Rufus makes the drive bootable, as from what I understand, Rufus uses its own syslinux files

I did notice the image seems to be Legacy BIOS only, which may explain why it took me three goes to find a computer that would recognise the drive as bootable (even though the boot fails with an error), and even then I had to enable legacy booting (the first 2 computers I tried appear to not support legacy booting at all, they will only boot pure EFI systems, and the third does support legacy booting, but it was set to only boot EFI systems by default)

[pbatard]

@Tomas-M,

Thanks for reporting the issue, which I was unaware of as it had not been reported here before.

As @pineapple63 pointed out, Rufus does create a FAT32 based media, but it appears that, unlike other Linux distros, the slax ISO is not designed to work with File System Transposition (which is the process of taking an ISO-9660 bootable image, extract all the files to something like FAT32, and have that media boot without any further processing in UEFI mode, or boot in BIOS mode with the mere installation of a vanilla syslinux or GRUB bootloader with the standard options). So, indeed, this makes it harder for users to create a bootable media, using the method of their choice. Especially, your EFI bootloaders are not located in the UEFI standard-defined directories but need to be copied over by your media creation script, which, at the very least, is a step that seems a bit superfluous unless you actively want people not to be able to boot the media.

I also found that the syslinux.exe you use appears to have been customised from vanilla Syslinux 6.03 and seems to embed a custom ldlinux.sys which is why the generic ldlinux.sys 6.03 Rufus downloads leaves the media unbootable in BIOS mode. However, when telling it to use the ldlinux.sys generated from your syslinux.exe, the media created by Rufus does boot properly.

Unfortunately, whereas Rufus does have ways of dealing with custom GRUB and Syslinux bootloaders for precisely these kind of situations by downloading custom versions as needed (you can see that the first time you run Rufus with Slax as it will report it needs to download Syslinux 6.03 bootloaders), it currently only works for Syslinux if the maintainers do alter the version string reported by Syslinux to indicate that it deviates from vanilla (which means that, instead of reporting 6.03, it would report something like 6.03-slax which in turn would make Rufus able to download the rerquired Slax specific version of ldlinux.sys).
The above means that, unless Slax starts to properly change the version string of the software it does alter, the current override mechanism of Rufus can indeed not make a working BIOS Slax media. Plus, regardless of BIOS boot, this still leaves the issue of duplicating the Slax EFI bootloaders for UEFI boot, which Rufus also does not currently do, but which we could easily add an exception for.

At this stage then, I think I'm just going to add an exception to run slax\boot\bootinst.bat when such a file is detected, though I'm not entirely sure that trying to run such a script may not create issues in the long run...

[pbatard]

Looking at this further, I believe I should be able to patch the ldlinux.sys Rufus uses to point to /slax/boot/ as its working directory, which should solve the BIOS boot issue.

Not sure why our use of APPEND /slax/boot/ in the root syslinux.cfg file we create does not accomplish the same with Slax, but since this is fixable by passing an explicit installation target directory when we invoke our own Syslinux installer, I guess we'll do just that and add an exception to copy the EFI files, to sort Slax support.

[pbatard]

Syslinux BIOS support should be fixed now, and I added an exception of UEFI boot as well.

However, it appears that UEFI boot is broken as of slax-64bit-slackware-15.0.3.iso anyway, as, without using Rufus at all but when following the official installation instructions for Windows (i.e. running \slax\boot\bootinst.bat from an admin command prompt after copying the ISO content to a FAT32 drive), the resulting media was not bootable in UEFI mode on any of the machines I tested (which included recent and old UEFI systems).

I would therefore suggest that you try to validate that your current ISO, and especially the Syslinux UEFI botoloaders, on multiple UEFI systems, as I am pretty confident this is indicative of an upstream issue with Slax rather than improper testing on my side.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.