Open firasuke opened 1 year ago
Booster needs to add erofs
filesystem detection.
By the chance do you have exact instructions on how to create a bootable ISO with efofs & squashfs?
First of all you need to have a root file system (you can grab one of alpine's mini root file system for convenience).
It comes in .tar.gz
format, so you should extract that into a directory say rootfs
, and then create an erofs
out of it by running:
mkfs.erofs rootfs.erofs rootfs
Now going back to our ISO structure:
- boot/ (contains `vmlinuz`, `initramfs`, `grub/` or `isolinux/` files)
- fs/ (contains rootfs.erofs) (some distros call `fs/` as `live/`)
Now an initramfs should detect we are in ISO mode and attempt to mount /dev/sr0
as iso9660
which is what booster started doing as of #223, but that is only in the case the root file system was the root layout of /dev/sr0
.
In our case here, the root file system is still in erofs
format and simply mounting /dev/sr0
won't suffice, as booster
now needs to do another mount for the erofs
file system then switch_root
into that or something similar:
losetup /dev/loop0 /run/iso/fs/rootfs (or location of rootfs.erofs)
mount -t erofs -o ro /dev/loop0 /mnt/fs
Loop device number (could be based on what loop device is available, and the location /mnt/fs
could be in /run
or whatever you see fit, as the above is just an example for the sake of explaining this).
Now having a read-only filesystem is not always a good idea, so we may need to have a tmpfs
or overlayfs
mounted to simulate read-write mode until system is shutdown.
Hope that clears things up a bit.
Any updates to this? as I am delaying the ISO release process until this feature is added :)
I just merged erofs
fs detection code to master
.
To get the schema you described working booster needs to mount a loop device on a file. So you can specify root=/rootfs.erofs
and booster will handle mounting it.
Currently booster can mount a device file only, but it will be doable to add support for loopback devices in case if root is a regular file.
Are there any initramfs that already implement erofs root filesystems? I want to check their implementation as well.
To get the schema you described working booster needs to mount a loop device on a file. So you can specify root=/rootfs.erofs and booster will handle mounting it.
Exactly!
Currently booster can mount a device file only, but it will be doable to add support for loopback devices in case if root is a regular file.
Ok, cool.
Are there any initramfs that already implement erofs root filesystems? I want to check their implementation as well.
I believe only Arch's ISO scripts support EROFS. Alpine's initramfs generation utility (mkinitfs) supports SquashFS (which providing support for is almost identical to EROFS).
We should also handle the case of providing read-write support when in ISO mode (via overlayfs), which is also mentioned in #88.
A proposal for the whole ISO / OverlayFS / SquashFS / EROFS situation (Getting booster
to support handling ISOs with read-write support):
booster
beforehand:/media/cdrom # Where /dev/sr0 will be mounted
/media/rootfs/lower # Where /dev/loop0 will be mounted (Overlayfs step 1)
/media/rootfs/upper # (Overlayfs step 2)
/media/rootfs/work # (Overlayfs step 3)
/new_root # Where chroot / switch_root will take place
erofs,iso9660,loop,overlay
/dev/sr0
should be mounted ro
as type iso9660
on /media/cdrom
(according to FHS 3.0):mount -t iso9660 -o ro /dev/sr0 /media/cdrom
losetup
should be run (the location of the compressed rootfs should be controlled by the variable root=
which has recently added to booster):losetup /dev/loop0 /media/cdrom/boot/rootfs.erofs
/dev/loop0
should be mounted ro
as type erofs
on /media/rootfs/lower
:mount -t erofs -o ro /dev/loop0 /media/rootfs/lower
overlay
should be mounted rw
as type overlay
on /new_root
with the following parameters (lowerdir=/media/rootfs/lower,upperdir=/media/rootfs/upper,workdir=/media/rootfs/work
):mount -t overlay -o lowerdir=/media/rootfs/lower,upperdir=/media/rootfs/upper,workdir=/media/rootfs/work overlay /new_root
Any updates to this?
What's the current situation on this?
squashfs as rootfs with a writable overlay would be very nice to have
Ok, consider the case the root filesystem was compressed using
squashfs
orerofs
into a file calledrootfs.erofs
.According to this, I think
booster
should check whether the root filesystem is compressed/squashed or not, if it is then an additional mount command should be run:So in addition to checking for
/dev/sr0
and mounting it, booster should also check whether another parameter is passed that specifies the location of the root filesystem on/dev/sr0
whether it was compressed or not (for example anotherroot=
as an argument for booster and not for cmdline)..