• Status Closed
  • Percent Complete
    100%
  • 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

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..

Closed by  Andreas Baumann
13.01.2022 17:10
Reason for closing:  Fixed
Admin
Andreas Baumann commented on 06.01.2022 14:21

Most could just be a side effect of systemd-udevd not running:

[  OK  ] Stopped Rule-based Manager for Device Events and Files.                                         
         Starting Rule-based Manage…for Device Events and Files...                                       
[FAILED] Failed to start Rule-based…r for Device Events and Files.                                       
Admin
Andreas Baumann commented on 06.01.2022 14:24

And of course:

emergency.service: Executable /usr/bin/plymouth missing, skipping: No such y

Really?

Admin
Andreas Baumann commented on 06.01.2022 14:33

This seems to affect at least i686 too..

Admin
Andreas Baumann commented on 07.01.2022 11:39

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.

Admin
Andreas Baumann commented on 07.01.2022 12:58

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.

Admin
Andreas Baumann commented on 08.01.2022 09:08

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..

Admin
Andreas Baumann commented on 08.01.2022 12:31

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.

Admin
Andreas Baumann commented on 08.01.2022 13:02

I spot a dependency of systemd-libs to zstd, I wonder. Let's force rebuild systemd
and see if the problem persists.

Arne Wörner commented on 13.01.2022 15:47

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

Admin
Andreas Baumann commented on 13.01.2022 15:53

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..

Admin
Andreas Baumann commented on 13.01.2022 16:31

I'm going for the "proper" patch matching the segment in all cases..
Not the "disable assembly in make" patch..

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing