Booting from refind, how to choose boot options?

[libertas]

Hi,

I used the suggestion from the other thread viewtopic.php?t=11632 about configuring refind.conf.
FatDog boots fine, but as is there's no option for me to choose to load the savefile/dir or not.
It seems that refind should load isolinux.cfg or some grub config file.

The current refind.conf configuration is:

Code: Select all

menuentry "Fatdog64 Linux 901" {
    icon /EFI/boot/icons/os_fatdog.png
	volume FATDOG_LIVE
	loader /FD901/vmlinuz
    initrd /FD901/initrd
    options "savefile=ram:uuid:b8bbd0b9-39a5-4341-b724-1b55eaf1e135:fd64save waitdev=5" 
}

Is the way to go to change that 'options...' line to 'savefile=ask'?
Or can rEFInd chain boot to isolinux or some grub file.
I really don't like grub2, maybe rEFInd could chain the boot process to grub4dos.

[libertas]

Forgot to say that as of now, when shutting down or rebooting, there's no option for me to choose between saving or not saving to the savefile/dir.
When using the default ISO this option used to prompt me.
How can I enable this?

[jamesbond]

Is the way to go to change that 'options...' line to 'savefile=ask'?

Yes, or just remove the savefile=XXX altogether.

Or can rEFInd chain boot to isolinux or some grub file.
I really don't like grub2, maybe rEFInd could chain the boot process to grub4dos.

rEFInd doesn't understand isolinux or grub configuration file, but if you disable secure boot, then yes you can chain to grub4dos, but you need to use special version of grub4dos: the UEFI version. For example, from here: https://github.com/chenall/grub4dos/rel ... g/for_UEFI

Forgot to say that as of now, when shutting down or rebooting, there's no option for me to choose between saving or not saving to the savefile/dir.
When using the default ISO this option used to prompt me.
How can I enable this?

Fatdog will not ask this question when it thinks that the savefile has been set up. This happens when you specify "savefile=xxxx" as the boot parameter. Remove it, and Fatdog will ask you again.

[libertas]

Forgot to say that as of now, when shutting down or rebooting, there's no option for me to choose between saving or not saving to the savefile/dir.
When using the default ISO this option used to prompt me.
How can I enable this?

Fatdog will not ask this question when it thinks that the savefile has been set up. This happens when you specify "savefile=xxxx" as the boot parameter. Remove it, and Fatdog will ask you again.

Is it possible to load the savefile/dir only after the system has booted?

[libertas]

Another question.

I could boot from rEFInd as suggested by @smokey01 using the FATDOG_LIVE uefi vfat formatted partition, like so:

Code: Select all

menuentry "Fatdog64 Linux" {
    icon /EFI/boot/icons/os_fatdog.png
    volume FATDOG_LIVE
    initrd \FD901\initrd
    loader /FD901/vmlinuz
}

Then, I tried to boot from the second partition of the USB stick.

I moved the FD901 folder from the vfat formatted /dev/sda1 to the ext4 formatted /dev/sda2.

Named the GPT partition (that I think it's not necessary) and the filestystem label of /dev/sda2 to PUPPIES (in upper case), although I've tried in lower case as well. As stated in https://wiki.archlinux.org/title/Persis ... g#by-label

Code: Select all

# ls -l /dev/disk/by-label/  | grep sdb
lrwxrwxrwx 1 root root 10 May 26 23:27 FATDOG_LIVE -> ../../sda1
lrwxrwxrwx 1 root root 10 May 26 23:27 PUPPIES -> ../../sda2

Tried the initrd with forward and back slashes.

Code: Select all

menuentry "Fatdog64 Linux" {
    icon /EFI/boot/icons/os_fatdog.png
    volume PUPPIES
    initrd \FD901\initrd
    loader /FD901/vmlinuz
}

I cannot find a way to boot FatDog from the ext4 second partition.
The fatdog image shows up, so it's reading from the vfat UEFI sda1 partition, but when I press enter, it briefly shows a screen with a blue line that seems to say "refind booting".
But promptly returns to the fatdog uefi screen and image.

Am I doing anything wrong?
Or what should I change to be able to boot from the larger sda2 ext4 partition?

[jamesbond]

If you're running Fatdog64, copy /usr/share/refind-bin-0.13.3.1/refind/drivers_x64/ (the entire folder) to /EFI/Boot (in your vfat formatted partition), then try again. If you're not running Fatdog64, you can find the same drivers_x64 folder inside efiboot.img.

[LateAdopter]

Or can rEFInd chain boot to isolinux or some grub file.
I really don't like grub2, maybe rEFInd could chain the boot process to grub4dos.

rEFInd doesn't understand isolinux or grub configuration file, but if you disable secure boot, then yes you can chain to grub4dos, but you need to use special version of grub4dos: the UEFI version. For example, from here: https://github.com/chenall/grub4dos/rel ... g/for_UEFI

The refind documentation warns you that a PC BIOS does not support chainloading a Bios boot sector bootloader but a Mac BIOS does support it.

If you ask refind to chainload Grub4DOS it adds an entry to the NVRAM and restarts so that that entry gets used.

When I tried that, the new entry broke the BIOS boot menu so that it didn't work at all! It was necessary to find another way to start in EFI mode so that I could run efibootmgr to delete the offending entry.

Warning! There is no master reset for the NVRAM so it is possible to break a PC permanently by writing a buggy driver to it.

Grub4DOS-UEFI is really simple for normal booting, without secure boot. The menu.lst entries are the same as for Gru4DOS. It can boot from EXT4 without any extra drivers. You just have to put its BOOTX64.EFI in the proper place.

You need a version that is less than four years old so that it can handle the Fatdog initrd size.

[Clarity]

Would an upgrade to Grub2 (now version 2.12) address this discovered issue for this PC's newer hardware?

Reason asked: This started with a report when v901 was booted on this PC. Then, the approach being used to address the problem via a circumvention to the normal boot.

I have reported success on older hardware with EVERY launcher on this forum and have booted v901 via the 2 PXE methods available without issue. Then this newer PC has issues.

That why I am asking: Is it possible with GRUB2 being upgraded to the latest version from the current version, this PC issue disappears.

Lastly, since GRUB2 continues to keep up with all hardware platforms, aggressively with PC manufacturers contributions, is it time to move on from GRUB4DOS to reduce developer workload a little?

[libertas]

If you're running Fatdog64, copy /usr/share/refind-bin-0.13.3.1/refind/drivers_x64/ (the entire folder) to /EFI/Boot (in your vfat formatted partition), then try again. If you're not running Fatdog64, you can find the same drivers_x64 folder inside efiboot.img.

The two locations provide different sets of drivers.
While the first one has no ntfs driver, the second one has a ntfs driver.

Tried to boot with both sets of drivers, but the system didn't boot.
It advances from the fatdog image to a black screen saying:
a blue line: rEFInd booting OS
Starting vmlinuz
Using load options 'initrd=\FD901\initrd'

But stays there.

[libertas]

I tried all these options:

Code: Select all

menuentry "Fatdog64 Linux" {
    icon /EFI/boot/icons/os_fatdog.png
    volume PUPPIES
    initrd /FD901/initrd
    loader /FD901/vmlinuz
}
menuentry "Fatdog64 Linux1" {
    icon /EFI/boot/icons/os_fatdog.png
    volume PUPPIES
    initrd \FD901\initrd
    loader /FD901/vmlinuz
}
menuentry "Fatdog64 Linux2" {
    icon /EFI/boot/icons/os_fatdog.png
    volume PUPPIES
    initrd initrd
    loader vmlinuz
}
menuentry "Fatdog64 Linux3" {
    icon /EFI/boot/icons/os_fatdog.png
    volume PUPPIES
    initrd /initrd
    loader /vmlinuz
}
menuentry "Fatdog64 Linux4" {
    icon /EFI/boot/icons/os_fatdog.png
    volume PUPPIES
    initrd \initrd
    loader \vmlinuz
}
menuentry "Fatdog64 Linux5" {
    icon /EFI/boot/icons/os_fatdog.png
    volume FATDOG_LIVE
    initrd \FD901\initrd
    loader /FD901/vmlinuz
}

Only the last one, booting from the EFI partition works.
There must be some problem regarding the ext4 driver.
Boots from sda1, not from sda2.

Code: Select all

# mount | grep sda
/dev/sda1 on /mnt/sda1 type vfat (rw,relatime,fmask=0027,dmask=0027,codepage=437,iocharset=iso8859-1,shortname=mixed,quiet,utf8,errors=remount-ro)
/dev/sda2 on /mnt/sda2 type ext4 (rw,relatime)

# tree /mnt/sda2/
/mnt/sda2/
├── FD901
│ ├── initrd
│ ├── java-jdk-22.0.1+8-x64.sfs
│ └── vmlinuz
├── initrd
├── java-jdk-22.0.1+8-x64.sfs
├── lost+found
└── vmlinuz

Code: Select all

# ls -l /dev/disk/by-label/ | grep sda
lrwxrwxrwx 1 root root 10 May 28 19:11 FATDOG_LIVE -> ../../sda1
lrwxrwxrwx 1 root root 10 May 28 19:11 PUPPIES -> ../../sda2

[smokey01]

@libertas it really has me stumped as well. As per your first option I have it working this way on an old and a new laptop from their internal hard drives. The same setup on a flash drive will not work. It's like it doesn't recognise the volume, label name, of the second ext4 partition. Like you it works fine if all files are on the first Fat32 partition. Maybe it needs to be vfat and not Fat32 on the flash drive although it doesn't seem to matter on internal HDD/SSD. My 32GB USB came formatted at Fat32 so I never changed it.

@Clarity we are trying to boot directly with refind and not use GRUB2 at all. Why use a boot loader to load another boot loader. Each has different strengths and weaknesses.

[libertas]

I asked a question some posts before that got forgotten.
Is it possible to load a savefolder or save file after the boot has been done?
Since this is the upper layer, it probably is.
So, to rephrase, is there a tool to do this?

[libertas]

@libertas it really has me stumped as well. As per your first option I have it working this way on an old and a new laptop from their internal hard drives. The same setup on a flash drive will not work. It's like it doesn't recognise the volume, label name, of the second ext4 partition. Like you it works fine if all files are on the first Fat32 partition. Maybe it needs to be vfat and not Fat32 on the flash drive although it doesn't seem to matter on internal HDD/SSD. My 32GB USB came formatted at Fat32 so I never changed it.

Tommorrow, I'll try with the second partition formatted to other filesystems.
Thanks smokey01.

[Clarity]

@Clarity we are trying to boot directly with refind and not use GRUB2 at all. Why use a boot loader to load another boot loader. Each has different strengths and weaknesses.
Top

I know what you are trying. But I also know what our Linux world offers for our use that attempts to eliminate boot-time issues with these various hardware platforms. Further, I have tested successfully using how FD v901 is successful in booting in ALL the varied bare-metal and VM environments including PXE methods using the GRUB2 in its current version. Thus if a mere upgrade addresses the current condition, would it be reasonable?

Again I ask, would GRUB v2.12 have the intelligence to provide the relief that is seeked? If so, should it be a solution to alleviate future similar issues?

This IN NO WAY attempts to undermine or change the work efforts we are all trying to contribute in our efforts in this thread. So this post is merely intended to address this and future directions for FATDOG to continue its ability to boot in ALL the currently platforms we know it boot in by considering if an update addressing THIS problem with its current hardware and other future hardware we will see.

BTW: I have not seen or found harm in GRUB2 use with FATDOG or any distros...even those which also use reFind as FD does too.

I hope this was viewed as merely an idea.

[smokey01]

@Clarity we are trying to boot directly with refind and not use GRUB2 at all. Why use a boot loader to load another boot loader. Each has different strengths and weaknesses.
Top

I know what you are trying. But I also know what our Linux world offers for our use that attempts to eliminate boot-time issues with these various hardware platforms. Further, I have tested successfully using how FD v901 is successful in booting in ALL the varied bare-metal and VM environments including PXE methods using the GRUB2 in its current version. Thus if a mere upgrade addresses the current condition, would it be reasonable?

Again I ask, would GRUB v2.12 have the intelligence to provide the relief that is seeked? If so, should it be a solution to alleviate future similar issues?

This IN NO WAY attempts to undermine or change the work efforts we are all trying to contribute in our efforts in this thread. So this post is merely intended to address this and future directions for FATDOG to continue its ability to boot in ALL the currently platforms we know it boot in by considering if an update addressing THIS problem with its current hardware and other future hardware we will see.

BTW: I have not seen or found harm in GRUB2 use with FATDOG or any distros...even those which also use reFind as FD does too.

I hope this was viewed as merely an idea.

@Clarity it works fine with grub2 and I have no issues with it. It's actually handy being able to boot grub from refind as no boot sectors need to be touched, which I think is a good thing.
If it was easy everyone one would be doing it, pun intended. We are trying to make it easy just to use refind as it is prettier, not important to me but is to many. It also speeds the boot process, which is important to me.
Thanks for your input as it's all useful.
I just can't seem to work out why the exact same setup on a HDD or SSD works fine but not on a USB flash drive.
When I get out of hospital I might try it on an external USB SSD.

[jamesbond]

The two locations provide different sets of drivers.
While the first one has no ntfs driver, the second one has a ntfs driver.

Indeed. They're from different versions. The ones from efiboot.img are usually older, but when I remember I update them from time to time. You can try either ones.

But please DO NOT don't use the ext4_x64.efi, use ext2_x64.efi instead. Don't even have both inside drivers_x64, because it will only confuse rEFInd. The ext2_x64.efi (if it works) should handle ext2/3/4.

Only the last one, booting from the EFI partition works.
There must be some problem regarding the ext4 driver.
Boots from sda1, not from sda2.

Code: Select all

# mount | grep sda
/dev/sda1 on /mnt/sda1 type vfat (rw,relatime,fmask=0027,dmask=0027,codepage=437,iocharset=iso8859-1,shortname=mixed,quiet,utf8,errors=remount-ro)
/dev/sda2 on /mnt/sda2 type ext4 (rw,relatime)

Indeed. The first entry should have worked - that's how mine and @smokey01's are configured.
Can you please post the result of running:

Code: Select all

dumpe2fs /dev/sda2 | grep features

I asked a question some posts before that got forgotten.
Is it possible to load a savefolder or save file after the boot has been done?
Since this is the upper layer, it probably is.
So, to rephrase, is there a tool to do this?

No, sorry, it's not possible.
Exactly because it is the upper layer that it cannot be changed.
You can only change the lower layers.

Well, that's actually a lie.
The truth is, there is actually a way to change the upper layer,
but it involves bringing down a lot of things to the point that it's not worth it.
You'd be better off doing a full reboot instead.

When I get out of hospital I might try it on an external USB SSD.

@smokey01 - Please take care. I hope you get better soon.

Again I ask, would GRUB v2.12 have the intelligence to provide the relief that is seeked?

I'd like to update grub2 as well, but it's easier said than done.

[Clarity]

Thanks @jamesbond

...it's easier said than done.

YES, I know; as it seems to best be done during a build.

[libertas]

The two locations provide different sets of drivers.
While the first one has no ntfs driver, the second one has a ntfs driver.

Indeed. They're from different versions. The ones from efiboot.img are usually older, but when I remember I update them from time to time. You can try either ones.

But please DO NOT don't use the ext4_x64.efi, use ext2_x64.efi instead. Don't even have both inside drivers_x64, because it will only confuse rEFInd. The ext2_x64.efi (if it works) should handle ext2/3/4.

There's no ext4_x64.efi at /EFI/boot/drivers_x64, only the ext2_x64.efi.
So, the problem is not caused by a ext4_x64.efi file.
The contents of /EFI/boot/drivers_x64 are:

Code: Select all

btrfs_x64.efi
ext2_x64.efi
hfs_x64.efi
iso9660_x64.efi
ntfs_x64.efi
reiserfs_x64.efi

Only the last one, booting from the EFI partition works.
There must be some problem regarding the ext4 driver.
Boots from sda1, not from sda2.

Code: Select all

# mount | grep sda
/dev/sda1 on /mnt/sda1 type vfat (rw,relatime,fmask=0027,dmask=0027,codepage=437,iocharset=iso8859-1,shortname=mixed,quiet,utf8,errors=remount-ro)
/dev/sda2 on /mnt/sda2 type ext4 (rw,relatime)

Indeed. The first entry should have worked - that's how mine and @smokey01's are configured.
Can you please post the result of running:

Code: Select all

dumpe2fs /dev/sda2 | grep features

Sure, here it is, now as sdd2:

Code: Select all

# dumpe2fs /dev/sdd2 | grep features
dumpe2fs 1.47.0 (5-Feb-2023)
Filesystem features:      has_journal ext_attr resize_inode dir_index orphan_file filetype needs_recovery extent flex_bg metadata_csum_seed sparse_super large_file huge_file dir_nlink extra_isize metadata_csum orphan_present
Journal features:         journal_incompat_revoke journal_checksum_v3

I asked a question some posts before that got forgotten.
Is it possible to load a savefolder or save file after the boot has been done?
Since this is the upper layer, it probably is.
So, to rephrase, is there a tool to do this?

No, sorry, it's not possible.
Exactly because it is the upper layer that it cannot be changed.
You can only change the lower layers.

Well, that's actually a lie.
The truth is, there is actually a way to change the upper layer,
but it involves bringing down a lot of things to the point that it's not worth it.
You'd be better off doing a full reboot instead.

I got it totally wrong, then.
Though it as a stack, that the upper layer could be removed or added with no interference with what is below.

When I get out of hospital I might try it on an external USB SSD.

@smokey01 - Please take care. I hope you get better soon.

@smokey01
Be careful, the medicine from the Rockfellers don't want our good, only our money!
Hope you get healthy!

Again I ask, would GRUB v2.12 have the intelligence to provide the relief that is seeked?

I'd like to update grub2 as well, but it's easier said than done.

I also don't like grub2, although it's the most supported boot loader. Liked grub 0.99, though.
Nowadays, on my Slackware system, I use elilo, simple that I can understand.

[libertas]

As promised, I formatted the second partition of the USB stick to btrfs (from ext4 previously) and could boot from all of the rEFInd entries (Linux0-Linux4):
Entry Linux5 is for the first partition (vfat).

Code: Select all

menuentry "Fatdog64 Linux0" {
    icon /EFI/boot/icons/os_fatdog.png
    volume PUPPIES
    initrd /FD901/initrd
    loader /FD901/vmlinuz
}
menuentry "Fatdog64 Linux1" {
    icon /EFI/boot/icons/os_fatdog.png
    volume PUPPIES
    initrd \FD901\initrd
    loader /FD901/vmlinuz
}
menuentry "Fatdog64 Linux2" {
    icon /EFI/boot/icons/os_fatdog.png
    volume PUPPIES
    initrd initrd
    loader vmlinuz
}
menuentry "Fatdog64 Linux3" {
    icon /EFI/boot/icons/os_fatdog.png
    volume PUPPIES
    initrd /initrd
    loader /vmlinuz
}
menuentry "Fatdog64 Linux4" {
    icon /EFI/boot/icons/os_fatdog.png
    volume PUPPIES
    initrd \initrd
    loader \vmlinuz
}
menuentry "Fatdog64 Linux5" {
    icon /EFI/boot/icons/os_fatdog.png
    volume FATDOG_LIVE
    initrd \FD901\initrd
    loader /FD901/vmlinuz
    options "savefile=ram:uuid:6e301609-8536-4989-871f-b4e1c7a47915:FatDog/fd64save waitdev=5"
}

So, something seems definitely wrong with booting from ext4.

[smokey01]

@libertas have you tried booting from ext2/3?

[LateAdopter]

So, something seems definitely wrong with booting from ext4.

I haven't noticed any mention of whether your ext4 is the 32bit or 64bit variety.

[libertas]

The system is 64 bits:

Code: Select all

# getconf LONG_BIT
64

I don't have data about the filesystem of the second partition as it was formatted with btrfs, but from the third inside LUKS, it's this:

Code: Select all

# tune2fs -l /dev/mapper/dmcrypt0 
tune2fs 1.47.0 (5-Feb-2023)
Filesystem volume name:   <none>
Last mounted on:          /aufs/pup_save
Filesystem UUID:          a34b9272-3727-438f-b6c7-110508107536
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index orphan_file filetype needs_recovery extent flex_bg metadata_csum_seed sparse_super large_file huge_file dir_nlink extra_isize metadata_csum orphan_present
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2223872
Block count:              8889856
Reserved block count:     444492
Overhead clusters:        217372
Free blocks:              7467984
Free inodes:              2209801
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1021
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8176
Inode blocks per group:   511
Flex block group size:    16
Filesystem created:       Sun May 26 21:05:57 2024
Last mount time:          Thu May 30 09:43:25 2024
Last write time:          Thu May 30 09:43:25 2024
Mount count:              12
Maximum mount count:      -1
Last checked:             Sun May 26 21:05:57 2024
Check interval:           0 (<none>)
Lifetime writes:          7367 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      af5a07d4-28dd-4f2b-8a7d-54abc97d4132
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x816b5122
Checksum seed:            0x7fcbe547
Orphan file inode:        12

[jamesbond]

Sure, here it is, now as sdd2:

Code: Select all

# dumpe2fs /dev/sdd2 | grep features
dumpe2fs 1.47.0 (5-Feb-2023)
Filesystem features:      has_journal ext_attr resize_inode dir_index orphan_file filetype needs_recovery extent flex_bg metadata_csum_seed sparse_super large_file huge_file dir_nlink extra_isize metadata_csum orphan_present
Journal features:         journal_incompat_revoke journal_checksum_v3

Thanks. I think the metadata_csum is the culprit. We have a few threads discussing about it here, during the alpha testing of 900:
viewtopic.php?t=9176
viewtopic.php?t=9166
viewtopic.php?t=9127
viewtopic.php?t=9105

But it was focused more on grub2, which failed to boot from ext4 exactly because of that.
We have since updated grub2, but I think we didn't touch refind at all.
It is possible the cause is the same.

Since you've already deleted the ext4 partition, it will be hard to test further, but otherwise what we could have done is:
a) turn off the metadata_csum:
tune2fs -O ^metadata_csum /dev/sdXXX

b) use updated ext2 driver you can find from http://distro.ibiblio.org/fatdog/packag ... arch-1.txz (download the file, open the tarball (you don't need to install), then grab ext4_x64.efi from usr/share/refind-0.14.2/refind/drivers_x64).

I got it totally wrong, then.
Though it as a stack, that the upper layer could be removed or added with no interference with what is below.

It cannot be removed because there are programs holding open file handles on the "/", which also means that it is holding open file handles on the re-writable layer. To remove the writable layer, you will need to stop all the programs that do that; and this turns out to be "almost all" programs.

EDIT:
1. It's "tune2fs -O" not "tune2fs -o" (must use capital O)
2. I've edited the explanation on using refind 0.14.2, as I have rebuild the package. Now you need to grab ext4_x64.efi, not ext2_x64.efi.
(If this sounds confusing, that's because it is. There are 2 kinds of ext2_x64.efi: one of them supports ext2 only, another one supports ext2/3/4. I've edited the refind-0.14.2 to include the ext2-only ext2_x64.efi, and re-include the standalone ext4_x64.efi as it seems to be the best).

[libertas]

Sure, here it is, now as sdd2:

Code: Select all

# dumpe2fs /dev/sdd2 | grep features
dumpe2fs 1.47.0 (5-Feb-2023)
Filesystem features:      has_journal ext_attr resize_inode dir_index orphan_file filetype needs_recovery extent flex_bg metadata_csum_seed sparse_super large_file huge_file dir_nlink extra_isize metadata_csum orphan_present
Journal features:         journal_incompat_revoke journal_checksum_v3

Thanks. I think the metadata_csum is the culprit. We have a few threads discussing about it here, during the alpha testing of 900:
viewtopic.php?t=9176
viewtopic.php?t=9166
viewtopic.php?t=9127
viewtopic.php?t=9105

But it was focused more on grub2, which failed to boot from ext4 exactly because of that.
We have since updated grub2, but I think we didn't touch refind at all.
It is possible the cause is the same.

Since you've already deleted the ext4 partition, it will be hard to test further, but otherwise what we could have done is:
a) turn off the metadata_csum:
tune2fs -O ^metadata_csum /dev/sdXXX

b) use updated ext2 driver you can find from http://distro.ibiblio.org/fatdog/packag ... arch-1.txz (download the file, open the tarball (you don't need to install), then grab ext4_x64.efi from usr/share/refind-0.14.2/refind/drivers_x64).

I got it totally wrong, then.
Though it as a stack, that the upper layer could be removed or added with no interference with what is below.

It cannot be removed because there are programs holding open file handles on the "/", which also means that it is holding open file handles on the re-writable layer. To remove the writable layer, you will need to stop all the programs that do that; and this turns out to be "almost all" programs.

EDIT:
1. It's "tune2fs -O" not "tune2fs -o" (must use capital O)
2. I've edited the explanation on using refind 0.14.2, as I have rebuild the package. Now you need to grab ext4_x64.efi, not ext2_x64.efi.
(If this sounds confusing, that's because it is. There are 2 kinds of ext2_x64.efi: one of them supports ext2 only, another one supports ext2/3/4. I've edited the refind-0.14.2 to include the ext2-only ext2_x64.efi, and re-include the standalone ext4_x64.efi as it seems to be the best).

I formatted the second partition of the USB stick (label PUPPIES) as a ext4 filesystem and removed the metadata_csum as shown.
FatDog can now boot from that partition with no further issues.
Thank you @jamesbond.
I still have to read the URLs you provided to understand why this is hapenning.

[jamesbond]

Thank you for confirming.

Don't worry about the URLs, they're just background information if you want to know what has been discussed before. Basically the newer mkfs.ext4 (from version 1.47 onwards) will by default enable metadata_csum, and many bootloaders do not recognise this "feature" and to avoid corrupting the filesystem, will simply refuse to boot from an ext4 that has this feature enabled.