Initramfs unpacking failed

I updated my computer and now it won’t boot.
The error is "initramfs unpacking failed "

I found this possible solution:

I can mount the right directory by booting a live USB but doing update-initramfs will just change the live USB that booted.
Will update-initramfs work from the busybox shell?
It’s not listed as a command but maybe I missed it.

You have to mount the drive and edit it that way. You can probably do it via chroot as well.

2 Likes

I CAN mount the drive and edit the file from within the live usb environment but what else do I need to mount so that update-initramfs will NOT use the live usb drive?

I think what KGII is saying is right. See if you can use chroot command to use / from what’s on your disk (not USB). Then the update-initramfs will apply.
EDIT:

1. Boot the Live CD.

2. Press Ctrl-Alt-F1

3. sudo mount /dev/sda1 /mnt

4. If you created a custom partition layout when installing Ubuntu you have to find your root partition using the fdisk utility. See the section Finding your root partition.

5. sudo chroot /mnt 

Note: In the mount command, /dev/sda1 will need to be replaced with the partition where the root of the file system resides.

Source: https://help.ubuntu.com/community/LiveCdRecovery

2 Likes

I’ll try that solution with chroot.

Didn’t work. :frowning:

update-initramfs is disabled since running on read-only media

Forgot the chroot.

root@lubuntu:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.4.0-47-generic
/usr/share/initramfs-tools/hooks/cryptroot: 64: cannot open /proc/mounts: No such file
cryptsetup: WARNING: Couldn’t determine root device
sed: can’t read /proc/cmdline: No such file or directory
grep: /proc/swaps: No such file or directory
/usr/share/initramfs-tools/hooks/cryptroot: 64: cannot open /proc/mounts: No such file
grep: /proc/cpuinfo: No such file or directory
W: Couldn’t identify type of root file system for fsck hook

I did and I am making progress.

sudo update-initramfs -u -k all

The error now is:
20200918_112619_1

$ blkid (from live USB)
/dev/nvme0n1p1: SEC_TYPE="msdos" UUID="812C-B4BC" TYPE="vfat" PARTLABEL="EFI System" PARTUUID="39cf8666-82ab-45e2-8257-382faa2b0ddb"
/dev/nvme0n1p2: LABEL="OS" UUID="12554e38-e51e-4761-8a79-efe2780391e3" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="5b51add3-68a4-423d-8091-35687f82e928"

Am I missing an nvme module that I didn’t need before?

sudo mount /dev/nvme0n1p2 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt
mount -a
update-initramfs -u

update-grub


:-(

grub-probe: error: cannot find a GRUB drive for /dev/sdb1. Check your device.map.’


I did
grub-install --target=x86_64-efi --bootloader-id=lubuntu --recheck --verbose

Same error about UUID not found. :frowning:

I feel dumb for asking this late but can you boot with an older kernel? As in can you boot fine by choosing an older kernel via grub during boot? My mind forgot this all happened 'cause of an update.

I forgot to ask if you could reach recovery mode. If so, you can use nano to edit grub directly and then run sudo update-grub to load the new configuration.

This sounds like a problem I and others have been having with ubuntu and grub for quite awhile. The “initramfs unpacking” error I don’t think is involved, I get that and I can still get to the system. The problem is that ubuntu seems to be breaking grub in some manner with each update, it’s happened so many times, I think I have several bug reports, latest one #1894242.

I have a number of distros installed, and if somehow the grub “updates” slip by, I’m only left with usually U-MATE as the auto-boot. The chroot idea work awhile back, but only by chrooting into an Open SUSE system and then running their version of update grub does it work. I have to use Super Grub 2 disk now to boot that system . . . . PITA

PS: Point being that running “update-grub” in ubuntu doesn’t seem to fix the problem with grub . . . devs don’t seem to be able to diagnose it or think it matters. I think it has something to do with EFI boot, but I don’t know how to address the problem that seems to be happening over and over . . . . OpenSUSE doesn’t seem to have this problem and I don’t think Manjaro does either.

2 Likes

I think I removed the old kernel before I was sure it rebooted.

I THINK the problem now is my partition table is GPT and grub sees that but the initramfs doesn’t.
The busybox shell sees /dev/nvme0 but no partitions on it.
It sees /dev/sda1 though but maybe that is an MBR partition.

I booted an old kernel.
i should have thought of that. :slight_smile:
Doesn’t it keep one kernel as backup?
What if the next kernel doesn’t boot?

1 Like

I could be wrong but it’s supposed to keep all unless you clean them up yourself.

I believe those “cleanup” utilities do in fact keep at least one (in addition to latest) which is always recommended for cases like these…

This doesn’t fix the issue… but assuming you can actually get the desktop and everything else fine with the older kernel, then you can at least use your machine now.

If you get another kernel update and even that one has problems booting… then something, somewhere has either changed or wasn’t setup correctly. I know that’s vague but I honestly can’t figure out the problem myself. There are bug reports online with the messages you’ve shown us but I can’t pinpoint it.

The advantage you have now is that you can boot normally, which gives you the opportunity to better investigate why the other kernel won’t work. :wink:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.