Bug#790560: udev fails to start on sparc boot, breaking boot

Control: reassign 790556 binutils Control: reassign -1 binutils Control: forcemerge -1 790556 Control: retitle -1 LTO and gold linker broken on sparc Am 08.09.2015 um 17:25 schrieb Artyom Tarasenko: > On Sun, Aug 30, 2015 at 3:29 PM, Michael Biebl wrote: >> control: user -1

Bug#790560: udev fails to start on sparc boot, breaking boot

On Sun, Aug 30, 2015 at 3:29 PM, Michael Biebl wrote: > control: user -1 debian-sp...@lists.debian.org > control: usertag -1 sparc > control: tags -1 + help > > On Tue, 30 Jun 2015 11:04:20 +0300 Meelis Roos wrote: >> Package: udev >> Version: 221-1 >> Severity:

Bug#790560: udev fails to start on sparc boot, breaking boot

control: user -1 debian-sp...@lists.debian.org control: usertag -1 sparc control: tags -1 + help On Tue, 30 Jun 2015 11:04:20 +0300 Meelis Roos mr...@linux.ee wrote: Package: udev Version: 221-1 Severity: critical Justification: breaks the whole system udev 220-7 broke sparc boot with

Bug#790560: udev fails to start on sparc boot, breaking boot

Reported a binutils/gold bug for it: https://sourceware.org/bugzilla/show_bug.cgi?id=18855 -- Regards, Artyom Tarasenko SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu

Bug#790560: udev fails to start on sparc boot, breaking boot

On Mon, 2015-08-17 at 18:34 +0200, Artyom Tarasenko wrote: On Mon, Aug 10, 2015 at 9:33 AM, Frans van Berckel fberc...@xs4all.nl wrote: Checked with binutils_2.25.1-1_sparc64.deb . -Wl,-fuse-ld=gold still produces broken binaries. Tried manually compiling a couple of systemd binaries

Bug#790560: udev fails to start on sparc boot, breaking boot

On Mon, Aug 10, 2015 at 9:33 AM, Frans van Berckel fberc...@xs4all.nl wrote: On Fri, 2015-08-07 at 20:48 +0200, Frans van Berckel wrote: On Fri, 2015-08-07 at 18:24 +0200, Artyom Tarasenko wrote: After 10 hours of building (my machine is probably not the fastest one), I can only confirm

Bug#790560: udev fails to start on sparc boot, breaking boot

On Fri, 2015-08-07 at 20:48 +0200, Frans van Berckel wrote: On Fri, 2015-08-07 at 18:24 +0200, Artyom Tarasenko wrote: After 10 hours of building (my machine is probably not the fastest one), I can only confirm that the gold linker is still broken in binutils_2.25-11_sparc64.deb Am I

Bug#790560: udev fails to start on sparc boot, breaking boot

After 10 hours of building (my machine is probably not the fastest one), I can only confirm that the gold linker is still broken in binutils_2.25-11_sparc64.deb Also I added ifneq ($(findstring $(DEB_BUILD_ARCH), sparc),) LD=ld endif to debian/rules (that's the only part of the patch

Bug#790560: udev fails to start on sparc boot, breaking boot

On Fri, 2015-08-07 at 18:24 +0200, Artyom Tarasenko wrote: After 10 hours of building (my machine is probably not the fastest one), I can only confirm that the gold linker is still broken in binutils_2.25-11_sparc64.deb Am I right, there are some fails / test error's, building binutils_2.25

Bug#790560: udev fails to start on sparc boot, breaking boot

Richard Mortimer ri...@oldelvet.org.uk writes: So maybe the code is trying to use the wrong string as input to chdir and hence failing. Is udev using the gold linker during build? I've been looking into a bug where in certain circumstances, when linking with gold, string literal function

Bug#790560: udev fails to start on sparc boot, breaking boot

That's what I see in the strace log: set_tid_address(0xf80100133790) = 9184 set_robust_list(0xf801001337a0, 24) = 0 rt_sigaction(SIGRTMIN, {0xf801006c6da0, [], SA_SIGINFO}, NULL, 0xf801006d2098, 8) = 0 rt_sigaction(SIGRT_1, {0xf801006c6c40, [], SA_RESTART|SA_SIGINFO},

Bug#790560: udev fails to start on sparc boot, breaking boot

Here is the correspondinf part of the gdb session with symbols from systemd-dbg_224-1_sparc64.deb: (gdb) run Starting program: /lib/systemd/systemd-udevd [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/sparc64-linux-gnu/libthread_db.so.1. Breakpoint 3, main

Bug#790560: udev fails to start on sparc boot, breaking boot

And here is an attempt to debug why parse_proc_cmdline fails: Breakpoint 3, main (argc=optimized out, argv=0x7fefc98) at ../src/udev/udevd.c:1662 1662r = parse_proc_cmdline(parse_proc_cmdline_item); (gdb) step parse_proc_cmdline (parse_item=0x1011180

Bug#790560: udev fails to start on sparc boot, breaking boot

It looks like stdout and/or stderr output is mixed up with the strace output but it looks udevd is failing because the chdir to / fails. Notes inline below. (Caution I'm comparing against current systemd git HEAD and not any specific version)

Bug#790560: udev fails to start on sparc boot, breaking boot

On 06/08/2015 12:48, Artyom Tarasenko wrote: Here is the correspondinf part of the gdb session with symbols from systemd-dbg_224-1_sparc64.deb: Many thanks. The log below pretty much does confirm that it is taking the suspected path through the code. Some steps are not visible to the

Bug#790560: udev fails to start on sparc boot, breaking boot

On Thu, 2015-08-06 at 16:57 +0200, Michael Biebl wrote: Looks like this should be fixed in binutils for good instead of having individual packages work around that. They are active changing the sources in git the past months. Searching for Sparc. Question, Is the bug stil there?

Bug#790560: udev fails to start on sparc boot, breaking boot

Am 06.08.2015 um 16:13 schrieb d...@mattli.us: Richard Mortimer ri...@oldelvet.org.uk writes: So maybe the code is trying to use the wrong string as input to chdir and hence failing. Is udev using the gold linker during build? It is, indeed. We had a hack in debian/rules for a while, to

Bug#790560: udev fails to start on sparc boot, breaking boot

It appears snapshot.debian.org only has udev 215-8, 218-1, 218-2, 218-8, 220-6, 220-7, 221-1 for sparc. with systemd 215-8: 218-2: udev OK 218-8: udev OK 220-6 fails the same 220-7 and 221-1 -- Meelis Roos (mr...@linux.ee) -- To UNSUBSCRIBE, email to

Bug#790560: udev fails to start on sparc boot, breaking boot

Am 30.06.2015 um 10:04 schrieb Meelis Roos: Package: udev Version: 221-1 Severity: critical Justification: breaks the whole system udev 220-7 broke sparc boot with strange messages about different options of udevadm not supported (--cleanup-db un recognized, --action=add not recognized,

Bug#790560: udev fails to start on sparc boot, breaking boot

Package: udev Version: 221-1 Severity: critical Justification: breaks the whole system udev 220-7 broke sparc boot with strange messages about different options of udevadm not supported (--cleanup-db un recognized, --action=add not recognized, --timeout=10 not recognized). Upgraded to 221-1 with

Bug#790560: udev fails to start on sparc boot, breaking boot

Control: found -1 220-7 Control: severity -1 important (downgrading, not a release architecture) Am 30.06.2015 um 10:04 schrieb Meelis Roos: Package: udev Version: 221-1 Severity: critical Justification: breaks the whole system udev 220-7 broke sparc boot with strange messages about

Bug#790560: udev fails to start on sparc boot, breaking boot

Hi, Am 30.06.2015 um 21:48 schrieb Meelis Roos: Did older udev versions work? Yes. By dpkg.log, 215-18 was the previous version before 220-7 that broke. Unfortunatley, 215 does not seem to be available from Debian mirrors any more. 215-18 seems to be available from snapshot.debian.org,

Bug#790560: udev fails to start on sparc boot, breaking boot

Unfortunately snapshots.debian.org [1] doesn't seem to have any sparc64 binaries which would have simplified that process somewhat, as you could have quickly installed older versions. And we don't have any sparc64 porter boxes :-/ But it is normal sparc debian, just sparc64 kernel. Got the

Bug#790560: udev fails to start on sparc boot, breaking boot

Upgraded to 221-1 with init=/bin/bash and chroot, still the same: Loading, please wait... e or neveruudevadm: unrecognized option '--action=add' Is that e or neveru a corruption of some sort? Yes, it seems so. With different kernel with no initramfs, there were more corrupted strings

Bug#790560: udev fails to start on sparc boot, breaking boot

Michael Biebl bi...@debian.org writes: If 215-8 was working successfully, finding the faulty commit would indeed be very helpful. If you know how to use git bisect, you could use that to determine the commit. This will be a lengthy process though and probably not something you want to do on a