How to change the casefold ext4 filesystem option of the root partition, if I only have ssh access

Question

I need to enable the case insensitive filesystem feature (casefold) on ext4 of a Debian 11 server with a backported 6.1 linux kernel with the required options compiled in.

The server has a swap partition of 2GB and a big ext4 partition for the filesystem, which it also boots from. I only have ssh access as root and cannot access the physial/virtual host itself, so I don't have access to (virtual) usb sticks or cdrom media.

What is the fastest way to enable the casefold feature? tune2fs doesn't want to do it because the fileystem is mounted.

Idea: Drop the swap, install a small rescue system in it, reboot into said rescue system, change the filesystem options of the root partition, reboot into the live partition and restore the swap. For this to work however I need to prepare an extra linux system just to do the tune2fs command needed.

Is there a better way? Any rescue systems I can already use and preconfigure for the required network settings after a reboot?

Answer 1

Thanks to @Marcus Müller I was able to do it. The trick is to add tune2fs into the initrd image and to call it during boot.

Create the script for initramfs-utils:

cat > /usr/share/initramfs-tools/scripts/local-premount/ext4_casefold << 'EOF'
#
# ext4_casefold
#
# initrd script to add the casefold option to the root filesystem
#

DEVICE=/dev/sda2

prereqs()
{
    . /usr/share/initramfs-tools/hook-functions 
    copy_exec /usr/sbin/tune2fs usr/sbin/tune2fs
}

case $1 in
# get pre-requisites
prereqs)
        prereqs
        exit 0
        ;;
esac

echo "Adding casefold option to $DEVICE"
sleep 5
/usr/sbin/tune2fs -O casefold $DEVICE
echo "If everything went well, we added the casefold option to $DEVICE"
sleep 5

EOF

Make it executable:

chmod a+x /usr/share/initramfs-tools/scripts/local-premount/ext4_casefold

Rebuild the initrd:

update-initramfs -u

Check if the contents of the ramdisk really contain tune2fs (optional):

INIT_RD_IMAGE=initrd.img-6.1.0-0.deb11.7-amd64
rm -rf /root/initrd
mkdir /root/initrd
cp /boot/$INIT_RD_IMAGE /root/$INIT_RD_IMAGE.gz
gunzip /root/$INIT_RD_IMAGE.gz
cd /root/initrd
cpio -id < /root/$INIT_RD_IMAGE

Reboot and enjoy!

Answer 2

I like your approach; it's clean in that it doesn't require modification of the data on your main system.

And, yes, I think that if you want to run tune2fs then by a large margin, the easiest solution is to run that from a running Linux, so that there's no real way around having to run it when the main file system isn't mounted.

I don't think your network setup is of any significance – you know exactly what you want your system to do; preconfiguring network to give you an SSH shell into it is going be harder than just running tune2fs … /dev/disk/by-partuuid/… in a script that's autonomously executed (and which then moves on to do what is needed to boot your normal system).

Now, two options:

1. Your debian currently boots using an initrd containing an initramfs (I expect it does)
2. It doesn't.

In the first case, modifying that initrd generation process to just include the necessary tune2fs invocation, generate a new initrd, booting with that, is probably the easiest. Mind you, initrds are really what you want to avoid building: custom fully-fledged Linux systems (which just happen to be Linux distro's ways to initialize the system before mounting the root file system and continuing the main boot process). It's just that debian already builds these for you, anyways :)
I must admit it's been a decade (or more) since I did something like that for a debianoid Linux, so I'm not terribly much of a help on how; check out debian's (sadly seemingly a bit sparse/outdated) documentation on it, and see what you have in /etc/mkinitrd.

In the second case, your approach seems sensible.

Answer 3

The approach I've used in the past for remote root filesystem modification is setting up a lightweight OS in a ramdisk (e.g. via mounting a tmpfs and then debootstrapping into it) and then using pivot_root to run off that ramdisk instead. With a little cleanup, you can then unmount the root filesystem and proceed to make your changes. This can all be done live without requiring a reboot of the system at any point - though of course a reboot at the end is probably a good idea to bring the system back into a clean state.

An advantage of using this approach is you should be able to maintain a remote connection during the process and address any issues that may come up while making the changes. You can also try a test mount of the modified filesystem before the final reboot.

There is a very comprehensive guide to the usage of pivot_root in this answer to a similar question. That answer copies the core parts of the existing system over to the ramdisk - which makes preserving ssh access and other tooling a lot easier.