Arch Linux 2022.11.01 fails to boot if label is changed, despite patching #2086
Comments
|
That's probably because you used a space in there. I'll test this, but what happens if you use underscores instead of spaces in your label? |
|
Will try using underscores instead of spaces shortly. |
|
For reference, the problem is that there are a mainstream distros out there (Red Hat, CentOS...) that require spaces in the FAT32 label to be converted to If that is the issue, this is going to be very difficult to fix, because we cannot "guess" what type of distro may require spaces and what type of distro may require Which means that, as long as it works with the default label proposed by Rufus, or when users don't try to change the label to something that includes spaces, I'm probably not going to do anything about this. But again, I'll test this when I have a chance to see if this theory is correct... |
|
Now trying "Arch_Linux_2022.11.01", here's the Rufus log. |
|
Does NOT work! |
|
But it works when you don't change the label right? I'm just going to point out that there's actually a good reason that Arch use a uppercase label with no spaces and less than 11 chars for their ISOs, so that it is compatible with the limitation of FAT32 and that while I can understand why one would want to change the label, the root of the problem is that there are too many Linux distros out there that use a search by label for the boot media (AFAIK the only ones that evolved from this are the good people of Debian, who realised that this was way too brittle a solution and are looking for a specific file on all the partitions that can be accessed, which is the MUCH SMARTER way to do it), and this is what leads users into exactly the kind of issue you are facing. Plus it breaks UEFI file system transposition (the ability that UEFI provides of simply copy the content of a boot media like an ISO at the file system level and still end up with a bootable media, without the need to use any utility like Rufus), which is another problem... At any rate, I will test this issue when I get a chance, but, yeah, I'm actually not surprised that things do break, as they have repeatedly done in the past, when distros rely on labels to identify the boot media... |
|
Arch media uses by default |
|
Now attempting just leaving the stupid label option alone, and editing the |
Yeah, there's also a good chance that they have hardcoded a search for Another reason why looking for a boot media by label is a VERY STUPID IDEA and why the Debian folks have moved away from it. |
|
Yep, it works when not changing the label. |
|
Hello guys, I have the same issue on another OS (Athena OS). The name of the ISO is At the end of the process, Rufus assigns the label "ATHENA-2022" to the USB device instead of the label shown in "Volume label" field of Rufus. If I remove and replug the USB to Windows, it sees my USB device in "My Computer" as "athena-2022.11.13" and not more as "ATHENA-2022" but "athena-2022.11.13" is a "fake" label, because if I open Disk Management of Windows, the USB device is seen as "ATHENA-2022". When I reboot the PC for booting Athena OS system, the grub is not able to find the device (as explained by @Leo40Git) because it refers to the "fake" label "athena-2022.11.13" and not the real assigned label "ATHENA-2022". If I edit the "Volume label as It is needed that Rufus must assign as REAL label the one specified in "Volume label" field, that in my case is "athena-2022.11.13", so either force the program to have limited characters in "Volume label" or remove the limited characters (if possible, idk) from the final label name on the USB device. |
Rufus should patch the GRUB configuration file, replacing the label. We must find out why it is not working anymore. |
That's because the FAT specifications do limit labels to 11 uppercase characters with no space. Now, to hide this behaviour and make it look like a non FAT restricted label was assigned, Rufus also creates an
Usually, this should be handled by altering the GRUB or Syslinux configuration files, that would have a kernel option that specifies the label that should be looked for to find the boot media. For distros that don't deviate too much from the de-facto norm (i.e. distros that don't place their GRUB/Syslinux config files in weird places), Rufus can do that automatically, and you will see lines such as: Unfortunately, since you did not attach a log, I can't tell what happened in your specific case.
No, it is related to the FAT specifications, that PROHIBIT the use of a label that is longer than 11 characters or that contains anything but UPPERCASE and a few other characters such as
Again, Rufus CANNOT do that, because FAT labels can only store a label up to 11 characters long, and using uppercase. You are under the impression we somehow designed Rufus to screw up the label, but we don't go altering labels unless we don't have any other choice. That's the reason why Rufus converts the label in the first place and limits it to 11 characters. Now, if you could provide a full log of how you created the ISO in Rufus, that would help, but it would tell us where the config files are locates and why they might not have been patches by Rufus. |
|
@pbatard in Windows where I can retrieve Rufus logs? Furthermore, we have this limits due to FAT labels. At this point, cannot you limit also the "Volume label" field at the same 11 chars? |
See the check list at the top of this issue.
I won't change a thing, since the label that rufus assigned is the same as you would get with an 11-char limited field. The full field label is only used for I have to stress out that the issue is not with the UI or how Rufus processes the label, but with how we link that processed FAT compliant label with the config scripts that are used to boot the media. On that note, it's really a shame that Arch derivatives like Athena don't take a hint from what Arch are doing with their ISO labels, and take a minute to wonder why on earth the official Arch maintainers would limit their labels to 11 uppercase characters, which is precisely because they want to make sure that the label is valid for both ISO-9660 and FAT32... PS: I can only find downloads for |
Don't worry for it, Athena devs can be compliant quickly for labeling in a correct manner within 11 chars and thank you for the suggestion, I was ignoring this limitation.
2022.11.13 is still not released because in testing phase. The latest one is |
Sounds good. Hopefully, if the issue (as is my current guess right now) is that they set the Syslinux/GRUB config files into different places or under different names than the ones Arch uses (since Rufus needs to have some idea where it should look in order to patch the kernel option to insert the actual FAT label), they can also revert to not deviating from what Arch does. Especially, Rufus should produce something similar to what OP reported in their log above: When dealing with Athena ISOs if you want to have any hope of finding the boot media (which, I am aware per the original issue still doesn't seem to work if you change the label, but which, for most distros, should be enough, even with a user-specified label). |
|
Here the Rufus logs: |
|
Thanks. So Rufus did properly patch the kernel options, but we still weren't able to find the media. I guess this is indeed the same issue as OP's with recent Arch ISOs, where there must be some remnant option somewhere (not in the config files Rufus patched) that references the original ISO label. Except of course, in OP's case, the issue was brought forward by the user actively altering the label, whereas this time, it's because Rufus has not choice but to alter the label to make it FAT compliant... I still haven't had a chance to look at it more closely, but I'll do so when I get a chance, coz I'd really like to know where, when the kernel options should be the only elements that specify the label to look for, there might be a residual label lookup in the Arch boot sequence. Oh, and just so it helps with testing, can you indicate whether you tried to boot in UEFI mode (in which case |
Currently I only tried in UEFI mode.
Athena ISO is created by using Archiso, and the ISO label is defined in profiledef.sh that defines several variables that will be used in syslinux and grub config files (i.e., |
|
Here when I use the new ISO with the new assigned label on Rufus: It failed again because GRUB (or better, Linux environment) reads string in case-sensitive. Here the logs: |
|
Nah, the issue is that Arch recently added a new: line to their GRUB config script, and since it's new, and we don't replace everything with a label willy-nilly, we don't yet have code in Rufus to patch the search. This means that, as soon as you don't have a label that matches your FAT partition's there, boot is going to fail. I have a fix for this which I will commit shortly. |
|
This should be fixed now (though I would still advise to follow Arch's example and use a default FAT compliant label for the ISO). Feel free to test with the artefact from https://github.com/pbatard/rufus/actions/runs/3456902660 once it's built. |
|
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. |
Checklist
<FULL LOG>below.Rufus version: x.y.z- I have NOT removed any part of it.Additionally (if applicable):
(✓)button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.Issue description
Changing the label from the default "ARCH_202211" value to something else (I used "Arch Linux 2022.11.01") seems to cause the boot loader to be unable to load the kernel - it cannot find "ARCH_202211".
This is despite the log claiming that references to this label have been patched (which is why I am opening an issue here rather than on Arch Linux - since it seems like a Rufus feature intended to avoid this exact scenario isn't working).
Log
The text was updated successfully, but these errors were encountered: