Initramfs problem [solved]

[kensanata]

@josch

@kensanata

mount -t ext4 /dev/mmcblk2p2 /root

I wonder why you have to explicitly pass the type of your rootfs here. If you cannot mount it without giving the type then that sounds like your error message that it cannot determine the type of your rootfs.

All I remember it saying that it couldn’t determine the type.

@josch

@kensanata

update-initramfs -u

You only mounted your rootfs but you did not mount /boot into it. So the initramfs you created here will be stored in the /boot directory of your rootfs but it will not be stored in the filesystem which then gets mounted as /boot.

Ah, interesting. I will add this to my notes.

@josch

Since whatever initramfs you create here has no effect on the initramfs you are currently running at that point i rather suspect that what made it work was you manually passing the type of the rootfs.

I remember it making a difference, but since everything works for me now, there’s no way to go back.

@josch

Did you ever try just mounting the rootfs but nothing else?

I’m not sure what you mean. I tried to just mount /root but then I didn’t know what to do with it. Just exiting the shell at that point didn’t get me booting.

@josch

How did you install the system?

Back in September 2024 I switched my sources to Trixie:

What brought you to the MNT community

Instead of doing /etc/apt/sources.list sorcery in the future, you could replace “testing” by “trixie” today. That way, at the point in time where “testing” becomes “stable” you do not need to edit your /etc/apt/sources.list. The updates and security mirrors also exist already for trixie but are of course empty but this means that you can also add those today already and have things set up for the future: deb http://deb.debian.org/debian trixie main deb http://deb.debian.org/debian trixie-updat…

But when I wondered about what else was required now that Trixie had landed, I was discouraged and wanted to go back to unstable. I changed the sources and ran sudo apt update and somewhere after that my problems started. There was a critical bug in systemd so I held it using sudo apt-mark hold systemd. I tried sudo apt upgrade and I guess something didn’t work: something about me uninstalling the kernel that was running and I should be extra sure I wanted to do this, yes/no. I said no and the upgrade was interrupted. At this point I had seen that udev had been uninstalled. The history shows I did sudo apt install udev to recover and that there was a systemd circular dependency because I did sudo apt-mark unhold systemd, then sudo apt --fix-broken install and sudo apt full-upgrade. So that’s how I ended up with some bonkers setup.

My notes have nothing to add, I think.