Re: udev fails to start on sparc boot, breaking boot
control: user -1 debian-sparc@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 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 init=/bin/bash and chroot, still the same: Loading, please wait... e or neveruudevadm: unrecognized option '--action=add' Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount .[ 63.869458] input: Sun Mouse as /devices/root/f005f9c0/f00601b4/f0061504/f0064df4/serio1/input/1 ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. udevadm: unrecognized option '--timeout=10' Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. done. Gave up waitin[ 94.135656] usbcore: registered new interface driver usbfs g for [ 94.207229] usbcore: registered new interface driver hub root [ 94.276486] usbcore: registered new device driver usb device. Comm[ 94.350131] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver on prob[ 94.435984] ehci-pci: EHCI PCI platform driver lems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did[ 94.558185] uhci_hcd: USB Universal Host Controller Interface driver the system wait long e[ 94.658718] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver nough?) We'll need help from our sparc porters on this bug report. So CCing them and tagging the bug report accordingly. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: 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 use ld.bfd on sparc due to build failures related to gtk-doc [1]. When the gtk-doc bits were removed from systemd, this hack was dropped again [2] I've been looking into a bug where in certain circumstances, when linking with gold, string literal function arguments are corrupted. This problem was also breaking qt, specifically moc. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773590 Looks like this should be fixed in binutils for good instead of having individual packages work around that. Does any want to try rebuilding the package with ld.bfd to check if it's working properly then? Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760879 [2] https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=ff3e6f6fc82adeeb5341b3bbd9824b2591965af6 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#790556: systemctl crashes, systemd setup fails
control: -1 user debian-sparc@lists.debian.org control: -1 usertag sparc control: -1 retitle systemctl crashes, systemd setup fails on sparc Am 01.07.2015 um 11:08 schrieb Meelis Roos: I had trouble with udev 220-7 hanging on sparc boot with corrupted messages on serial console. Because it was hard to report in understandable way, I booted init=/bin/bash and tried to upgrade all packages to try the lastest before reporting. However, now systemd setup crashes and breaks the system even more: Did you have a version which worked correctly on sparc? With udev 218-8: systemd 218-8 OK systemd 220-6 fails like described mduring install: *** Error in `systemctl': free(): invalid pointer: 0xf79f889c *** Aborted Initializing machine ID from D-Bus machine ID.rFri/*** Error in `systemctl': free(): invalid pointer: 0xf7d8489c *** Aborted *** Error in `systemctl': free(): invalid pointer: 0xf7e1089c *** CCing our debian-sparc porters mailing list. Would be great if they can look into this issue. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: 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, --timeout=10 not recognized). Upgraded to 221-1 with init=/bin/bash and chroot, still the same: Loading, please wait... e or neveruudevadm: unrecognized option '--action=add' Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount .[ 63.869458] input: Sun Mouse as /devices/root/f005f9c0/f00601b4/f0061504/f0064df4/serio1/input/1 ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. udevadm: unrecognized option '--timeout=10' Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. done. Gave up waitin[ 94.135656] usbcore: registered new interface driver usbfs g for [ 94.207229] usbcore: registered new interface driver hub root [ 94.276486] usbcore: registered new device driver usb device. Comm[ 94.350131] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver on prob[ 94.435984] ehci-pci: EHCI PCI platform driver lems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did[ 94.558185] uhci_hcd: USB Universal Host Controller Interface driver the system wait long e[ 94.658718] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver nough?) - Check root= (did[ 94.763559] hidraw: raw HID events driver (C) Jiri Kosina the system [ 94.841188] usbcore: registered new interface driver usbhid wait [ 94.912277] usbhid: USB HID core driver for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/sda1 does not exist. Dropping to a shell! Kernel is 4.0.5-1 from debian (4.0.0-2-sparc64). -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: sparc (sparc64) CCing our debian-sparc porters mailing list. Would be great if the sparc porters can look into this issue. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: VIO on sparc / udev support
Am 13.05.2013 13:45, schrieb Julien Cristau: Michael, On Mon, May 13, 2013 at 02:51:51 +0200, Michael Biebl wrote: Since no-one in the systemd/udev team is using SPARC hardware, I was wondering, if vio_type would have a better home in e.g. the sparc-utils [2] package, where it would be maintained and tested by people with knowledge of that architecture. I don't think that would make much sense, and this belongs with the related utils in udev IMO. Care to elaborate? That helper is highly sparc specific and it's an odd one, which doesn't really fit into udev. E.g. it's built on all architectures, then thrown away later during install. It's just weird. Take s390 as an example: The s390 specific helpers and udev rules are shipped in the s390-tools package and I think it would make a lot of sense to do the same for sparc. Even if it would only be for consistencies sake. Seeing a bug report like [3], it's not actually clear to me, if vio_type is still functional with newer kernel releases and for which type of hardware this is actually required. I poked Marco about this, but he doesn't remember the details anymore. Your [3] points at an udev packaging bug. How does it relate to newer kernel releases? The hardware for which this is required was described in #526621, so I don't really get that question either... Well, maybe the kernel got autoloading for that those types of devices, who knows. Something similar happened for e.g. cpufreq drivers. So I think this question is justified, if this helper is still required today and for what setups. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: VIO on sparc / udev support
Hi SPARC porters, hi Jurij! Since my last attempt to contact Jurij wasn't successful and I'm actually not sure, if Jurij is still active (as a SPARC porter), I'm reposting the full email, hoping to gather some feedback from the Debian SPARC porters. Regards, Michael Am 29.03.2013 22:16, schrieb Michael Biebl: Hi Jurij, afaics you are one of the SPARC porters and the original bug submitter of [1]. As you are probably aware, the udev sources have been merged into the systemd source tree. This also affects the Debian udev package which will be built from the systemd source package in the future. While preparing a new release and importing bits from the old udev package I stumbled upon vio_type and it's accompanying udev rules and was wondering what to do about that. Since no-one in the systemd/udev team is using SPARC hardware, I was wondering, if vio_type would have a better home in e.g. the sparc-utils [2] package, where it would be maintained and tested by people with knowledge of that architecture. Seeing a bug report like [3], it's not actually clear to me, if vio_type is still functional with newer kernel releases and for which type of hardware this is actually required. I poked Marco about this, but he doesn't remember the details anymore. Specifically, this would mean moving the /lib/udev/vio_type helper binary and the VIO bits from /lib/udev/rules.d/80-drivers.rules into sparc-utils proper. Jurij, what do you think about the idea in general? Do you also think this would make sense or do you see problems with this proposal? If you are open to the idea, we could discuss and work on the technical details. (Please CC the pkg-systemd-maintainers m-l on your reply) Cheers, Michael [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526621 [2] http://packages.qa.debian.org/s/sparc-utils.html [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678264#96 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: FTBFS on sparc: test-suite fails in timeout-test
On 30.09.2011 19:19, Michael Biebl wrote: Source: libsoup2.4 Version: 2.36.0-1 Severity: serious The test-suite fails on sparc with timeout-test: 5 error(s). Run with '-d' for details FAIL: timeout-test uri-parsing: OK PASS: uri-parsing 1 of 16 tests failed Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=libsoup make[3]: *** [check-TESTS] Error 1 make[2]: *** [check-am] Error 2 make[3]: Leaving directory `/build/buildd-libsoup2.4_2.36.0-1-sparc-QfTD7j/libsoup2.4-2.36.0/tests' make[2]: Leaving directory `/build/buildd-libsoup2.4_2.36.0-1-sparc-QfTD7j/libsoup2.4-2.36.0/tests' make[1]: *** [check-recursive] Error 1 make: *** [debian/stamp-makefile-check] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Full build log at https://buildd.debian.org/status/fetch.php?pkg=libsoup2.4arch=sparcver=2.36.0-1stamp=1317316945 I guess we need help with this bug. It would be great if sparc porters could have a look. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#651934: How to debug seed FTBFS on sparc?
tags 651934 + help thanks Hi Peter, Am 26.02.2012 03:19, schrieb peter green: mmm, the webkit (webkit is the source package for libjavascriptcore) build log has a huge number of cast alignment warnings :( worse the file in which the error occoured is generated at webkit build time and is therefore not available in the webkit source package. I don't have the resources to build webkit on sparc in a reasonable time. Since testing an unstable have different versions of both seed and webkit. I decided the next thing to try was to build both testing's version of seed and unstable's versions of seed in both testing and unstable to try and narrow down which package caused the regression. However all four combinations failed with a bus error so it seems this regression happened before the version of webkit that is now in testing. Could you try building seed 3.2 against the same version of webkit as seed 3.0 was built? According to [1], this should be 1.4.2-1 [2]. You can get those packages from snapshot.d.o [3]. This should help narrow down the problem. Michael [1] https://buildd.debian.org/status/fetch.php?pkg=seedarch=sparcver=3.0.0-2stamp=1310476647 [2] Get:235 http://mirror-ubc.debian.org/debian/ unstable/main libwebkitgtk-3.0-common all 1.4.2-1 [782 kB] Get:236 http://mirror-ubc.debian.org/debian/ unstable/main libwebkitgtk-3.0-0 sparc 1.4.2-1 [6312 kB] Get:237 http://mirror-ubc.debian.org/debian/ unstable/main libwebkitgtk-3.0-dev sparc 1.4.2-1 [163 kB] [3] http://snapshot.debian.org/package/webkitgtk%2B/1.4.0-1/ -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f4e35cc.8000...@michaelbiebl.de
Please reschedule build for knetworkmanager_0.2-2
Hi, knetworkmanager_0.2-1 has been held back from entering testing because it wasn't built for the arm, hppa and sparc architecture for quite some time. Please reschedule builds for these architectures. Thanks, Michael P.S. The build failure on arm wasn't caused by knetworkmanager but a temporary glitch in glibc which is now fixed. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
