Puppy Linux Discussion Forum

Hi. First a number of apologies, and thanks.
@jamesbond please accept my apologies for the distraction of the ext4 filesystem questions at a time when you and the rest of the Fatdog Team are concentrating on Fatdog900Alpha. I hope I haven't "dropped you in it" with respect to the extra workload in answering queries in the Users area of the forum, as well as here. A very heartfelt thanks for your efforts in answering those queries so clearly, informatively, and helpfully. And yes, another apology for taking so long to do this.

I guess I should also provide an explanation for my uninformed concern with all this. Fatdog64 doesn't automatically mount swap (that can be modified, of course). If you are using a removable device, then you can remove it once FD has been loaded into RAM. If you have a hard drive partition setup with a multisession save, then the partition is not mounted (if you also have the zero save interval set in Fatdog64 Event Manager then you are also controlling any saves). This, to my mind, makes it an ideal option for modifying partitioning schemes and the like (and, of course, a whole lot more).

Apologies are also due to all who might have been misled by my thought that Debian 12's ext4 filesystem had the metadata_csum_seed attribute. I had been looking at so many tune2fs -l outputs that I obviously started to mix them up, and didn't verify things before posting.

You may want to skip the following- it is mainly just explanation, I guess.

Following a personal mini install fest, changing the system to UEFI only, running a memtest etc. I have finally reinstalled MX21.3 as the lead OS, rather than Debian 12. No matter what I have tried, using the 40_custom option under the Grub2 in Debian 12 leads to "out of memory" errors when attempting to boot Fatdog64. This includes FD813. I have a suspicion that the explanation and answer to these difficulties might lie in the Grub2 Manual, that I still have not read. Bad Baldric!
Anyway, after installing MX21.3 as "lead" again, all is back to normal. Debian 12 was also installed again (not as "lead"), and it was after this that I decided I should take another look re the filesystem. Sure enough, I had fouled it up again. When I checked the forum before making this post, further confirmation was found in the Users area of the forum. I hope no-one has been misled by my posts.

Fatdog64- 900 Alpha. There are now four (4) Fatdog64 "LimSav" (a term I tend to use for multi-session arrangements with a zero RAM save interval in Fatdog64 Event Manager) setups on the trial machine. FD813 and FD900Alpha (which is using the "coldplug" parameter) on an NVMe drive. And the same again on a spinning disk drive. Quick Setup has been used on both of the 900Alphas (an initrd that had already been localised was used in the 813s). The 900Alpha on the NVMe was used to create a localised intrd via the Fatdog64 Remaster Live-CD. Which worked on a FD813 "multiboot" usb-boot-mbr.img based USB drive. Subsequent to this, some service adjustments were made, and within the limits of what I can see, they have worked. The only service adjustment made on the 900Alpha on the spinning drive was to enable the numlock_on option.

Apologies again, I'm splitting this as it is just wasting your time. Thanks.

baldronicus wrote: Fri Jul 14, 2023 10:02 am

.No matter what I have tried, using the 40_custom option under the Grub2 in Debian 12 leads to "out of memory" errors when attempting to boot Fatdog64.

Are you using the full initrd or the initrd-nano? I could not get recent Fatdogs to boot with the full initrd, even on machines with 8GB RAM.

Hi @rcrsn51 . I was using the normal humongous initrd. I have a suspicion that I might have unsuccessfully tried a nano-initrd approach on one occasion with Debian 12, before I cleared the system, yet again, and started over. As I have thought about it more, I don't think it is a reflection on Debian 12 (not that I had really initially thought of it that way either, although my post might have read that way). I just suspect that I need to read more about the Grub2 changes.

There are other smaller initrd boot options that I could have also tried. Step and Jamesbond had been assisting Tatemono with a similar problem, I think, in this thread viewtopic.php?p=93482#p93482

Returning to the use of MX21.3, which is, if my understanding is correct, based to a considerable extent on Debian 11, restored things to a normal working situation, and I could boot the humongous initrd without difficulty on this machine (which co-incidentally does just have 8G of RAM). I think things would have been just as successful as they are with MX if I had used Debian 11 [Edit- from a later test they were not. From the result, and info that Jamesbond has referenced below, it would appear that the MX developers might enable an option for larger initrd support in Grub2, that the Debian developers do not- don't rely on what I write, I could be mixing things a bit, and I am only going off the result]. Being lazy, I tend to give MX the lead as it has, by default, a Memtest option in it's boot parameters.

Although it is true that I should probably have persisted in trying to find a working solution, things were just getting messier and messier, and I really just wanted to get back to trying things with Fatdog64 900Alpha, so I just went back to what had been working.
Which isn't helpful for others, I know.
Thanks.

Hi again. More pain and suffering for you, I'm afraid. I was going to post about this last night, but, after my error with the tune2fs -l effort, regarding Debian 12's ext4 filesystem, I thought I should check things again first.

I thought I would try accessing a Debian 12 encrypted LVM, and other, encrypted, partitions, using the drive icons.

After some refreshing, regarding both encryption and LVM access, when using Fatdog64 (including referencing some off-line extracts of posts made by JakeSFR, that I had kept), access to a test Debian12 encrypted LVM worked. Note that accessing, and leaving, the LVM does involve using some terminal commands.

Two encrypted partitions were set up, one using Fatdog64 813, and one using Fatdog64 900 Alpha. The icon access approach worked with both, thank you.

I was a bit rusty, as I don't have much cause to use this approach via Fatdog64. However, it is very nice to know that these very neat options are available (especially if the case should arise that access to an encrypted back-up might be needed).

Then I thought I would check what would happen if I tried to access the ext4 filesystem on the encrypted partition created by FD900Alpha, using FD813, fully expecting it to fail. However, it worked. Which confuses me. So it turns out that I am still not getting away from the filesystem questions .

Following the above mentioned mess up, I thought that I should check things before posting.

A test ext3 partition was set-up using FD900Alpha. Using mkfs.ext4, an ext4 filesystem replaced the ext3 one. As expected, it has the metadata_csum and metadata_csum_seed attributes.
I then tried tune2fs -l on /dev/mapper/dmcrypt-sda6 (the FD900A encrypted partition). As expected, the filesystem had both the metadata related attributes.

A test text document was put on the filesystem. I then rebooted and went into FD813. I opened the encrypted filesystem, clicked on dm-0 to mount the underlying (if that is the correct expression) filesystem, and it worked. Further, I could access the document, and modified it, to check if that held.

After unmounting and closing things in FD813, I rebooted into FD900Alpha, accessed the partition, and the document, and the modification had worked.

Do filesystems on Device Mapper volumes (for want of the correct term) behave differently than "normal" filesystems?
In a way, I realise that there must be differences, but this seems strange.

If it is any consolation, I have been trying other stuff, but my posts just get too long. Thanks.
Thanks again

rcrsn51 wrote: Fri Jul 14, 2023 2:40 pm

baldronicus wrote: Fri Jul 14, 2023 10:02 am

.No matter what I have tried, using the 40_custom option under the Grub2 in Debian 12 leads to "out of memory" errors when attempting to boot Fatdog64.

Are you using the full initrd or the initrd-nano? I could not get recent Fatdogs to boot with the full initrd, even on machines with 8GB RAM.

@rcrsn51, In addition to what Baldric said:

If you're using Grub2, you probably hit Grub2's infamous 462 MB initrd limit. I posted a message about it in the old forum.

@baldronicus, I'm not surprised. Fatdog64-813 should have no problem at all accessing the partitions created by 900A. The kernel of 813 is of mature enough age (it has 5.19.4 kernels), the tools of 813 are mature enough (e2fsprogs 1.43). So, data exchange is not a problem. In fact, I checked that the first release of Fatdog64-800 already comes with kernel 4.19.24, so it shouldn't be a problem for it as well (metadata_csum_seed feature was introduced in kernel 4.4.x). The data exchange problem is probably more applicable for older releases (of Fatdog, and of Puppies).

The only problem is the bootloader: bootloaders installed by 813 (and earlier) cannot boot partitions created by 900A. This, obviously, is only a problem if you use bootloaders installed by 813. In your case, you use MXLinux's bootloader so the situation does not apply directly (what you need to be wary of - and you have done diligent tests on this - is whether the bootloader of your "lead" distro supports the new ext4 features, and so far you seem to have mixed results).

Hope that clears the air.

Hi @jamesbond . Thank you. It is good that you have such a clear head, and knowledge to see through all this.
I should have realised, as you had already mentioned this in earlier threads (and in the Users forum area, even emphasising the specifics of the situation), and I had already been checking filesystem access, D'oh . I'm just mixing all of this in my head, and running off on tangents.

Thank you again, and I hope you will accept my apologies for taking your time with something that, well "it is known John Snow" (if that is the right quote).

[Edit- As I was mixing too many things, I have tried to separate what was the rest of this post, which concerned difficulties in booting Fatdog64 with Debian, into another thread viewtopic.php?p=94137#p94137. Hopefully, this is OK, although I am not sure that it is the correct approach. The rather pointless waffle was largely incorrect, and has been superseded, anyway. ] Thanks.