Yr welcome, let me tell you about my day(s) - spent all of yesterday upgrading from debian 6.0 CD1 lxde/openbox to Bookworm/LMDE 6 with sysvinit still installed from debian 6.0, didn't backup along the way as it was more about seeing what happens if kmod isn't allowed to upgrade and kick the 2.6 kernel, anyway, after the final upgrade, unbootable on all fronts, all kernels, all inits, and bash init was borked by a short libtinfo.

The day before, had upgraded LMDE1 to LMDE6 with sysv. Took a backup at Debbie and a final one after Faye.
This morning, couldn't boot system 2, so decided to restore system1. Faye backup was borked and unfixable, luckily Debbie backup worked and was fixable (needed swap repair).

I blame usrmerge, or kmod, or 18 yo eee pc ssd, or my 90% of backups untested, and another 9% untested.

rbit is correct, EFI partitions are typically mostly empty and are at the start of the disk where there can be lots of non-zeroed old junk that can make your compressed images much larger.

The joy of using dd in a fat partition where you never need sudo

Hi, hope you find a solution! Some advice for anyone finding this thread:

Open your EFI partition in terminal then run

 dd if=/dev/zero of=zero.img 

then run

 rm zero.img 

then take a backup of the partition using dd or any disk utility then zip up your partition backup and save it for efi partition deletion emergencies. For accidental deletion of contents, just mount the backup image and copy the files over from it.

If you need to recreate a lost EFI partition, you can set the label to be the same as the lost one very easily.

Sorry my bad, I mean mocp (music on console player) complains of no sound server >_<

Been finding refracta isos work with ventoy and have used devuan with ventoy in the past???

There's a 17 MB bios boot boost partition for eee pc xp too! I should put that online too.

One does wonder about the breadth of testing of new 32 bit kernels, so many million use cases, so fewer eee pc users ;_:

Yes they all (my asus eee pc fleet) still run fine on every kernel since 3.16, they just all have different esoteric messages on boot.
I mean, is there some way to just include all relevant new security updates to an old kernel without worrying about new features or hardware that the asus eee pc will never know or be able to run?

The poor little 2G surf, I just managed to get lmde 6 onto it with latest kernel and 300 MB free space of the 1.87MIB ssd. No room for newest kernel upgrade. They can run the  new kernels, but can't install them!

Hey that's wonderful thanks, it's for my eee pcs so no need for the firmware or pae, they take max 2GB ram!
Downloading that kernel now and will try it on eee pc later

Got it working, reverted to pre-migration state and tried a different approach: Installed orphan-sysv-scripts and the four sysvinit-core dependencies under the debian repos, then checked and inittab was present, so went ahead with the migration instructions as before.
This worked fine, albeit with extra apt-get upgrades and apt-get -f installs, but the inittab.d warning was still there, so mkdir /etc/inittab.d fixed the warning, which didn't affect the system.
I am learning
Also forgot to reinstall lightdm, so booted to no desktop, but startx worked.
I'd like the system to always behave that way? Booting to cli, with startx option, but removing lightdm breaks switching between consoles.

Is the fix to simply copy over a known good inittab and mkdir /etc/inittab.d/  ?