Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

bread_lover · 2024-02-21 19:58:25

Greetings *.

After system upgrade done with "sudo pacman -Syu" i got warning that boot partition is running low on space (although I keep there only the latest initramfs.img and vmlinuz-linux). After reboot I can no longer access the system as it fails to boot with following errors:
https://i.postimg.cc/Hs68dJ0t/IMG-20240 … 24-181.jpg

Unfortunately I can't even access emergency shell as keyboard reamins undetected. I can only assume that failure is connected to the low space on boot.

I tried restoring initramfs using USBlive, like so:
- mount /dev/sdb1 /mnt
- arch-chroot /mnt
- rm initramfs vmlinuz
- sudo -S linux
- mkinitcpio -P
- reboot

but with no success. I am quite inexperienced with system-administration related stuff and I got stuck. I am not sure what other information should I provide to make my issue easier to understand. Please let me know and I will provide it. I would really appreciate you help.

Last edited by bread_lover (2024-02-23 07:36:00)

V1del · 2024-02-21 21:04:23

Please only embed thumbnails and/or link to images bigger than 250px in size

If those are the literal commands you ran then this cannot possibly have worked. I'm assuming you paraphrased, try not to do that, check the bash history in case.

You didn't mount the /boot partition under /mnt/boot before chrooting, do that, you didn't remove the correct initramfs files because you never cded to the (missing) /boot partition.

Assuming you ran the commands semi correct. One thing that recently lead to a big increase in initramfs size is that the kms hook will include firmware of nvidia GSP since nouveau gained support for those. The best way to mitigate that is to not use the kms hook in your /etc/mkinitcpio.conf, but only early load the modules of graphics drivers you're actually using: https://wiki.archlinux.org/title/Kernel … _KMS_start

Last edited by V1del (2024-02-21 21:05:15)

Scimmia · 2024-02-22 00:01:39

how bit is your /boot partition and what all is on it?

bread_lover · 2024-02-22 10:17:30

If those are the literal commands you ran then this cannot possibly have worked. I'm assuming you paraphrased, try not to do that, check the bash history in case.

It is literally what I've done. Step by step.

You didn't mount the /boot partition under /mnt/boot before chrooting, do that, you didn't remove the correct initramfs files because you never cded to the (missing) /boot partition.

So after "mount /dev/sdb1 /mnt" i need to "mount /boot /mnt/boot"? I think I tried something similar which lead to mount error with msg like: "/mnt/boot is not a block device". But if this would work I need to complete the rest of steps as before and reboot?

Assuming you ran the commands semi correct. One thing that recently lead to a big increase in initramfs size is that the kms hook will include firmware of nvidia GSP since nouveau gained support for those. The best way to mitigate that is to not use the kms hook in your /etc/mkinitcpio.conf, but only early load the modules of graphics drivers you're actually using: https://wiki.archlinux.org/title/Kernel … _KMS_start

I should've mentioned it earlier but I assigned only 100MB of disk space to the boot partition which is at the start of sdb1 where also root resides. I had problems with boot running low on space before but then I resolved it by removing old kernel images (also there was no boot issues then). I use dual boot with Windows. I will provide more info from fdisk after I'll get access to my PC if this will help. I will try this solution regarding kms but firstly I need to read a lot of "how to", because i am real newbie if it comes (but not only) to OS.

how bit is your /boot partition and what all is on it?

It's 100 MB on dual boot configuration (I know...) with grub folder, vmlinuz and initramfs on it.

seth · 2024-02-22 10:23:07

Dual booting windows from a 100MB /boot isn't a thing.
It's probably gonna be enough as ESP, but you'll have to either grow it or boot from the root partition.
Maybe if you remove the kms hook and skip the faillback initramfs

lsblk -f

from the install iso, w/o chroot
You can

lsblk -f | curl -F 'f:1=<-' ix.io

to upload it.

V1del · 2024-02-22 10:32:52

bread_lover wrote:

It is literally what I've done. Step by step.

Impossible, it will have failed at the rm because you weren't removing anything in /boot and the names would've been rm vmlinuz-linux initramfs-linux.img and sudo -S linux makes no sense since that lacks the pacman, mkinitcpio -P will have generated the images at the wrong location since you never mounted /boot... You see where I'm going with this? I know you probably ran the generaly correct things but computers are precise and you need to retell the precise things you did so you can be given proper help

So after "mount /dev/sdb1 /mnt" i need to "mount /boot /mnt/boot"? I think I tried something similar which lead to mount error with msg like: "/mnt/boot is not a block device". But if this would work I need to complete the rest of steps as before and reboot?

Close but not quite you need to mount the correspondingly correct /dev/sdX where your ESP or /boot partition actually resides to /mnt/boot before the chroot

I should've mentioned it earlier but I assigned only 100MB of disk space to the boot partition which is at the start of sdb1 where also root resides. I had problems with boot running low on space before but then I resolved it by removing old kernel images (also there was no boot issues then). I use dual boot with Windows. I will provide more info from fdisk after I'll get access to my PC if this will help. I will try this solution regarding kms but firstly I need to read a lot of "how to", because i am real newbie if it comes (but not only) to OS.
It's 100 MB on dual boot configuration (I know...) with grub folder, vmlinuz and initramfs on it.

As mentioned 100 MB is quite tight, it might work without the kms hook, but post seth's requested output so we get an actual picture of what's going on.

You can make this work somewhat but it's really not all that fun and you have to be careful on not generating too big initramfs, I've ran that on my old laptop for a while but have recently also just switched that to booting from the /root partition.

Last edited by V1del (2024-02-22 10:35:07)

bread_lover · 2024-02-22 11:38:03

Here is my output from lsblk:

NAME   FSTYPE   FSVER            LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0  squashfs 4.0                                                                     0   100% /run/archiso/airootfs
sda                                                                                              
├─sda1 vfat     FAT32                        DC02-F0CA                                           
├─sda2                                                                                           
└─sda3 ntfs                                  5AE206A9E2068A09                                    
sdb                                                                                              
└─sdb1 ext4     1.0                          dc931642-d168-42c0-9547-9dc9d4e1ed30                
sdc    iso9660  Joliet Extension ARCH_202402 2024-02-01-12-07-52-00                              
├─sdc1 iso9660  Joliet Extension ARCH_202402 2024-02-01-12-07-52-00                              
└─sdc2 vfat     FAT16            ARCHISO_EFI 9C7A-9A67                                           
sr0

sdb1 is where my archlinux resides and where boot folder with my vmlinux and initramfs is. At this point I'm not sure if this is the "boot partition" I should be interested in.

Close but not quite you need to mount the correspondingly correct /dev/sdX where your ESP or /boot partition actually resides to /mnt/boot before the chroot

I must've been doing it really wrong as doing "mount /devsdb1/ /mnt" then "mount /dev/sdb1/ /mnt/boot" makes my enitre root filesystem visible udner /mnt/boot; so my vmliuz and initramfs is actaully under /mnt/boot/boot

You can make this work somewhat but it's really not all that fun and you have to be careful on not generating too big initramfs, I've ran that on my old laptop for a while but have recently also just switched that to booting from the /root partition

How to achieve booting from /root partition? Does it impact OS somehow or it doesn't matter?

Maybe if you remove the kms hook and skip the faillback initramfs

I think I've done skip initramfs fallback in the past due to boot space issues. And I don't see any hooks in my preset:

# mkinitcpio preset file for the 'linux' package on archiso

PRESETS=('archiso')

ALL_kver='/boot/vmlinuz-linux'
archiso_config='/etc/mkinitcpio.conf.d/archiso.conf'

archiso_image="/boot/initramfs-linux.img"

EDIT:
Forgive me my stupidity. I should be looking for hooks under archiso.conf file, right? So am I supposed to remove kms from there and add Nouveau explicitly (I use Nvidia GPU and lspci output points to nouveau as Kernel driver in use)?

Last edited by bread_lover (2024-02-22 11:43:20)

V1del · 2024-02-22 11:48:18

Your /boot partition is most likely /dev/sda1 since that's where the ESP is. To be sure sure, look at your /etc/fstab of your root partition (i.e. assuming you mount /dev/sdb1 to /mnt, that file will be under /mnt/etc/fstab).

For editing mkinitcpio hooks and modules you'd edit /etc/mkinitcpio.conf (... again from the view of your root partition if mounted to /mnt/ then /mnt/etc/mkinitcpio.conf and if chrooted it will logically be under /etc/mkinitcpio.conf).

So for properly checking you'd do a

mount /dev/sdb1 /mnt
mount /dev/sda1 /mnt/boot
arch-chroot /mnt

now things are logically as they should be. From there you can edit /etc/mkinitcpio.conf to remove the kms hook and instead adding the module of your graphics card to the MODULES=() array (though if you're already skipping the fallback, you're unlikely to gain much from that)... From that chrooted position what do you get from

lsblk -f
ls -lR /boot

bread_lover · 2024-02-22 12:21:45

now things are logically as they should be. From there you can edit /etc/mkinitcpio.conf to remove the kms hook and instead adding the module of your graphics card to the MODULES=() array (though if you're already skipping the fallback, you're unlikely to gain much from that)

Yes, I think they are now. After chroot, df -h shows that sdb1 is mounted on / and sda1 on boot. I will skip removing kms as you say it will not help much and will keep it at the back of my head a a last resort (or should I proceed with it anyway?).

Here is an output from lsblk -f:

NAME   FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0                                         
sda                                           
├─sda1                              2K   100% /boot
├─sda2                                        
└─sda3                                        
sdb                                           
└─sdb1                          330.1G    24% /
sdc                                           
├─sdc1                                        
└─sdc2                                        
sr0

Here from ls -lR /boot (although it is really long considering all files under boot/EFI/Microsoft and I guess we are not interested in that so I'll skip it; If I am wrong I will edit my post):

/boot:
total 64824
drwxr-xr-x 5 root root     1024 May 18  2020 EFI
drwxr-xr-x 2 root root     1024 May 14  2020 System Volume Information
drwxr-xr-x 6 root root     1024 Jul 15  2021 grub
-rwxr-xr-x 1 root root 45973504 Feb 21 16:41 initramfs-linux.img
-rwxr-xr-x 1 root root  7368704 Feb  1 17:16 intel-ucode.img
-rwxr-xr-x 1 root root 13033984 Feb 21 16:41 vmlinuz-linux

/boot/EFI:
total 3056
drwxr-xr-x 2 root root    1024 May 14  2020 Boot
drwxr-xr-x 2 root root    1024 May 14  2020 GRUB
drwxr-xr-x 3 root root    1024 May 14  2020 Microsoft
-rwxr-xr-x 1 root root 3126272 May 18  2020 intel-ucode.img

/boot/EFI/Boot:
total 128
-rwxr-xr-x 1 root root 131072 May 14  2020 bootx64.efi

/boot/EFI/GRUB:
total 128
-rwxr-xr-x 1 root root 131072 May 14  2020 grubx64.efi

100% of boot usage is certainly an issue here I assume.

V1del · 2024-02-22 12:33:48

You can remove the kms hook anyway, and if you e.g. "run nouveau" just as a secondary GPU on a laptop having it missing from the initramfs will not hurt you much. But if it's not that and since you're apparently using GRUB anyway I'd suggest you simply configure GRUB to read the kernel images from your root partition instead of the ESP.

To do that, going from the position above you can do

umount /boot
#/boot should ideally be currently empty now, or if there's anything only some random experiments you had with reinstalling the kernel while not having sda mounted there
mkdir /efi
mount /dev/sda1 /efi
mv /efi/{intel-ucode.img,vmlinuz-linux,initramfs-linux.img} /boot
pacman -S linux 
grub-install --target=x86_64-efi  --efi-directory=/efi --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg
#edit your /etc/fstab and change what's currently mounted to /boot to get mounted to /efi so you don't mask that path

bread_lover · 2024-02-22 14:19:51

During

grub-install --target=x86_64-efi  --efi-directory=/efi --bootloader-id=GRUB

I ran into

EFI variables are not supported on this system.
EFI variables are not supported on this system.
grub-install: error: efibootmgr failed to register the boot entry: No such file or directory.

EDIT:
Here is my bootctl output if it helps:

System:
Not booted with EFI

Available Boot Loaders on ESP:
          ESP: /efi (/dev/disk/by-partuuid/804a928a-22ab-4844-905e-d6e4bfcc8e27)
         File: └─/EFI/BOOT/bootx64.efi

Boot Loader Entries:
        $BOOT: /efi (/dev/disk/by-partuuid/804a928a-22ab-4844-905e-d6e4bfcc8e27)
        token: arch

I am confused about "Not booted with EFI"; is this something I should've enabled manually during installation? I did about 2 years ago and I don't remember much from the processs.

Last edited by bread_lover (2024-02-22 14:31:17)

V1del · 2024-02-22 14:52:02

That means your current ISO/stick is not booted in UEFI mode, this depends on how you're booting the stick, normally booting a stick in UEFI mode is designated as [UEFI] usb manufacturer name or so in your UEFI's bootloader. Which mainboard is this?

bread_lover · 2024-02-22 15:07:20

I figured out that I should choose UEFI partition the as boot method(not sure If my nomenclature is correct). Instead of choosing USB as a boot method I picked UEFI partition and your instruction worked without error. I can boot to arch linux as before from the GRUB menu, thank you very much for your time and expertise. But...

As I was in the mid of your instructions and I needed to reboot system I tried to undo moving files from efi to boot but there was no place to move back vmlinuz. After reboot I lost my Windows entry in the GRUB menu. Is it something serious or just a matter of another GRUB config changes?

Last edited by bread_lover (2024-02-22 15:09:07)

V1del · 2024-02-22 15:11:29

GRUB should've picked up the Windows entry again unless you didn't mount the EFI partition to /efi before running grub-mkconfig again on the second turnaround. What's in your /boot/grub/grub.cfg and /etc/default/grub right now? os-prober is installed right? Output of

os-prober

with the logical mounting setup discussed above?

bread_lover · 2024-02-22 15:33:59

lsblk -l

NAME  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0   7:0    0 766.5M  1 loop 
sda     8:0    0 476.9G  0 disk 
sda1    8:1    0   100M  0 part /efi
sda2    8:2    0   128M  0 part 
sda3    8:3    0 476.7G  0 part 
sdb     8:16   0 476.9G  0 disk 
sdb1    8:17   0 476.9G  0 part /
sdc     8:32   1  28.7G  0 disk 
sdc1    8:33   1   917M  0 part 
sdc2    8:34   1    15M  0 part 
sr0    11:0    1  1024M  0 rom

/boot/grub/grub.cfg

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
insmod part_gpt
insmod part_msdos
if [ -s $prefix/grubenv ]; then
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="2"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd1,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1  dc931642-d168-42c0-9547-9dc9d4e1ed30
else
  search --no-floppy --fs-uuid --set=root dc931642-d168-42c0-9547-9dc9d4e1ed30
fi
    font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
fi
terminal_input console
terminal_output gfxterm
if [ x$feature_timeout_style = xy ] ; then
  set timeout_style=menu
  set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
  set timeout=5
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-dc931642-d168-42c0-9547-9dc9d4e1ed30' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod ext2
	set root='hd1,gpt1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1  dc931642-d168-42c0-9547-9dc9d4e1ed30
	else
	  search --no-floppy --fs-uuid --set=root dc931642-d168-42c0-9547-9dc9d4e1ed30
	fi
	echo	'Loading Linux linux ...'
	linux	/boot/vmlinuz-linux root=UUID=dc931642-d168-42c0-9547-9dc9d4e1ed30 rw  loglevel=3 quiet
	echo	'Loading initial ramdisk ...'
	initrd	/boot/intel-ucode.img /boot/initramfs-linux.img
}
submenu 'Advanced options for Arch Linux' $menuentry_id_option 'gnulinux-advanced-dc931642-d168-42c0-9547-9dc9d4e1ed30' {
	menuentry 'Arch Linux, with Linux linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-advanced-dc931642-d168-42c0-9547-9dc9d4e1ed30' {
		load_video
		set gfxpayload=keep
		insmod gzio
		insmod part_gpt
		insmod ext2
		set root='hd1,gpt1'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1  dc931642-d168-42c0-9547-9dc9d4e1ed30
		else
		  search --no-floppy --fs-uuid --set=root dc931642-d168-42c0-9547-9dc9d4e1ed30
		fi
		echo	'Loading Linux linux ...'
		linux	/boot/vmlinuz-linux root=UUID=dc931642-d168-42c0-9547-9dc9d4e1ed30 rw  loglevel=3 quiet
		echo	'Loading initial ramdisk ...'
		initrd	/boot/intel-ucode.img /boot/initramfs-linux.img
	}
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/15_ostree ###
### END /etc/grub.d/15_ostree ###

### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/25_bli ###
if [ "$grub_platform" = "efi" ]; then
  insmod bli
fi
### END /etc/grub.d/25_bli ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/30_uefi-firmware ###
if [ "$grub_platform" = "efi" ]; then
	fwsetup --is-supported
	if [ "$?" = 0 ]; then
		menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' {
			fwsetup
		}
	fi
fi
### END /etc/grub.d/30_uefi-firmware ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg
fi
### END /etc/grub.d/41_custom ###

/etc/default/grub

# GRUB boot loader configuration

GRUB_DEFAULT=2
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet"
GRUB_CMDLINE_LINUX=""
GRUB_DISABLE_OS_PROBER=false

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable booting from LUKS encrypted devices
#GRUB_ENABLE_CRYPTODISK=y

# Set to 'countdown' or 'hidden' to change timeout behavior,
# press ESC key to display menu.
GRUB_TIMEOUT_STYLE=menu

# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console

# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=auto

# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX=keep

# Uncomment if you want GRUB to pass to the Linux kernel the old parameter
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true

# Uncomment and set to the desired menu colors.  Used by normal and wallpaper
# modes only.  Entries specified as foreground/background.
#GRUB_COLOR_NORMAL="light-blue/black"
#GRUB_COLOR_HIGHLIGHT="light-cyan/blue"

# Uncomment one of them for the gfx desired, a image background or a gfxtheme
#GRUB_BACKGROUND="/path/to/wallpaper"
#GRUB_THEME="/path/to/gfxtheme"

# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"

# Uncomment to make GRUB remember the last selection. This requires
# setting 'GRUB_DEFAULT=saved' above.
#GRUB_SAVEDEFAULT=true

# Uncomment to disable submenus in boot menu
#GRUB_DISABLE_SUBMENU=y

Os-prober is installed but it gives no output other than:

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

This is irrelevant I guess as sdc1 is Live USB.

EDIT:
When I run os-prober from my arch distro I got:

/dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi

EDIT2:
I think it is also worh mentioning that my grub files differ when I am on arch distro. In example I have entry for Windows in grub.cfg:

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-DC02-F0CA' {
	insmod part_gpt
	insmod fat
	set root='hd0,gpt1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  DC02-F0CA
	else
	  search --no-floppy --fs-uuid --set=root DC02-F0CA
	fi
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
### END /etc/grub.d/30_os-prober ###

Is there a way to restore Windows entry on GRUB menu from my arch linux now?

EDIT3:
Yes, I managed to restore Windows entry by doing:

mount /dev/sda1 /mnt
os-prober
grub-mkconfig -o /boot/grub/grub.cfg

All commands must be executed with sudo if user is not a root. I happily recovered my access to Arch linux. Big thanks to you V1del for your time and engagement. Before you marked it as solved could you please tell me if from now on (i.e. after grub reconfig to boot from sdb1) I can safely proceed with the next system updates and not worry about issues with boot space? Once again: thank you.

Last edited by bread_lover (2024-02-22 17:28:18)

V1del · 2024-02-22 17:46:41

If you fixed the fstab so that it mounts the ESP to /efi instead of /boot then yes, future updates should generate images on the / partition which will have more space.

You should be marking as [SOLVED] by editing the title in your first post if you feel it is.

Arch Linux

#1 2024-02-21 19:58:25

Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#2 2024-02-21 21:04:23

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#3 2024-02-22 00:01:39

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#4 2024-02-22 10:17:30

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#5 2024-02-22 10:23:07

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#6 2024-02-22 10:32:52

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#7 2024-02-22 11:38:03

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#8 2024-02-22 11:48:18

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#9 2024-02-22 12:21:45

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#10 2024-02-22 12:33:48

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#11 2024-02-22 14:19:51

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#12 2024-02-22 14:52:02

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#13 2024-02-22 15:07:20

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#14 2024-02-22 15:11:29

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#15 2024-02-22 15:33:59

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

#16 2024-02-22 17:46:41

Re: Initramfs unpacking failed: ZSTD-compressed data is truncated [SOLVED]

Board footer