sysrecue-costomize –unpack and –auto seems to corrupt the airootfs.sfs image. I was trying to customize sr806 and the resulting iso would drop to root failing to mount airootfs.sfs as wrong filetype. I tried to mount the airootfs.sfs in my work dir and it also wouldn’t mount. I mounted the original iso and copied the airootfs.shs over to the work dir and was able to rebuild a successful iso. I looked at the script and see it’s using xorriso which I’m not familiar with but I’ll test it by itself and see if that is the problem. Here is the version info on a Manjaro system.
xorriso 1.5.8.pl02
ISO 9660 Rock Ridge filesystem manipulator and CD/DVD/BD burn program
Copyright (C) 2026, Thomas Schmitt [email protected], libburnia project.
xorriso version : 1.5.8.pl02
Version timestamp : 2026.05.22.150001
Build timestamp : -none-given-
libisofs in use : 1.5.8 (min. 1.5.8)
libburn in use : 1.5.8 (min. 1.5.8)
libburn OS adapter: internal GNU/Linux SG_IO adapter sg-linux
libisoburn in use : 1.5.8 (min. 1.5.8)
Provided under GNU GPL version 3 or later, due to libreadline license.
There is NO WARRANTY, to the extent permitted by law.
If you are trying to customise a quite old SystemRescue version such as 8.06, a potential problem is that you may be creating the squashfs file system on a recent linux distribution running a recent version of mksquashfs and the old SystemRescue version will try to mount it with an old kernel (ie: 5.10.79).
Linux file systems can only be mounted when the running kernel supports all its features, and updates to the mkfs utilities regularly introduce new file system features, some which are compatible with older kernels some which are not. You cannot run mkfs.ext4 on RHEL9 and expect to mount it on an older RHEL7 system. It is definitely a problem with file systems such as ext4, xfs, btrfs, etc. This is why SystemRescue does not provide the very latest versions of xfsprogs and btrfsprogs, instead we stick to the versions that match the kernel.
I would expect most users to use up to date versions of SystemRescue. If you really have to stick to such an old version, make sure you use an old versions of mksquashfs. You may be running it from an old version of your Linux distribution, or even better would be to run the customisation script from the same version of SystemRescue.
Well that is the latest image I could get to boot on this computer I’m testing. After posting this I tested xorriso and it ran fine. Then I did an –unpack on 8.06 and 13.01 and I could mount the airootfs no problem. I tried several times before and they all failed. I don’t know what has changed but it seems to be working now. I did checksum the iso and I used the same iso to copy the airootfs so the download was fine.
If you have random failures and inconsistent results, you should run a full memory test. You can use memtest which is available from the boot menu. If the RAM of your computer is unreliable, it could explain many problems.
I ran stress for memtest and 24 hours each but I’m not doing the work on that computer. I just wanted modify different version of sysrecue to boot up headless to see if I can figure out what causes the kernel panics. I thought it was the built in video but it seems later kernels cause it to crash too. passwd caused a kernel panic with 8.07.
Stress and memtest for 24 hours each, I meant. I have used –rebuild and –auto a bunch of times now and no corrupt airootfs so what ever caused it in the beginning is gone. I went through bash history to see if I did anything different and I didn’t see it. I do have 13.01 booting on the machine in question with odd results. It doesn’t kernel panic or lock up completely but i wouldn’t say it runs stable. I boot up headless and ssh in, run stress for 24 hours in a screen and run btop outside screen. It showed one CPU core locking up, then restart after a few minutes. Then btop locked up but not completely. the current time updates but nothing else does. the keyboard numlock still functions but I can’t login at the console. I can ssh in but sometimes only up till it asks for my ssh key passphrase. Htop seems to run but it shows 0 load with stress running and all CPU cores at 100%. Oh, it does show a core at 7% which I assume is locked up or throttled or something. I like that btop shows the CPU temps but this machine seems to only have one sensor for all the CPUs which was at 85c which I think is in the safe zone. Anyways, the script seems to be working fine. Maybe one of the tools it uses had a bug and was upgraded.