Why are the new ROME zen builds wanting Fat16 for the ESP?

Development
1

I noticed this for the Plasma (4292); Plasma Slim (4310); and PlasmaWayland (4306) builds.

I am wondering if this is intended by the Dev team for compatibility reasons, or if it’s an oversight or typo or something.

I’m not sure if the following are problems, or just harmless quirks but…

If Erase disk is selected, the install defaults the ESP to Fat16.
But, if I partition manually and select Fat32 for the ESP it throws 2 warning messages.
The first says EFI System Partition is necessary, go back and make one using Fat32.
The next says the partitioning layout doesn’t comply with FS restrictions set by the distro, boot/efi must be Fat16.
Which is confusingly contradictory.
Manually choosing Fat16 for ESP throws no warnings.

Also, and I’m not 100% sure this is related, though it seems likely to be, If I install mint, then install OMLx “alongside” it, the installation fails with the error message.

”Bad main script file”
”Main script file /usr/lib64/calamares/modules/bootloader/
main.py for python job bootloader raised an exception”

I can post pics of these warnings and error message, as well as the partitioning setup, if they are wanted.

This is just the first of 5 potential problems i’ve had with OMLx installs (including ROCK btw) over the past couple weeks.
I’ve been circling around them, trying to get enough of a grasp on them to separate and communicate them clearly in support threads, rather than make even more of a mess in there (I did enough of that already I think :embarrassed face:) but I sort of need to gain clarity on this question first, since it’s basically the start of the whole process (in my mind at least) and I’m not even sure it actually IS a problem.

Hope someone can answer this for me.

2

Note: This installation fail only happened with build 4292, I haven’t tried it with the other 2 builds yet.

3

Let’s just say for the sake of argument that it wasn’t a typo. Currently, no one is booting a compressed kernel over 1 GB. The default size for my cooker install of /boot is 300M. The system keeps 3 kernels installed. There is no immediate danger of the size of the /boot partition running out of space. I bring all this up, because the maximum partition size of FAT16 is 2GB.

This sounds like a calamares config held over from a version that required this support, or possibly a bug.

I have only seen bootloader issues with systems that are Legacy BIOS (or possibly configured as CSM but are UEFI). I am not sure if the FAT16 “issue” might be for safety in that configuration, but GPT is somehow now magically supported on my Legacy notebook without UEFI.

It’s a problem if you can’t complete an install of a system.

4

Try ignoring that error. It has been reported to Cooker devs and maybe someday it will be fixed. I think I first reported this 6 weeks ago but that is guess. But the error message is itself an error.

Would that not be /boot/efi. There is a huge difference between /boot and /boot/efi.

5

Yes, it would be /boot/efi. I still don’t think people are booting compressed kernels over 1GB.

ls -la /boot
total 823576
dr-xr-xr-x  4 root root      4096 Nov 14 22:03 .
dr-xr-xr-x 20 root root      4096 Jan  8  2025 ..
lrwxrwxrwx  1 root root        45 Oct 30 00:27 config-6.17.6-desktop-1omv2590 -> ../lib/modules/6.17.6-desktop-1omv2590/config
lrwxrwxrwx  1 root root        45 Nov  3 00:01 config-6.17.7-desktop-1omv2590 -> ../lib/modules/6.17.7-desktop-1omv2590/config
lrwxrwxrwx  1 root root        45 Nov 13 21:26 config-6.17.8-desktop-1omv2590 -> ../lib/modules/6.17.8-desktop-1omv2590/config
drwx------  3 root root      4096 Dec 31  1969 efi
drwxr-xr-x  6 root root      4096 Nov 14 22:03 grub2
lrwxrwxrwx  1 root root        39 Jul  6  2023 initrd0.img -> /boot/initrd-6.3.5-desktop-3omv2390.img
-rw-------  1 root root 131608143 Oct  3 13:30 initrd-6.17.0-desktop-1omv2590.img
-rw-------  1 root root 131629678 Oct 16 18:31 initrd-6.17.2-desktop-1omv2590.img
-rw-------  1 root root 131646958 Oct 25 09:42 initrd-6.17.4-desktop-1omv2590.img
-rw-------  1 root root 133334257 Nov  1 18:06 initrd-6.17.6-desktop-1omv2590.img
-rw-------  1 root root 133301884 Nov  6 20:28 initrd-6.17.7-desktop-1omv2590.img
-rw-------  1 root root 134991115 Nov 14 22:03 initrd-6.17.8-desktop-1omv2590.img
-rw-r--r--  1 root root    155992 Dec  5  2024 memtest.bin
-rw-r--r--  1 root root    157184 Dec  5  2024 memtest.efi
-rw-r--r--  1 root root  14898176 Nov 11 14:19 microcode.img
lrwxrwxrwx  1 root root        49 Oct 30 00:27 System.map-6.17.6-desktop-1omv2590 -> ../lib/modules/6.17.6-desktop-1omv2590/System.map
lrwxrwxrwx  1 root root        49 Nov  3 00:01 System.map-6.17.7-desktop-1omv2590 -> ../lib/modules/6.17.7-desktop-1omv2590/System.map
lrwxrwxrwx  1 root root        49 Nov 13 21:26 System.map-6.17.8-desktop-1omv2590 -> ../lib/modules/6.17.8-desktop-1omv2590/System.map
-rw-r--r--  1 root root  10514623 Oct 29 22:27 vmlinuz-6.17.6-desktop-1omv2590
-rw-r--r--  1 root root  10514623 Nov  2 21:57 vmlinuz-6.17.7-desktop-1omv2590
-rw-r--r--  1 root root  10514624 Nov 13 20:07 vmlinuz-6.17.8-desktop-1omv2590
6

Posts like this provide us with nothing more than “it’s broke”. Believe it or not we can not fix “it’s broke”. We need more information than that. That is why someone wrote this article:

From OM-Forum>Resources Index>Installation.

Also consider that as much as you are having problems how many people are able to install OMLx without all the strum and drang. It’s just a thought.

Also a reminder. There are no employees, all OM-Contributors are part time, unpaid, volunteers. Anyone one helping you is taking time away from other things on our “To Do” lists.

7

Oh, I agree with you on that. I am currently showing 1.1GB for a /boot with 3 kernels and that seems high.

I have a multi-boot Linux laptop with 5 separate systems currently installed and I see out of 300MB df -h shows a whopping 1% of that as used space. The files in /boot/efi are tiny but essential.

8

Exactly. The need to use fat32 is probably just a false comparison with why you would use it in an installation of Windows 95 B. You wouldn’t use fat32 to store things on a USB disk today because it can’t store 4GB files. Which is why you would use exfat. It’s not really a one to one comparison at all and the bigger number marketing ploy doesn’t realy apply.

9

What I know is that I do a ton of installs of OMLx all versions and we have for a long time used 300MB fat32 for /boot/efi and that works, it still works today. Don’t know where that error message comes from, I have reported it multiple times and beyond that I ignore it. I deal with the real world not some imaginary perfect world.

10

This is not just ROME or znver1, I saw the same error when trying to manually partition an install on an Intel pc with a cooker-lxqt-wayland iso.

I normally choose fat32, so I was a bit surprised when it forced me to use fat16, but they are functionally the same when dealing with such small files.

11

No matter who thinks what should be what, there are a few issues here that explain things:

Particularly:

Where our distro shows up and weighs in… 8 years ago…

Looking over all the closed issues may provide clues.

12

I’m sorry guys, and especially @ben79 . The last thing I want to do is waste anybody’s time or stress you all out, but every time I try to ask questions I mess it up and either overshare, making a mess of the support thread; or I undershare and don’t provide enough detail.

I’ve spent every spare moment in the past 2 weeks trying to scrape enough understanding of everything that’s been going on with this install to separate the (now 6) things that might range from nothing worth bringing up to actual problems that need to be fixed. Some of them have been answered/given workarounds, but I still don’t actually understand them enough to know wtf is going on (which is probably just a me thing tbh)
I spent this time willingly, trying to figure shtuff out myself so that I DON’T waste peoples time. But I can’t seem to break my way into this cluster of problems, or even be sure where OMLx starts and my specific hardware / firmware ends (In spite of spending hours reading up on UEFI and boot loaders / managers).

I posted this in coffebreak first because I didn’t want to make a big issue of it and thought it would just be a simple question.
“Yeh we need F16 to be compatible with BIOS, not just uefi”
or ”Ohh, we didn’t notice that, but it’s fine ignore it”
or “ohh, we didn’t notice, that might upset some UEFI implementations/settings”
I only posted those other details because I thought it might be relevant to that question.
I was hoping this would be one, mind-nagging, “I don’t understand” thing, right at the base of the cluster, that I could scratch off, and make some inroads from there.

Again, I am truly sorry for messing this up and stressing you guys who are probably already stressed after this major update. But I am getting pretty stressed myself.
I chose OMLx because you’re a small, independent distro, knowing full well what that means for support/devs/testers. I chose ROME because I wanted to actually learn.
I gave up at one point and tried ROCK, and even THAT had an issue I couldn’t fn solve.
Maybe I should just give up on OMLx and go back to mint or something, at least until I can tell the difference between a problem that’s (Linux) and a problem that’s (“OMLx is NOT {insert_other_distro_here})
How do you actually KNOW when you’re in over your head?

EDIT:
Sorry, that was probably all oversharing me problems again huh. You don’t need me dumping in here on top of your already overtaxed time.

13

You do not seem to be getting to the “if so many other people can use this why am I having so much trouble”. I don’t know that I am smart enough to help with that except to ask questions from my own experience like:

If I am having a problem understanding a thing is the problem with that thing or my approach to the problem?

Did I not do enough homework before attempting something new?

Am I overthinking the problem?

Am I treating this like it is Rocket Science when it is not?

Am I worrying to much about making a mistake instead of “just do it and learn”?

Am I asking the correct questions?

When people post something like this why am I not using that information?

Another common thing people do is to simply revert to some basic scientific problem solving list.

14

Hey @ben79

TLDR:
I thought I had asked an innocuous question, in the lowest pressure category, that would help me start to break my problems into manageable, ordered, chunks that could then be posted in the appropriate categories, with appropriate details included.
Apparently I even failed at that.

I am definitely there, I have been for at least a week, and the only conclusion I came to is there must be something unique about my hardware or my head.

The more reading I do, the more questions pile up, until I completely lose sight of where I even started. This is partly why I am wondering if I am out of my depth and should retreat closer to the kiddy pool.

Almost certainly yes. “Stop overthinking things” is probably the single most common phrase I have heard in my life.

Sometimes yes, but In this case it’s a new build so there is literally nothing to lose so those moments don’t last too long.

I don’t know, which probably means I’m probably not. I thought this question had been the right one for a starting point but perhaps I was wrong again.

Almost certainly my approach. I was treating the problem cluster as a whole (as I tend to do) and circling it uselessly. Which is why…

(sort of)

…I decided to take the problems in the order they present (from install through to a booted/running system). So I started by breaking of the piece at the very bottom (the starting point) with what I thought would be a simple question that would either be eliminated from the cluster or act as the weak point to breaking it apart into distinct pieces. Depending on the answer to the question, I would have either posted an actual support request about it, or eliminated it. Then depending on those results I would have moved on to then next problem in order that still persisted. I figured this would not only provide an ordered approach, but also eliminate potentially related problems as those relationships emerged without assuming relatedness and dumping unrelated problems in a single thread as a result.
I have always defaulted to looking at how things connect to a bigger picture. This is great for world building, or relating systems you are already familiar with to others you are not. But when it comes to solving multiple problems within a single system you are not familiar with it just leads to assumptions and uncertainty.
I thought I was course correcting by asking this question, (in the coffee break thread) as a starting point.

What to do if there is a problem installing OM Lx

I wasn’t asking about the install fail directly, I just thought it might be relevant to the actual question in the title. In fact, I only even tried that “alongside” install just before posting the question because I wondered how OM’s Calamares would handle installing using another distro’s Fat32 ESP and thought it might be relevant to the actual question.
If the answer about the ESP format led me in any way to think it was an actual issue I was going to repost it in Support with all the required details, and a bunch of relevant screenshots and install logs and more, from all effected versions I’ve tried, and then moved on to the next problem, which probably still would not have been about the install fail.
However, since you asked.

  • re P2.: Secureboot is off (as are TPM and CSM)

  • re. P3: All checksums of all ISO’s matched.

  • re. P4: I asked this question in Coffee Break hoping to figure out where, and what, to post.
    I wouldn’t know a bug from an issue until after going through the Support thread. I suspect posting “bugs” that aren’t actually bugs would be more of a problem than asking a question first.

    I was hoping I could figure out, first, if this is actually an issue, and then if it’s an issue others can help with or just a quirk of my mobo’s UEFI implementation or something.

  • re. P5: Again, wasn’t intended as a bug report. If the answer had led me to posting in Support, let alone a Bug Report, you would have gotten all the information you could ask for and then some.

  • re. P6: I did offer to post screen shots, in the Coffee Break thread, if anyone wanted them.

  • re. P7-9: Thank you, I was looking for this command, in that thread, the other day but couldn’t find it. I knew I had seen it somewhere in these forums but couldn’t find my way back when I wanted it.
    I am also wondering, is the file output by that command
    $ pkexec calamares -d 2>&1 | tee /home/live/calamares-installation-log.txt
    the same as doing
    cat /var/log/Calamares-install.json > Calamares-install.json.txt
    or
    cat /var/log/Calamares.log > Calamares.log.txt
    or is it a different log file altogether (those were the solutions I found when I couldn’t find that post)

  • re. P9→When I next post a question in the Support thread, I will be sure to include
    $ inxi -Fz > inxi_F.txt
    and
    $ dmesg > dmesg.txt

    as well as
    $ cat /etc/product.id.OpenMandriva > product.id.OpenMandriva.txt
    and
    $ sudo journalctl > journal.txt
    Just as I have every other time I have posted questions in Support.

That last post was a little snappy and I apologise again for it. I had thought I found the right approach to breaking apart this whole cluster into something I could begin understanding so I could move on to Support one problem at a time.
And then I got in trouble AGAIN and overreacted.

15

As it turns out, assuming I have understood anything I’ve read in here, it seems that
-The ESP formatting as Fat16 is an old (bug?) that has re-emerged.
-The contradictory warnings when forcing Fat32 manually can be safely ignored and wont cause problem down the line.
-The failed “alongside” install is unrelated to the ESP formatting.
-I can probably safely ignore this and move on to the next problem in order.

One question left, is it possible that a particular UEFI implementation on a particular motherboard series might cause problems with Fat16 on ESP?
I don’t think so, since the errors are thrown by Calamares, but I don’t know that Calamares isn’t pulling information from UEFI to do so. (This thread, along with other things I’ve read, seem to suggest it is possible)
Edit: Also, if this IS the case, is there any way I can check my own UEFI to see if it is causing problems?

EDIT: This whole question actually did have me in the

state for a while. I knew enough to know that messing with boot entries must edit something on ROM, which had me worried enough to spend a day or more reading up on bootloaders/managers and EFI in this.

16

I provided the link to that Issue upstream so you could get some history behind it. Using fat16is not a bug, and I use it for my 2GB USB stick all the time. There is no reason for something 2GB or smaller to have a fat32 filesystem just because it’s a fat32 filesystem (i.e. bigger number means better). There are no compatibility issues now or in the immediate future that will render anything using fat16 inoperable. I would be curious to hear what you are basing the information on.

See the previous paragraph.

Errors with live disks in the past have been related to ISO mastering and how the images are put onto a USB disk. We have a set of tools we suggest that people use. If you are making a disk in Windows, you can use Rufus, but you must use dd mode. If you are using Linux, we suggest you still use dd just so we know it wasn’t a bug in some other imaging tool. Ventoy has recently (within the past year) been fixed so that you can use it, but it should be a new version of Ventoy, and a recent ISO from ABF and not Sourceforge.

Anything outside of those very specific circumstances is most likely an issue with how your system is configured. Some common pitfalls would be, trying to use the same /home/ folder from a different distro (which you should not do because of permissions and compatibility), having exotic boot configurations such as encryption or multiple operating systems, or using file systems that are experimental such as btrfsor anything not part of the standard “Erase Everything” install scenario. Could you manually do things and be successful with all of these other configuration options? Yes, but we recommend you be more seasoned in Linux administration if you are going to take that on for your everyday system. Otherwise, you should try doing all of those things on a test system.

Finally, make sure any firmware is up to date. As I have stated in many other posts, we are using a newer kernel than most distros in all of our releases. If you are concerned about boot entries in UEFI being modified, that is a normal course of action, especially if you distro hop. efibootmgr is what I have used in the past to clean out old entries to systems I don’t use anymore that are always left behind when I change a distro.

To touch on some of your other, more personal points, we all have things that make us not perfect. That is what it means to be human. When I started learning computers and Linux, I was also worried about what might happen if I made a mistake. Well, I made mistakes and things happened. I wasn’t always happy with what happened, but I learned something in the process and that was the important part.

Getting lost in the anxiety is how you end up enslaved by it and unable to do anything at all. You are going to make a mistake. If you didn’t backup your system, you are going to lose data. It’s just how it goes. I reflect on my own failures by determining how important it will be in a year’s time. Then I develop how best to keep it from happening if the potential for it to happen is high. I have also worked on customer computers for long enough to know that it absolutely will happen again. There are just too many things and you won’t be able to plan for them all. Sometimes, you just have to roll with the punches and take a chance.

If the root of the problem pertains to the bootloader script, that has already been covered by the disk creation and exotic configuration section above. Could manufacturers cut out certain features? Probably not. I believe they still buy firmware chips from one of 3 manufacturers and have their branding and specific engineering inserted. It’s in the best interest of the firmware makers to produce something that doesn’t brick somebody’s PC in the future. FAT itself was evolved primarily to deal with growing storage capacities. The final thing I have to say about it, is there should be a choice that the user can make regarding which they use in order to address the possibility that some UEFI firmware may no longer support fat16, but I don’t see why they would not just use a general fat implementation since some SBC’s may not use significant storage.

17

Once again, I’m betting:

Try that

18

Heya @ben79, I owe you an absolutely massive thanks for this post. It has turned out to be, by far, the most important one in here.
Trying to answer those questions forced me to mentally step back from this “problem cluster”, and to get a little bit introspective.
Now, having also slept on it, I think I know why I’ve been so stuck on the whole thing for so long.

I had been treating this as one big project, something like
{Install ROME on my new pc and and use that process to also start “learning Linux”.}

I really need to separate this into two related, but distinct projects.
-Project A: {Get my new pc set up and operational.}
-Project B: {Improve my understanding of Linux as a whole, and how to effectively use it and troubleshoot.}

They need to be two separate projects for two important reasons.

1: The new pc is going to be my main pc/daily driver. It needs to be functioning and reasonably stable for other upcoming projects, as well as daily necessities. This means it has, inherently, a somewhat loose, but very real, time-limit.
“Learning Linux” on the other hand is inherently an open-ended project, ie. no specific time-frame.
This underlying contradiction left me in a mental loop where the sense of urgency wouldn’t let me relax enough to properly absorb anything I was reading, but the sense of not understanding things well enough wouldn’t let me “just try it and see if it works”. And so around and around in circles I went, getting more and more frustrated at not making progress which made it even harder to make progress.

-2: By combining the two goals mentally, I was also subconsciously treating these forums as more of a general “Linux support forum” than the “Open Mandriva Support/Forum” that they are intended for, and I think this was reflected in my posts, here and in Support, in spite of my best intentions to the contrary.
To make it worse I think my head was too far up its own a… butt, to pick up on any of the more-than-obvious hints that I was doing so.
That is sooo #### unfair on all of you guys, volunteers, its not funny.
I really can’t apologise enough for that.

I know myself well enough that I can’t promise I wont fall into similar mistakes again, but I CAN promise I will do my damnedest not to. If anyone notices that I am, please feel free to just tell me to pull my head in, as blatantly as possible so it actually sinks in.

That being said, I sort of hope it’s ok if I occasionally dropped a post in CoffeeBreak asking for clarification or resources for specific Linux/tech related topics in the future. I think I can trust the people in here enough to not steer me in wrong/harmful directions.

Thanks again @ben79, your questions in that post did more to get me on track than anything else.
And sorry for being so obtuse and taking so long to figure this out.

1 Like
19

Hey guys. Thanks for all the help and info you have given. It has/will prove useful.

I have read everything you have said, and linked to, but I have been so muddled, with this and everything over the last while, I don’t think I have properly absorbed much of it. And, to make things worse, as a result I think I was also really unclear with everything I tried to ask.

Rather than go over everything point by point, I will just ask for confirmation on one thing now.

Nothing about the ESP formatting mentioned in here is actually an issue, or problem, and should have no negative effects on an installed OS.
Correct?
EDIT: No need to confirm. The errors can be ignored, as @ben79 said it directly in here, and also in this thread (which I finally found again.)

As noted these warnings can be ignored, at least for me system installed normally.

And F16 vs F32 also makes no difference, as @zeroability said directly in here also.
End EDIT:

This means that, in terms of “Project A” (see above post) I can ignore this and move on.

As for “Project B”, I have bookmarked all (I think) of the links to the OM forum posts mentioned, including this one, and to the codeberg threads @zeroability linked above, so I can come back and go through them when I’m done with Project A.
I think I will start that process by digging into Fat, and file systems in general, since FS’s are sort of at the bottom of OS’s in general, unless I’m mistaken again.
The links in #607 - Suggest to format in fat32 in EFI mode - Calamares/calamares - Codeberg.org I think might be a good jumping-off point for that.

As for the actual error message I posted, it doesn’t really matter for project A since I only want to run ROME build 4292, by itself, on the new pc. At least for now.
I only did the “alongside mint” install out of curiosity, thinking it might be related to, or shed some light on, the question I posted. (Like I said, I really could/should have been clearer in the this thread in general).
I did considered briefly whether I should re-do that installation and gather the data/logs/screenshots etc needed to open a Support thread, just in case it might be useful for others later on, but going by @SomeDudeInAZ ‘s reply, and the thread he linked

It looks like it’s already a solved issue anyway.

@zeroability
The main site I was reading about UEFI and bootloaders/managers, outside of links from here, was this one.

Some of the pages in there are a little old (2018), but the most recently updated one was updated early 2024. And (unless the guy is full of ###) he wrote the rEFInd boot manager, so I figure he should know what he was talking about.
I have been using Ventoy mostly, with downloads from abf. And the Ventoy version is from about 6 months ago, so I don’t think it was related to the failed install. But I am definitely adding “looking into how Ventoy works more thoroughly” into my project B task-list.

Thanks again to all of you for your feedback on this, and sorry if I have wasted anybody’s time in here.

20

The bottom end of any OS is the kernel. It needs to set up communication with the hardware and enable access to things like the storage controller and many others. The storage controller has storage on it that is mapped out by a file allocation table (FAT). The kernel needs to know how the table is constructed in order to apply the data to the storage.

It’s important that no matter what you do or read that you have a realistic and understood goal, and that it can be stated simply. You can debate everything in the middle once that is established and as necessary. Ventoy should work in the majority of circumstances, but it is not how we recommend the live disk be created. We get that it’s more convenient to some that want to distro hop or have other tools at the ready. The best way to succeed at installing OM is to use a USB that has had the ISO imaged onto it with a utility that will apply the RAW image as is. That would be a utility that uses dd, does RAW writing in another way, or use dd itself. We have an entire section devoted to that in the wiki and here.