You are not logged in.
I put this to report the error and what fixed it. Has this been a problem for others?
This has happened with 2 machines running Lithium, one via Synaptic and the other manually
$ sudo apt upgrade
The error comes up like this:
Setting up initramfs-tools ) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.linux-image-4.19.0-13-amd64
gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
dpkg: error processing initramfs-tools (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
initramfs-tools
I did a search and found that this means there are too many Linux images, so then did this:
dpkg -l 'linux-image-*' | grep '^ii'
Which lists images. You have to delete one or more of these. Which seems weird. Why doesn't it happen as part of the upgrade?
output:
ii linux-image-4.19.0-9-amd64 4.19.152-1 amd64 Linux 4.19 for 64-bit PCs (signed)
ii linux-image-4.19.0-12-amd64 4.19.152-1 amd64 Linux 4.19 for 64-bit PCs (signed)
ii linux-image-4.19.0-13-amd64 4.19.160-2 amd64 Linux 4.19 for 64-bit PCs (signed)
ii linux-image-amd64 4.19+105+deb10u8 amd64 Linux for 64-bit PCs (meta-package)
Delete an older image,
sudo apt-get purge linux-image-4.19.0-9-amd64
then re-run
$sudo apt upgrade
or update, autoremove or anything it seems after "apt". This then fixed initramfs error
Last edited by trilobite (2021-01-20 01:02:18)
{Linux-using people I haven't met are friends yet to be made.}
Offline
gzip: stdout: No space left on device
Do you have /boot on a separate partition?
Offline
No. Just Swap and the rest of disks is one big partition.
{Linux-using people I haven't met are friends yet to be made.}
Offline
I put this to report the error and what fixed it. Has this been a problem for others?
This has happened with 2 machines running Lithium, one via Synaptic and the other manually
[...]
I did a search and found that this means there are too many Linux images,
On two of my machines now up, I have 4 kernels. You had only 3 (one metapackage).
I have never seen that error.
It is good to save some kernels if there is problem when upgrading. If you dont want that, you can edit /etc/default/grub:
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
// Regards rbh
Please read before requesting help: Guide to getting help,
Introduction to the Bunsenlabs Lithium Desktop and other help topics under "Help Resources" on the BunsenLabs menu
Offline
update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
dpkg: error processing initramfs-tools (--configure):
Missed that. Kernel 2.6. is 10 years old. Was not listed when you searched installed images. What does command "ls /boot/initrd.*" return?
If you realy have very old initrd and vmlinuz, in /boot, that is not installed, they should be deleted.
// Regards rbh
Please read before requesting help: Guide to getting help,
Introduction to the Bunsenlabs Lithium Desktop and other help topics under "Help Resources" on the BunsenLabs menu
Offline
ls /boot/initrd.*
gives:
/boot/initrd.img-4.9.0-12-686-amd64
/boot/initrd.img-4.9.0-13-686-amd64
Noting that these were fresh installs within the last 3-4 months of Lithium. Wiped clean the Windows7 that was on them.
{Linux-using people I haven't met are friends yet to be made.}
Offline
ls /boot/initrd.*
gives:
/boot/initrd.img-4.9.0-12-686-amd64
/boot/initrd.img-4.9.0-13-686-amd64
You get error "failed for /boot/initrd.img-2.6.38-8-generic" but dooes not have kernel 2.6 installed or even left behind in /boot directory. It does not make sense for me..
What package did install file initrd.img-4.9.0-13-686-amd64, or is it an typo error? I have never seen a kernel for both 32 and 64 bit...
Btw, rememberd that "apt autoremove", cleans old kernels, with default /etc/default/grub, it only leaves one extra kernel.
Last edited by rbh (2021-01-20 19:06:43)
// Regards rbh
Please read before requesting help: Guide to getting help,
Introduction to the Bunsenlabs Lithium Desktop and other help topics under "Help Resources" on the BunsenLabs menu
Offline
I did indeed have a typo I think.
That may in fact answer it, "apt autoremove".
I am in fact also inconsistent with apt and apt-get which was noted by a friend. Don't know if combining the two makes differences.
{Linux-using people I haven't met are friends yet to be made.}
Offline
I am in fact also inconsistent with apt and apt-get which was noted by a friend. Don't know if combining the two makes differences.
Nop. As long as you only mix them in terminal. In skripts, stick to apt-get. Apt warn it still is to unstable to use in scripts.
// Regards rbh
Please read before requesting help: Guide to getting help,
Introduction to the Bunsenlabs Lithium Desktop and other help topics under "Help Resources" on the BunsenLabs menu
Offline
Your mistake actually stems from this:
...
update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
...
i.e. a "remainder" from a ubuntu kernel.
Unfortunately, you also did not even show, e.g.
parted -l
otherwise to the differences apt-vs-apt-get
Offline
trilobite, have a look under /etc/initramfs-tools/ if there's something wrong with the configuration.
Personally I think the 2.6.38 kernel is some sort of weird fallback though.
Also
man update-initramfs
man update-initramfs.conf
Offline
Never used Ubuntu ?? weird.
I have an encrypted disk.
$ sudo parted -l
Model: ATA FUJITSU MJA2160B (scsi)
Disk /dev/sda: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 160GB 160GB extended
5 257MB 160GB 160GB logical
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/trilo--vg-root: 157GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 157GB 157GB ext4
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/trilo--vg-swap_1: 2613MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 2613MB 2613MB linux-swap(v1)
Error: /dev/mapper/sda5_crypt: unrecognised disk label
Model: Linux device-mapper (crypt) (dm)
Disk /dev/mapper/sda5_crypt: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Perhaps you are right re "weird fallback"?
Encrypted drive?
I am over my head in this.
{Linux-using people I haven't met are friends yet to be made.}
Offline
Number Start End Size Type File system Flags
1 1049kB 256MB 255MB primary ext2 boot
In post #3, you wrote:
No. Just Swap and the rest of disks is one big partition.
What is in fstab? Does it mount /dev/sda1 on /boot?
If so, no wonder you went out of space with only three kernels.
Only remember to run apt-autoremove after upgrading kernel, else you could move border for sda1 +500 mb...
// Regards rbh
Please read before requesting help: Guide to getting help,
Introduction to the Bunsenlabs Lithium Desktop and other help topics under "Help Resources" on the BunsenLabs menu
Offline
I let the Bunsen installation do its default (?)
I've got (from GParted), this:
/dev/sda1 - ext2 which is boot and has 243MB, current usage is 82.32 MB
/dec/sda2 -extended which is 148.81GB
under this is /dev/sda5 which is encrypted, also 148.81GB
My understanding is that this means in actuality 2 partitions.
fstab shows that it is 2 doesn't it? There is a cd drive too.
<file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/trilo--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=37085dbe-d727-4b82-9460-e8a6f188570f /boot ext2 defaults 0 2
/dev/mapper/trilo--vg-swap_1 none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
{Linux-using people I haven't met are friends yet to be made.}
Offline
hey trilobite
you have two physical partitions - sda1 is /boot, and sda2 is an encrypted logical volume group with a volume for / and a volume for swap.
that's how debian/bunsenlabs usually sets up encrypted for me
the /boot (/sda1) is where your kernels are, you ran out of room, so getting rid of an old one took care of the problem.
like what was said earlier, the kernel version mentioned in the error report is probably just some misleading fallback placeholder
although for fun you could post content of /boot
ls /boot
Last edited by Nick (2021-01-21 22:08:10)
Offline
Else, command "df -h" in terminal is a quick way to get info about size and available space of mounted partitions.
Good to add to conky, so you get quick warning for low free disk space.
The code:
${color0} ${alignc}${font = Entopia:bold:size=11} DISK / FILESYSTEM ${color}${font}
${color0}${alignc}Local filesystem ${color}
Diskktivitet: $diskio
${exec df -h | grep "/dev/sd" | awk '{ printf "%s of %s \t : %s\n", $5, $2, $6 }' }
${color0}${alignc}NFS filesystem ${color}
${exec df -h | grep "nfs-mnt" | cut -c16-48}
Again; you was early in thread asked if you had separate boot partion. You answered no, but should answered yes...
You have only two partions. One small boot and rest for rot. You use swapfile instead of swap-partition.
// Regards rbh
Please read before requesting help: Guide to getting help,
Introduction to the Bunsenlabs Lithium Desktop and other help topics under "Help Resources" on the BunsenLabs menu
Offline
ls /boot
config-4.19.0-12-amd64 initrd.img-4.19.0-13-amd64 vmlinuz-4.19.0-12-amd64
config-4.19.0-13-amd64 lost+found vmlinuz-4.19.0-13-amd64
grub System.map-4.19.0-12-amd64
initrd.img-4.19.0-12-amd64 System.map-4.19.0-13-amd64
Thanks for the clarification and information @rbh. I learned today.
{Linux-using people I haven't met are friends yet to be made.}
Offline
I guess it's been said already, but:
/dev/sda1 - ext2 which is boot and has 243MB, current usage is 82.32 MB
243MB is not enough, esp. if update-initramfs defaults to compressing (gzip) the image on that partition - temporary files will quickly fill it up.
I believe Archlinux recommends at least 500MB, but it's much less conservative with old kernels.
BTW, your updating mechanism calls this command "update-initramfs". How exactly it does that can be derived from some files:
ls /var/lib/dpkg/info/initramfs-tools*
and
ls /etc/kernel/post*.d
You can read the man pages for "update-initramfs" and call it manually, to see what's happening and generally get a better grasp, maybe even fix it.
Offline