MX21.3-Debian11.2 and 12-Fatdog64 [Solved]

versatile 64-bit multi-user Linux distribution

Moderators: kirk, jamesbond, p310don, JakeSFR, step, Forum moderators

Post Reply
baldronicus
Posts: 80
Joined: Sat Aug 29, 2020 6:55 am
Has thanked: 41 times
Been thanked: 15 times

MX21.3-Debian11.2 and 12-Fatdog64 [Solved]

Post by baldronicus »

Hi @rcrsn51 . As I was mixing things up too much in the other thread viewtopic.php?p=94056#p94056 , I thought I should report this here.

Once again Baldrick presumes something, and he is wrong.

I thought I should check how Debian 11.2.0-amd64 went with booting Fatdog64 on the trial machine.

After some false starts, I finally installed Debian 11.2 as "lead" on this machine, and tried booting Fatdog64-813. The result was an "Out of memory" failure again.

Given that this was the first time that I had run into this problem, and that it was coinciding with the disabling of OS-Prober, I, once again, incorrectly associated the two, and thought that only Debian 12 would be affected. As usual, Baldrick jumps to a completely baseless presumption, that is wrong.

Although I knew that the Antix and MX developers make modifications from Debian, I didn't think of the Grub2 configuration as being one of them.
Obviously they have modified things in a similar way to the adjustments made by the Fatdog Team, as per the info in the link to the old forum, that @jamesbond has kindly provided in the other thread viewtopic.php?p=94043#p94043 .

When I think about it, MX does have the persistent USB option, but I don't know how that would relate to the initrd, nor whether that might be an influencing factor in their increasing the initrd memory limit in Grub2.

It could be that Debian has just never had cause to consider modifying things to increase the initrd memory limit (if that is the right description).

If my understanding regarding this is correct (and that is a big if), it wouldn't matter if one was running a machine with 128gig of memory, the "out of memory" issue, booting a Fatdog64 humongous initrd, would still arise, if the Grub2 initrd memory limit had not been modified in the "lead" OS.

In any event, it appears that my tendency to use MX as "lead" (due to the ready availability of Memtest) has also been shielding me from this issue.

So yet another reason for trying to read more.

Thanks, and apologies to both yourself and Jamesbond.

[Edit- the following has been taken from this thread viewtopic.php?p=94056#p94056. I hope this is OK. I thought I should try to tidy things up a bit, but I am probably going about it the wrong way. It predates the text above, and it is really redundant waffle, that doesn't help.

Hi again also rcrsn51 . There are some other things that have come to mind that I hadn't posted about.
I went "cowboy" and installed rEFInd using the installer included with Fatdog64 (not the boot image), before reading the html documentation (but I did read the Readme, sort of). Hence I haven't set things up for directly booting Fatdog64, yet.

However, it did detect MX Linux well, and then Debian 12, when I installed it (I suspect via the entries in the EFI partition). The first Debian install involved a boot partition and an encrypted LVM, which, of course would not normally be detected by Grub2 Os-Prober (which was neat). The second Debian install, a "normal" installation, ended up with the files in the debian sub-directory on the EFI partition being overwritten with the later files (as expected).

This has the advantage that I can still boot into the new Debian 12 Grub2 without it affecting the main MX Grub2 based boot loader configuration.

Indeed, and this is one of the bits that am taking a long time to work up to . Slacko64-7.0 and Fatdog64-813 were "installed" to ext4 filesystems created using the GParted in Fatdog64-813 (i.e. without the new attributes, or, at least not metadata_csum_seed). Debian 12 was booted via the Debian 12 Grub2 that rEFInd loaded. When I ran update-grub, to pick up the updated 40_custom, a warning message came up after the initial load of Debian's own details, indicating that Os-Prober would be run. That is, not the usual warning that it won't be run. I presume the behaviour might depend on where Grub2 might be being run from, since the MX Grub2 menu was not impacted.

When boots were attempted, Slacko worked, but Fatdog64 had the out of memory issue, as expected. But I do have a means of trying further smaller initrd tests. ]

[The following is all wrong. I have left it as an indication of how uninformed I am, although I am inclined to delete it to save forum space.
A bad tendency that I have is to try to ponder things that I have no knowledge of, so please treat the following with the suspicion it deserves. Again, a reminder that I haven't yet read the Grub 2 Manual.

Given: a) that both Fatdog64-813 and 900Alpha can be booted, using this machine, with the humongous initrds, if they are on the "older" ext4 filesystems, using the earlier Grub2 in MX Linux 21.3,
b) having Os-Prober function (but perhaps not fully) in the latest test with Debian 12 (where it was not "principal" boot loader), but still resulting in a failed Fatdog64 boot,
c) the information in Jamesbond's post above, regarding the earlier Grub 2 limit,
could the Grub 2 developers, or perhaps, the Debian developers, have reverted to an earlier version (under the hood), or maybe earlier specifications, when changing the Os-Prober behaviour?
Another thought is whether something in "update-grub" might have been hobbled as part of, or as a side-effect of, the Os-Prober change?

Unhelpful speculation, I know. Thanks. ]

Post Reply

Return to “FatDog64”