Re: after Debian update most apps crash - libffi issue?
i too am having problems with libffi8 on a powermac g5 # dmesg ... [ 16.257543] fail2ban-server[384]: illegal instruction (4) at 3fffb4283970 nip 3fffb4283970 lr 3fffb4282f90 code 1 in libffi.so.8.1.0[3fffb427b000+c000] ... # ls -l libffi* -rw-r--r-- 1 root root 68696 Feb 20 2021 libffi.so.7.1.0 -rw-r--r-- 1 root root 68720 Sep 24 00:00 libffi.so.8.1.0 i went back to 7.1.0 and there are no more messages about illegal instructions cam On Sun, Sep 26, 2021 at 5:45 AM Riccardo Mottola wrote: > Hi, > > I upgraded my iMac G5 to latest debian, including kernel 5.14 ! > The good thing is that the new kernel boots and X11 comes up. > > The bad news is lots of applications crash and they all have one thing > in common, libffi. > > > So e.g. a build of ArcticFox fails: > multix@PPC970FX:~/code/Arctic-Fox$ ./mach build > /usr/bin/which: this version of `which' is deprecated; use `command > -v' in scripts instead. > Illegal instruction > > dmesg shows: > [18439.269485] python2.7[4993]: illegal instruction (4) at > 7fffabff42fc nip 7fffabff42fc lr 7fffabff42ec code 1 in > libffi.so.8.1.0[7fffabff+1] > [18439.269547] python2.7[4993]: code: 6042 3d205858 6000 > 61295858 3880 387e03c8 f9228590 4bffe119 > [18439.269555] python2.7[4993]: code: e8410028 6000 7fe3fb78 > 392285b8 <7c004eee> 6000 39228950 7c004fae > > > GNUMail fails to start up: > Program received signal SIGILL, Illegal instruction. > 0x75d08970 in ?? () from > /usr/lib/powerpc64-linux-gnu/libffi.so.8 > (gdb) bt > #0 0x75d08970 in ?? () from > /usr/lib/powerpc64-linux-gnu/libffi.so.8 > #1 0x75d07f90 in ?? () from > /usr/lib/powerpc64-linux-gnu/libffi.so.8 > #2 0x75d02d10 in ?? () from > /usr/lib/powerpc64-linux-gnu/libffi.so.8 > #3 0x76d02be0 in cifframe_from_signature (info= out>) at cifframe.m:196 > #4 0x77055cf4 in -[GSFFIInvocation initWithMethodSignature:] > (self=0x1002ac1c0, _cmd=, > aSignature=0x1002a8180) at GSFFIInvocation.m:299 > #5 0x76e8b130 in +[NSInvocation > invocationWithMethodSignature:] (self=, > _cmd=, _signature=0x1002a8180) at NSInvocation.m:332 > #6 0x76f5cf68 in +[NSRunLoop _runLoopForThread:] > (self=, _cmd=, > aThread=) at NSRunLoop.m:790 > #7 0x76f5a160 in +[NSRunLoop currentRunLoop] > (self=0x77328568 <_OBJC_Class_NSRunLoop>, > _cmd=) at NSRunLoop.m:827 > #8 0x76f5b4cc in +[NSRunLoop initialize] (self= out>, _cmd=) at NSRunLoop.m:759 > #9 0x76aa41e8 in ?? () from > /usr/lib/powerpc64-linux-gnu/libobjc.so.4 > #10 0x76aa4368 in ?? () from > /usr/lib/powerpc64-linux-gnu/libobjc.so.4 > #11 0x76aa4830 in ?? () from > /usr/lib/powerpc64-linux-gnu/libobjc.so.4 > #12 0x724a4680 in -[XGServer(EventOps) > setupRunLoopInputSourcesForMode:] (self=0x1003ec3d0, > > > I guess not a coincidence! > > Riccardo > > -- > Sent with GNUMail from GNUstep on a Raspberry PI 4. > >
Re: after Debian update most apps crash - libffi issue?
hi, after ./autogen.sh && ./configure && make i then copied the new libffi.so.8.1.0 from ~/libffi/powerpc64-unknown-linux-gnu/.libs to /usr/lib/powerpc64-linux-gnu and that solved it. no more illegal instruction messages On Tue, Sep 28, 2021 at 12:44 AM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello! > > On 9/28/21 06:18, Cameron MacPherson wrote: > > i too am having problems with libffi8 on a powermac g5 > > > > # dmesg > > ... > > [ 16.257543] fail2ban-server[384]: illegal instruction (4) at > > 3fffb4283970 nip 3fffb4283970 lr 3fffb4282f90 code 1 in > > libffi.so.8.1.0[3fffb427b000+c000] > > ... > > # ls -l libffi* > > -rw-r--r-- 1 root root 68696 Feb 20 2021 libffi.so.7.1.0 > > -rw-r--r-- 1 root root 68720 Sep 24 00:00 libffi.so.8.1.0 > > > > i went back to 7.1.0 and there are no more messages about illegal > > instructions > > Could you please help debugging this? I'm currently not at home and > don't have access to my Powerbook G4. > > Please try building libffi from git as I'm still a bit skeptical that > Ricardo built the upstream version properly. I don't see any reason > why the regression shouldn't be a result of an upstream change but in > the Debian package as the Debian package doesn't do anything special. > > $ apt build-dep libffi > $ git clone https://github.com/libffi/libffi.git > $ cd libffi > $ ./autogen.sh && ./configure && make > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: after Debian update most apps crash - libffi issue?
i ran apt install --reinstall libffi8, restarted the system and the following messages reappeared [ 16.874069] fail2ban-server[384]: illegal instruction (4) at 3fff7ef95970 nip 3fff7ef95970 lr 3fff7ef94f90 code 1 in libffi.so.8.1.0[3fff7ef8d000+c000] [ 16.874154] fail2ban-server[384]: code: b1090008 f949 4e800020 6000 6042 [ 16.874176] fail2ban-server[384]: code: 8123 712a0008 41820018 39230004 <7c004eee> 39230020 7c004fae 4bfffaf4 after rm -rf ~/libffi, git clone, autogen, this time i ran ./configure with --disable-exec-static-tramp and then copied the new libffi.so.8 to /usr/lib/powerpc64-linux-gnu/ once again restarted the system and no more messages on the console or in the logs about libfffi # ls -l libffi* lrwxrwxrwx 1 root root15 Sep 28 01:22 libffi.so -> libffi.so.8.1.0 lrwxrwxrwx 1 root root15 Feb 20 2021 libffi.so.7 -> libffi.so.7.1.0 -rw-r--r-- 1 root root 68696 Feb 20 2021 libffi.so.7.1.0 lrwxrwxrwx 1 root root15 Sep 24 00:00 libffi.so.8 -> libffi.so.8.1.0 -rw-r--r-- 1 root root 78152 Sep 28 01:47 libffi.so.8.1.0 september 28th is the one i just compiled replacing the one contained in the libff8 package. i dont know the standard way of verifying which library is being used. On Tue, Sep 28, 2021 at 1:40 AM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello! > > On 9/28/21 10:33, Cameron MacPherson wrote: > > after ./autogen.sh && ./configure && make i then copied the new > > libffi.so.8.1.0 from ~/libffi/powerpc64-unknown-linux-gnu/.libs to > > /usr/lib/powerpc64-linux-gnu and that solved it. no more illegal > > instruction messages > > Did you verify that it is actually using the proper version? > > You need to make sure 100% that this version fixes it while the > libffi.so.8.1.0 from the Debian package causes the crash. > > Also, can you check whether passing "--disable-exec-static-tramp" > makes a difference? > > We need to find out why the Debian package causes SIGILL and we > still don't know why. It gets particularly strange when the issue > cannot be reproduced with the upstream source. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: after Debian update most apps crash - libffi issue?
after running the commands you listed i repeated my process with the new libffi.so.8 from v3.4.2 vs HEAD and there is no change. both of them work. i am using gcc 11.2.0-7 On Tue, Sep 28, 2021 at 2:07 AM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hi Cameron! > > On 9/28/21 10:59, Cameron MacPherson wrote: > > i ran apt install --reinstall libffi8, restarted the system and the > > following messages reappeared > > > > [ 16.874069] fail2ban-server[384]: illegal instruction (4) at > > 3fff7ef95970 nip 3fff7ef95970 lr 3fff7ef94f90 code 1 in > > libffi.so.8.1.0[3fff7ef8d000+c000] > > [ 16.874154] fail2ban-server[384]: code: b1090008 f949 4e800020 > > 6000 6042 > > [ 16.874176] fail2ban-server[384]: code: 8123 712a0008 41820018 > > 39230004 <7c004eee> 39230020 7c004fae 4bfffaf4 > > > > after rm -rf ~/libffi, git clone, autogen, this time i ran ./configure > with > > --disable-exec-static-tramp and then copied the new libffi.so.8 to > > /usr/lib/powerpc64-linux-gnu/ once again restarted the system and no more > > messages on the console or in the logs about libfffi > > OK, this sounds like a good verification. Thanks for testing this for me. > > Can you make another check and try the v3.4.2 upstream tag? > > $ make clean > $ git clean -df > $ git checkout v3.4.2 > $ ./autogen.sh && ./configure && make > > and try again? Maybe the issue was fixed between v3.4.2 and HEAD. > > > september 28th is the one i just compiled replacing the one contained in > > the libff8 package. i dont know the standard way of verifying which > > library is being used. > > You can verify the library being using with the `ldd` command. > > For example: > > $ ldd `which python2.7` > > So, my next guess is that there is something wrong with the Debian source > package. Maybe it's actually not version 3.4.2 that is being used. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: after Debian update most apps crash - libffi issue?
i recompiled everything with gcc-10 and there is no change vs gcc version 11 On Tue, Sep 28, 2021 at 2:24 AM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > On 9/28/21 11:22, Cameron MacPherson wrote: > > after running the commands you listed i repeated my process with the new > > libffi.so.8 from v3.4.2 vs HEAD and there is no change. both of them > work. > > i am using gcc 11.2.0-7 > > Ah, the compiler is a good point. > > Try building with gcc-10 instead by setting CC=gcc-10 after installing > the gcc-10 package. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: after Debian update most apps crash - libffi issue?
after building and installing it locally using your commands (i had to add --no-sign to dpkg-buildpackage) it works. no illegal instructions On Tue, Sep 28, 2021 at 3:08 AM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hi Cameron! > > On 9/28/21 11:38, Cameron MacPherson wrote: > > i recompiled everything with gcc-10 and there is no change vs gcc > version 11 > > As a last test, can you try rebuilding the Debian package locally and test > that? > > $ apt-get install devscripts > $ dget -u > https://deb.debian.org/debian/pool/main/libf/libffi/libffi_3.4.2-2.dsc > $ apt-get build-dep libffi > $ cd libffi-3.4.2 > $ dpkg-buildpackage -B > > Then just install the package with "dpkg -i libffi_3.4.2-2_powerpc.deb" > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: after Debian update most apps crash - libffi issue?
i installed the b1 version of libffi8 and the illegal instruction messages are back [ 16.195961] fail2ban-server[384]: illegal instruction (4) at 3fffa5270970 nip 3fffa5270970 lr 3fffa526ff90 code 1 in libffi.so.8.1.0[3fffa5268000+c000] [ 16.196045] fail2ban-server[384]: code: b1090008 f949 4e800020 6000 6042 [ 16.196067] fail2ban-server[384]: code: 8123 712a0008 41820018 39230004 <7c004eee> 39230020 7c004fae 4bfffaf4 On Tue, Sep 28, 2021, 4:50 AM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > On 9/28/21 12:58, John Paul Adrian Glaubitz wrote:> On 9/28/21 12:55, > Cameron MacPherson wrote: > >> after building and installing it locally using your commands (i had to > add > >> --no-sign to dpkg-buildpackage) it works. no illegal instructions > > > > Well, that's becoming intesting now. I'm going to have the packages > rebuilt > > on the buildds now. > > Can you try whether this package works? > > $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_powerpc.deb > $ dpkg -i libffi8_3.4.2-2+b1_powerpc.deb > > For ppc64: > > $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_ppc64.deb > $ dpkg -i libffi8_3.4.2-2+b1_ppc64.deb > > Although the ppc64 version was built on the same buildd as the same > problematic > version while the powerpc version was now built on another buildd. > > So, if the problem is fixed on powerpc now, but persists on ppc64, we might > have a culprit. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: after Debian update most apps crash - libffi issue?
i can confirm that the ppc64 snapshot packages work without illegal instructions On Tue, Sep 28, 2021 at 12:54 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hi! > > On 9/28/21 21:34, John Paul Adrian Glaubitz wrote: > > OK. I'm regenerating the chroots on the build servers now and then > > trigger another rebuild of the package. If that still doesn't help, > > we know there is some runtime detection which enables these instructions > > during build and I have to start looking into the source code. > > In the meantime, could you please perform another experiment and check > whether > the libffi_3.4.2-1 package is affected as well? > > You can fetch it from here: > > powerpc: > > > > http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/libf/libffi/libffi8_3.4.2-1_powerpc.deb > > ppc64: > > > > http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/libffi/libffi8_3.4.2-1_ppc64.deb > > The -dev packages can be found here if necessary: > > powerpc: > > > > http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/libf/libffi/libffi-dev_3.4.2-1_powerpc.deb > > ppc64: > > > > http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/libffi/libffi-dev_3.4.2-1_ppc64.deb > > If these package work, we know it's a bug with the build environment > (compiler, binutils etc). > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
Re: libffi illegal instruction - again
would it be helpful if all of us affected contributed to the bug report? the squeaky wheel gets the grease method sometimes works On Mon, Oct 25, 2021, 11:10 AM Riccardo Mottola wrote: > Hi Adrian > , > > John Paul Adrian Glaubitz wrote: > > > > a) Upstream doesn't care and has not even looked at the issue yet: > > That's worrying. > > > > > >> https://github.com/libffi/libffi/issues/662 > > b) Debian's libffi maintainer hasn't understood the problem and assume > it's > >just a matter of passing the right configure option. It isn't so I > reopened > >the bug reportÖ > > I didn't notice it was reopened, but indeed, he writes "believes" issue > is closed, but facts are different :) > > > > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995223 > > I don't know what else to do and honestly, I can't fix all these bugs > myself, I'm > > not even paid for doing that. > > Adrian, I wasn't implying you should do it and I thanks for your work, I > just noted that things broke again. First part is diagnosing the issue > and hoping that maintainers and/or upstream work on it, which was not > the case. > > What could be of use? forking libffi and attempting to patch all > configure warnings and generate a big patch and a pull-request? > > > Riccardo > >
Re: libffi illegal instruction - again
i got the 3.4.2-3+ports package after apt upgrade -t experimental and there are no illegal instructions On Fri, Oct 29, 2021 at 5:43 AM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > On 10/25/21 12:11, John Paul Adrian Glaubitz wrote: > > b) Debian's libffi maintainer hasn't understood the problem and assume > it's > >just a matter of passing the right configure option. It isn't so I > reopened > >the bug reportÖ > > > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995223 > > So, there is an update. A fellow Debian Developer suggested on > #debian-devel that > the configure option "--without-gcc-arch" will actually fix the problem > and it > did. > > I will build the package manually with that option and upload it, the > Debian's > libffi maintainer will hopefully shortly follow up with an updated package. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: libffi illegal instruction - again
you have to add the following to your /etc/apt/sources.list to get the experimental packages deb http://ftp.ports.debian.org/debian-ports/ experimental main see here https://wiki.debian.org/DebianExperimental On Wed, Nov 3, 2021, 10:42 AM Ken Cunningham < ken.cunningham.web...@gmail.com> wrote: > It appears that when building portable code, the ax_gcc_archflag.m4 macro > clears -mcpu for almost every arch except powerpc: > > https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L241 > > case $host_cpu in i*86|x86_64*|amd64*) flag_prefixes="$flag_prefixes > -mcpu= -m";; esac > > > > The fact that PowerPC is excluded must result in m4 passing the “-mcpu=“ > flag matching the buildbot’s CPU, and breaks everything older than the > buildbot. > > This must happen with any build that uses this ax_gcc_archflag.m4 macro. > > I wonder why powerpc* is excluded? Seems like this line should rather be: > > case $host_cpu in i*86|x86_64*|powerpc*|amd64*) > flag_prefixes="$flag_prefixes -mcpu= -m";; esac > > > Ken > > PS. Although I did not as yet sort out getting the “experimental” packages > (I keep getting an error when I try to use that option), building libffi in > a couple of minutes on the local machine and installing that of course > works easily. — K > > > > On Nov 2, 2021, at 2:01 PM, John Paul Adrian Glaubitz < > glaub...@physik.fu-berlin.de> wrote: > > > > On 11/2/21 21:59, Cameron MacPherson wrote: > >> i got the 3.4.2-3+ports package after apt upgrade -t experimental and > there > >> are no illegal instructions > > > > As I expected. The build log didn't have any traces of "-mcpu=power8". > > > > Adrian > > > > -- > > .''`. John Paul Adrian Glaubitz > > : :' : Debian Developer - glaub...@debian.org > > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > >
Re: Bug#885245: linux: FTBFS on powerpcspe: sstep.c: ptesync unrecognized
to get the latest kernel to compile on a powermac g5 takes removing the
power8 instructions from sstep.c it will compile with -mpower8 but then
wont boot if you dont get rid of the instructions
On Thu, Jan 20, 2022, 1:11 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> Hi!
>
> On 12/26/17 04:32, Aaron M. Ucko wrote:
> > Builds of linux for powerpcspe (admittedly not a release architecture)
> > have been failing lately:
> >
> > {standard input}: Assembler messages:
> > {standard input}:5854: Error: unrecognized opcode: `ptesync'
> > /<>/scripts/Makefile.build:319: recipe for target
> 'arch/powerpc/lib/sstep.o' failed
> > make[6]: *** [arch/powerpc/lib/sstep.o] Error 1
>
> Funny, it seems that this particular issue is now uncovering on powerpc
> [1] and
> ppc64 [2] as well after this change [3] in the GNU Assembler.
>
> Adrian
>
> > [1]
> https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=5.15.15-1&stamp=1642579068&raw=0
> > [2]
> https://buildd.debian.org/status/fetch.php?pkg=linux&arch=ppc64&ver=5.15.15-1&stamp=1642578946&raw=0
> > [3]
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaub...@debian.org
> `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>
>
Re: sid ppc64 port systemd is broken on PowerMac G5 right now
hi, on my system i get systemd[1]: Caught , core dump failed (child 210, code=killed, status=6/ABRT) prior to rebooting there were messages about journald not starting. i will see if i can go back to an older version of systemd. On Tue, Feb 1, 2022 at 2:33 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > On 2/1/22 23:11, H wrote: > > Namely, systemd-journald and systemd-logind and some other less important > > stuff. And, due to the fact that systemd-journald is unable to start, > > journalctl -xn $service is empty for any services. > > It's a bit difficult to say what's wrong without any error messages. The > cause > might be unrelated to systemd and it's just the part of the system where > the > problem shows. > > Maybe problems with the filesystem or hardware? > > I have not observed any systemd issues on my PowerPC machines yet, but I > will > run a test installation tomorrow. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: sid ppc64 port systemd is broken on PowerMac G5 right now
i got the ppc64 version 250.3-1 of libnss-systemd libpam-systemd libsystemd0 systemd-timesync and systemd from snapshot.debian.org and installed them with dpkg -i and the system boots again after apt upgrade to 250.3-2 on reboot the machine halts before it restarts systemd[1]: Caught , dumped core as pid 1293. systemd [1]: Freezing execution. after reboot same failure except with core dump failed On Tue, Feb 1, 2022, 3:27 PM H wrote: > Hi John, > > FWIW, A little bit information that might be helpful: > > I started journald manually via /lib/systemd/systemd-journald, no error > message to stdout and stderr, nor journalctl output. Actually journalctl > still does not work (empty for all services). > But the journald seemed started logging to /var/log/syslog. > When I try to start logind, /var/log/syslog captures the following error > message: > /lib/systemd/systemd-logind: error while loading shared libraries: > libsystemd-shared-250.so: failed to map segment from shared object. > > The file exists, clearly this is a broken binary from the port. > The filesystem is ext4. > > Thanks, > Hao > > On Tue, Feb 1, 2022 at 2:17 PM John Paul Adrian Glaubitz < > glaub...@physik.fu-berlin.de> wrote: > >> On 2/1/22 23:11, H wrote: >> > Namely, systemd-journald and systemd-logind and some other less >> important >> > stuff. And, due to the fact that systemd-journald is unable to start, >> > journalctl -xn $service is empty for any services. >> >> It's a bit difficult to say what's wrong without any error messages. The >> cause >> might be unrelated to systemd and it's just the part of the system where >> the >> problem shows. >> >> Maybe problems with the filesystem or hardware? >> >> I have not observed any systemd issues on my PowerPC machines yet, but I >> will >> run a test installation tomorrow. >> >> Adrian >> >> -- >> .''`. John Paul Adrian Glaubitz >> : :' : Debian Developer - glaub...@debian.org >> `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de >> `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >> >>
Re: sid ppc64 port systemd is broken on PowerMac G5 right now
i got the +b1 version of systemd this afternoon and its fixed On Wed, Feb 2, 2022 at 10:15 AM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello! > > On 2/2/22 18:55, H wrote: > > Thank you Adrian! > > Try upgrading your machines, it should be fixed now. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: Testers on PowerMac needed - overwriting the boot-device in NVRAM
hi, nvram --print-config='boot-device /pci@f400/ata-6@d/@0:2,\\:txbi' nvram --update-config boot-device="" nvram --print-config=boot-device reboot result is another login prompt On Fri, Mar 25, 2022, 12:44 AM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello! > > I would like to ask users running Debian on a real PowerMac machine (G3, > G4, G5 etc) > to help me verify a theory on the boot mechanism. In particular, the > question is > whether we can skip setting the boot-device in NVRAM in the grub-installer > script > which causes incompatibilities with the PowerMac emulation in QEMU [1]. > > According to Apple's documentation [2], Open Firmware will automatically > search for > available operating systems, so there is no need to explicitly set the > path to > the boot device. > > To verify this, I set the boot device on my iBook G4 to NULL and checked > whether the > machine would still boot which turns out to be true. However, before I > change the > code in grub-installer, I want to make sure it won't break any other > PowerMacs. > > So, if you would like to help, please try the following. > > As root, run: > > root@ibook-g4:~# nvram --print-config=boot-device > /pci@f400/ata-6@d/@0:2,\\:txbi > root@ibook-g4:~# nvram --update-config boot-device="" > root@ibook-g4:~# nvram --print-config=boot-device > root@ibook-g4:~# reboot > > If your machine still comes up after changing "boot-device" to zero, we > know that > it's safe to drop the NVRAM part from the grub-installer script for > PowerMacs. > > This will fix the remaining compatibility with QEMU. > > Thanks, > Adrian > > > [1] https://lists.debian.org/debian-powerpc/2022/03/msg00029.html > > [2] https://opensource.apple.com/source/bless/bless-37/README.BOOTING > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: Testers on PowerMac needed - overwriting the boot-device in NVRAM
cam@propaganda:~$ cat /proc/cpuinfo processor : 0 cpu : PPC970, altivec supported clock : 1600.00MHz revision: 2.2 (pvr 0039 0202) timebase: platform: PowerMac model : PowerMac7,2 machine : PowerMac7,2 motherboard : PowerMac7,2 MacRISC4 Power Macintosh detected as : 336 (PowerMac G5) pmac flags : L2 cache: 512K unified pmac-generation : NewWorld correct it rebooted normally looking at the display i rebooted it remotely its been a long night On Fri, Mar 25, 2022, 1:42 AM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello Cameron! > > On 3/25/22 09:40, Cameron MacPherson wrote: > > nvram --print-config='boot-device /pci@f400/ata-6@d/@0:2,\\:txbi' > > nvram --update-config boot-device="" > > nvram --print-config=boot-device > > reboot > > > > result is another login prompt > > On which machine exactly? > > And by "another login prompt" you mean the machine booted normally? > > Thanks, > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
ppc64 testing binutils
after upgrading to binutils 2.35.50.20201125-1 while attempting to compile kernel 5.10.1 i get this error: $ make V=1 bindeb-pkg CC init/main.o [..]scripts/genksyms/genksyms -R -r /dev/null > init/.tmp_main.ver; ld -EB -m elf64ppc -r -o init/.tmp_main.o init/main.o -T init/.tmp_main.ver; mv -f init/.tmp_main.o init/main.o; rm -f init/.tmp_main.ver; fi ld: final link failed: bad value make[4]: *** [scripts/Makefile.build:279: init/main.o] Error 1 cam
Re: ppc64 testing binutils
after apt update && apt -t experimental upgrade $ ld --version GNU ld (GNU Binutils for Debian) 2.35.50.20201209 thinking it could be something with my .config i tried again using /boot/config-5.10.0-trunk-powerpc64 and got the same result. i haven't yet had time to look into it further or report it elsewhere. make KERNELRELEASE=5.10.1 ARCH=powerpc KBUILD_BUILD_VERSION=1 -f ./Makefile [...] CC init/main.o ld: final link failed: bad value make[4]: *** [scripts/Makefile.build:279: init/main.o] Error 1 cam On Thu, Dec 17, 2020 at 6:05 AM Elimar Riesebieter wrote: > * Cameron MacPherson [2020-12-16 12:10 > -0800]: > > > after upgrading to binutils 2.35.50.20201125-1 while attempting to > compile > > kernel 5.10.1 i get this error: > > > > $ make V=1 bindeb-pkg > > CC init/main.o > > [..]scripts/genksyms/genksyms -R -r /dev/null > init/.tmp_main.ver; ld > > -EB -m elf64ppc -r -o init/.tmp_main.o init/main.o -T init/.tmp_main.ver; > > mv -f init/.tmp_main.o init/main.o; rm -f init/.tmp_main.ver; fi > > ld: final link failed: bad value > > make[4]: *** [scripts/Makefile.build:279: init/main.o] Error 1 > > binutils 2.35.50.20201209-1 should be in experimental. > > Elimar > -- > Numeric stability is probably not all that > important when you're guessing;-) > >
Re: ppc64 testing binutils
i reported the problem via bugzilla and it was fixed on december 25th in the upstream source. i tested the fix and successfully compiled a kernel. hopefully a new experimental package based on the updated code will be released. the bug report (with fix): https://sourceware.org/bugzilla/show_bug.cgi?id=27100 cam On Wed, Dec 16, 2020 at 12:24 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hi Cameron! > > On 12/16/20 9:10 PM, Cameron MacPherson wrote: > > after upgrading to binutils 2.35.50.20201125-1 while attempting to > compile > > kernel 5.10.1 i get this error: > > > > $ make V=1 bindeb-pkg > > CC init/main.o > > [..]scripts/genksyms/genksyms -R -r /dev/null > init/.tmp_main.ver; ld > > -EB -m elf64ppc -r -o init/.tmp_main.o init/main.o -T init/.tmp_main.ver; > > mv -f init/.tmp_main.o init/main.o; rm -f init/.tmp_main.ver; fi > > ld: final link failed: bad value > > make[4]: *** [scripts/Makefile.build:279: init/main.o] Error 1 > > This should be either reported to the binutils Bugzilla [1] or to the > linux-ppc > kernel mailing list [2]. > > Thanks, > Adrian > > > [1] https://sourceware.org/bugzilla/ > > [2] https://lists.ozlabs.org/listinfo/linuxppc-dev > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > >
Re: iMac G5 "windfarm"
On Wed, Dec 30, 2020 at 2:55 PM Riccardo Mottola wrote: > But yaboot doesn't find it, so I have to boot "old". Maybe this is part > of the issue. > make sure you run ybin -v after making changes cam
Re: iMac G5 "windfarm"
On Sun, Jan 3, 2021 at 1:30 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > On 1/3/21 10:25 PM, John Paul Adrian Glaubitz wrote: > > The stuff is open source, if anyone is interested in getting this fixed, > please > > start reading the code and help me. > > FWIW, the source code is here: > > > > https://salsa.debian.org/installer-team/partman-base/-/blob/master/parted_server.c > > If anyone has any clever idea, please let me know. > there are lots of calls to fflush without a following fsync(fileno()) from the fflush() manual page: NOTES Note that fflush() flushes only the user-space buffers provided by the C library. To ensure that the data is physically stored on disk the ker‐ nel buffers must be flushed too, for example, with sync(2) or fsync(2). i imagine this could cause blocking problems with fifos but i am just guessing. cam
