FD900Alpha-MXLinux21.3 40_custom boot problem [Solved]

[baldronicus]

Hi. Thank you @jamesbond for your reply in the ext4 query thread, and the info that it contained.

[EDIT- The result regarding this has been given in the next post, since both posts are overly large. Please let me know if most of this post should be culled. Thanks.]

I am making this post a bit too early, as there is more that I need to check (more still after your abovementioned reply ). However, I thought it was best to mention the problem, even though I need to do more checking and reading (including the grub2 manual that you kindly linked to when assisting Keniv).

I think it might be a bit early to consider this a real problem at this stage, but I thought I should mention some stuff whilst I could still think of it.

The version of GParted available in Fatdog64-900Alpha was used to generate an ext4 partition on a trial machine I am using (please note that I have only used the one machine so far).
An earlier partition that had been generated the same way was able to be mounted by the MXLinux 21.3 kernel (as expected) and MX was used to put a test document on the filesystem, that was subsequently used to test the access for various Puppies. That partition was subsequently deleted, and after a few other changes, the new partition was created in a different location on a spinning hard drive.

The kernel, initrd, fatdog.png and version files were copied across to the new partition, and an existing 40_custom file, in the MX installation, was modified to boot Fatdog64 900Alpha. The boot was unsuccessful, with the kernel not being able to be found.

As a test, another partition was created using the GParted variant from Fatdog64-813, and the same files copied to that partition. The stanza in the 40_custom file that had failed (which itself was a modified copy of an existing stanza) was copied and modified to boot from the new partition. The boot was successful.

With me there are many variables, I may even have an unnoticed space in the 40_custom file, but I have tried to check for that.

My suspicion is that although the MX Linux kernel can access the partition, the Grub2 may not be able to. Which leads me to suspect a missing option that I haven't included in 40_custom file (or maybe the opposite, I might have something there that shouldn't be). I also tend to use labels, and I haven't yet tried it using a UUID, to see if that is the problem. I haven't, of course, yet tried another partition with the tune2fs modifications that you mentioned in the other thread. I also vaguely seem to recall seeing mention of Orphan information when I had checked the earlier (now deleted) partition, with tune2fs -l. However, I suspect that was provision for orphaned inodes(?), rather than an indication of a problem. As an unrelated aside I think the 64bit option might have also been excluded (as is also the case in 813, I think, now that I look).

I will try to attach a copy of the 40_custom text, in case it might be helpful later. If I can't identify the problem, would posting a copy of the tune2fs -l result for the partition be helpful? If so, should any info from that e.g. checksum seeds etc., be deleted first?

Thanks and apologies for another tome that may be about nothing. I am posting way too early.

[baldronicus]

Hi again.

I feel it is important that the point is made that this problem is not a bug in, nor in any other way a reflection on, Fatdog64-900 Alpha.
It is just that this the first time I have personally come across this (others are probably more advanced, and I am behind the times).
As had been pointed out by @jamesbond in the ext4 related thread, the changes are coming from upstream, so they are going to have a wider impact/influence.
It is just a usage issue that we may have to adapt to, dependent on how we do things. It also, of course, needs to borne in mind that it only relates to ext4 filesystems.

It appears that the boot problem was related to the newer ext4 filesystem attributes that are now being fully enabled (if that is the right way to put it). In this case specifically metadata_csum_seed.

The MX Linux 21.3 64 bit kernel (5.10.0.0-20-amd64) fully supports these features and can mount ext4 filesystems that are using them.

However, the filesystem that this version of MX is using has metadata_csum, but not metadata_csum_seed.

Although I don't know, I suspect that the MX related Grub2 might have been loading the ext4 filesystem information from elsewhere in the filesystem, since I don't think it would load the MX kernel during the boot process. From this information it couldn't mount the ext4 filesystem that I had generated using the GParted in Fatdog64-900 Alpha.

Using an ext4 partition created using the GParted version in Fatdog64-813 worked, and booted Fatdog64-900 Alpha with no problem. As did using an ext3 partition generated using the GParted in 900Alpha. Similarly, creating an ext4 filesystem using 900Alpha, but without the metadata_csum_seed attribute (if that is the correct term) worked fine.

We all use different boot methods/setups, and general arrangements.

If you do use a "lead" boot distro (on ext4) approach, and are intending to install a newer distro, then it might be better to give the new one the lead, as I think it will still boot the earlier distros you might be running, but, perhaps, not vice-versa.

[Edit- Made after @jamesbond 's reply below, edited rather than a new post, as I don't want to mess up the important info regarding the FD64-814 bootloaders that he has given- As usual I missed something. I had forgotten that MX21.3 had booted Debian 12.0.0-amd64. [Another edit- A check of the attributes of the ext4 filesystem of a Debian 12.0.0 installation made today (14 July) (albeit after some system changes, e.g. going to UEFI only), indicates that it doesn't have the metadata_csum_seed attribute. That is, it is similar to MX. Hence no wonder MX could boot it. As the text that followed was just pointless speculation about a situation that wasn't there, I am deleting it.]

Another consideration here might be the news (in the Debian 12.0.0 Release Notes, and then confirmed as being wider, in the Grub2 Manual document Jamesbond linked to) of the Grub2 Os-Prober being disabled. (I have an idea that I might need to try to learn something, rather than just using "monkey see- monkey do" ).

The trial machine- I have lost the plot (yeah, I know it was already gone) with the number of partitions I set up. I think I will "ground zero" everything, install Debian 12.0.0 as the "lead", and go from there. [Edit- Not a good move move in my case. After attempting to battle with Debian 12.0.0-amd64 using 40_custom entries to attempt to boot Fatdog64s (and ending up with only "out of memory" failures), I have gone back to MX21.3 as "lead".
I was tired when trying some of the stuff, and maybe I have misjudged what I have thought I had seen, but I feel like the ground just keeps shifting with Debian 12.0.0 in relation to this stuff. Of course, it is the initial release, and the first with (maybe, perhaps) Os-Prober disabled (another thing that has shifted- I could have sworn the messages were indicating that it wasn't going to run, then a warning message this morning that it was). Perhaps it is just me, or I have messed up the USB drive in some way. I remember that I had checked the download sha256sum and it was fine. Still running with Debian 12, of course. Just not as lead. I think I will wait for 12.1 before committing too heavily, though. ][Yet another edit- while the ground felt like it was shifting I think it might have been external factors that might have influenced this. Principle among them could have been the nut at the controls . Thinking on things a bit, I suspect that an explanation for the failures to boot Fatdog64 via the 40_custom option might lie in the Grub2 Manual, which I still haven't read.
The answer regarding the apparent change in behaviour might be found there too. I had installed rEFInd after reinstalling MX21.3 as "lead". In order to access Debian's Grub2 so that I test booting Slacko64-7.0 and have another go at FD64-813 on an "older" ext4 partition I booted Debian using rEFInd. This took me to Debian's Grub2 menu, but it was not being used as the "lead" Grub2, so to speak. Maybe it's behaviour adapts? Anyway, I think I really need to settle down to some reading. ]
Thanks, and apologies. I can never be concise.

[jamesbond]

Thanks for extensive tests, @baldronicus. I think your informative post will be useful not only for Fatdog64 users but also for others who combine newer and older Puppies (and other Linux OS).

Commenting on your point here:

Although I don't know, I suspect that the MX related Grub2 might have been loading the ext4 filesystem information from elsewhere in the filesystem, since I don't think it would load the MX kernel during the boot process.

You're quite right, it does not.

The kernel, the bootloader (grub2), and the userspace tools (tune2fs, mkfs.ext4, etc) are three different set of programs, __independent__ of each other. Each have its own mechanism to read and understand the filesystem (the userspace and the grub2 does not depend on the kernel to do that). For the system to boot, all of them must understand the filesystem being used.

Your post confirms that while MX21 kernel and userspace has no problem accessing the ext4 with the new feature, its boot loader (grub2) that gets installed by MX21, is not. This is nobody's fault; it's just the price of progress. One can't use an old wineskin to keep a new wine, so to speak; but as you said, one has to be aware of this problem before one can find a solution for that.

For the record, MX21 grub2 bootloader isn't the only one with the problem. Boot loaders installed by Fatdog64 813 (and older) will fail exactly for the same reason. For 814 release, we have updated the bootloaders and they would work with partitions created by 900.

cheers!