You are not logged in.
I'm new to systemd-boot having used grub for years.
On a new clean install of arch after first boot I receive the error "Initramfs unpacking failed: junk in compressed archive".
I can resolve the issue by changing mkinitcpio.conf to use anything other than the default gzip compression.
Edit: I've not found any other reports of this problem. I did find the following post but had already tried fsck and building my partitions from scratch on clean disks and each time reproduced this problem.
Any ideas?
Last edited by smash (2016-10-04 09:26:16)
Offline
Para todos todo, para nosotros nada
Online
Apologies, I did find that post but had already tried fsck'ing my partitions which showed no problem at all. I also completely rebuilt my partitions just to be sure and still have the same reproducible problem each time I load Arch (3 times with completely clean disks).
Offline
I can resolve the issue by changing mkinitcpio.conf to use anything other than the default gzip compression.
What is the output of:
grep -v '^$\|^#' /etc/mkinitcpio.conf
Does GRUB boot fine with a gzipped initramfs?
Please also post your systemd-boot configuration files.
Para todos todo, para nosotros nada
Online
This occurs immediately after a base Arch installation, thus any config files are default.
grep -v '^$\|^#' /etc/mkinitcpio.conf
MODULES=""
BINARIES=""
FILES=""
HOOKS="base udev autodetect modconf block filesystems keyboard fsck"
Does GRUB boot fine with a gzipped initramfs?
I purposely didn't use GRUB due to having a UEFI system. I'll need to create a boot USB disk to test this now.
Please also post your systemd-boot configuration files.
These are stock standard also and contain nothing other than commented out lines.
Offline
These are stock standard also and contain nothing other than commented out lines.
That makes no sense, you have to create the configuration file yourself.
Para todos todo, para nosotros nada
Online
That makes no sense, you have to create the configuration file yourself.
OK, now I get you. Nothing fancy.
loader.conf:
timeout 15
default arch
arch.conf:
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
initrd /intel-ucode.img
options root=PARTUUID=4e751e1d-f486-46fa-b46f-92ec5f418101 rootfstype=ext4 rw add_efi_memmap
Tested with GRUB and GRUB loads the file no trouble. Systemd-boot doesn't like something!
Last edited by smash (2016-09-27 12:19:10)
Offline
I don't know if it's related to your problem, but the Intel-ucode has to be the first initrd. Otherwise the CPU microcode will not be updated.
Offline
Tested with GRUB and GRUB loads the file no trouble.
How confusing
Are those rootfstype & add_efi_memmap parameters applied by GRUB?
Have you tried without those added parameters?
If you `umount` the EFI system partition, is there still an initramfs and/or kernel image in /boot?
For the record, although the microcode line should be before the initramfs line my system will still boot with that order reversed.
Para todos todo, para nosotros nada
Online
Are those rootfstype & add_efi_memmap parameters applied by GRUB?
Have you tried without those added parameters?
I don't recall if GRUB added them or not (not at my PC currently), but I ensured GRUB used the same kernel parameters and options that were setup in systemd-boot.
If you `umount` the EFI system partition, is there still an initramfs and/or kernel image in /boot?
No, my EFI partition is mounted as /boot
For the record, although the microcode line should be before the initramfs line my system will still boot with that order reversed.
I would like to say I did that on purpose to see if you were paying attention, but alas it was my mistake. Thanks
I find it interesting that there is only a problem when gzip is used, I have tested every other compression method available in the mkinitcpio.conf (and cat) and they all work fine. In my mind this suggests a problem in the method used to gzip the file, but mkinitcpio simply gzips with no options set and shouldn't cause an issue (and apparently doesn't for a ton of other arch users).
Offline
Does a direct NVRAM entry work?
https://wiki.archlinux.org/index.php/EFISTUB#efibootmgr
Please omit the rootfstype=ext4 & add_efi_memmap parameters for that entry, they should not be needed.
Also, are the systemd-boot configurations being applied correctly?
# efibootmgr -v
Para todos todo, para nosotros nada
Online
Does a direct NVRAM entry work?
Not sure that helps determine what the problem is since we know GRUB can load the file fine and systemd-boot only has a problem if the file is gziped.
Offline
OK, went to test some other things and it seems moving intel-ucode.img to the first initrd line has resolved the problem! Confirmed by moving it back to the 2nd entry.
If someone is able to explain why it would be appreciated. If I remove the initrd line for intel-ucode all together, the system boots fine, but if it is 'incorrectly' loaded on the 2nd entry systemd-boot fails to extract initramfs correctly and won't boot.
Thanks for your help Head_on_a_Stick.
Offline