- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Packages
-
Assigned To
Andreas Baumann - Operating System pentium4
- Severity Critical
- Priority High
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: Arch Linux 32
Opened by Andreas Baumann - 06.01.2022
Last edited by Andreas Baumann - 13.01.2022
Opened by Andreas Baumann - 06.01.2022
Last edited by Andreas Baumann - 13.01.2022
FS#225 - [zstd] 1.5.1, zstd compressed ramdisk fails to load properly
kernel issue with some network card and/or
systemd subservice not working add all
I cannot login remotely or locally.
System drops to maintainance shell..
Not a single systemd subdaemon is working..
This also effectively kills all i486 build machines..
Most could just be a side effect of systemd-udevd not running:
And of course:
emergency.service: Executable /usr/bin/plymouth missing, skipping: No such y
Really?
This seems to affect at least i686 too..
Works fine with 1.5.0.
You can use the emergency shell to get a zstd-1.5.0 from archive.archlinux32.org
and then just rebuild your ramdisks.
Using -19 for zstd during mkinitcpio didn't help. Using zstd 1.5.0 or 1.5.1
during mkinitcpio doesn't seem to make a difference, so I suspect it is during
uncompression with 1.5.1 only.
This makes it difficult, if userland requires zsts 1.6.x or so and 1.5.x is needed
for the ramdisk.
It could also be that kernel modules compressed with zstd are failing to unpack..
otoh, it seems even the broken bootup was able to load modules..
Reilly interesting: when generating a ramdisk with xz compression the error still
happens with zstd 1.5.1, not with zstd 1.5.0. So there is some module decompression
or something else choaking on zstd 1.5.1 during early boot.
I spot a dependency of systemd-libs to zstd, I wonder. Let's force rebuild systemd
and see if the problem persists.
Is this related?
Jan 13 15:40:55 neo systemd-coredump[25656]: /usr/lib/systemd/systemd-coredump: error while loading shared libraries: libzstd.so.1: cannot enable executable stack as shared object requires: Operation not permitted
And I found these links:
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=2035802 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103863
Thanks for the link, yes, this sounds promising (I mean, it's the same bug most
likely). Let me try to apply the mentioned fix:
https://github.com/pld-linux/zstd/commit/b46fcfe9f8699ec8d1041d77902cdf6b2b798e5a and see what happens..
I'm going for the "proper" patch matching the segment in all cases..
Not the "disable assembly in make" patch..