libc6:m68k 2.28-1

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

libc6:m68k 2.28-1

Finn Thain
When I ran 'apt-get dist-upgrade' today, the installation got stuck when
configuring libc6-2.28-1. This package seems to have broken my system --
any process that gets launched never terminates. Anyone else seen this?

--

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

Finn Thain
On Mon, 3 Dec 2018, I wrote:

> When I ran 'apt-get dist-upgrade' today, the installation got stuck when
> configuring libc6-2.28-1. This package seems to have broken my system --
> any process that gets launched never terminates. Anyone else seen this?
>

The problem turns out to be dash. I got things working again by replacing
/bin/sh and /bin/dash with symlinks to bash and then running
'apt --fix-broken install' to finish the upgrade.

--

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

John Paul Adrian Glaubitz
On 12/3/18 8:13 AM, Finn Thain wrote:
> The problem turns out to be dash. I got things working again by replacing
> /bin/sh and /bin/dash with symlinks to bash and then running
> 'apt --fix-broken install' to finish the upgrade.

Thanks for the heads-up! I just ran into this problem with qemu-system but
not with qemu-user. I wonder whether it's related to [1].

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903514

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

Finn Thain
On Tue, 4 Dec 2018, John Paul Adrian Glaubitz wrote:

> On 12/3/18 8:13 AM, Finn Thain wrote:
> > The problem turns out to be dash. I got things working again by replacing
> > /bin/sh and /bin/dash with symlinks to bash and then running
> > 'apt --fix-broken install' to finish the upgrade.
>
> Thanks for the heads-up! I just ran into this problem with qemu-system but
> not with qemu-user. I wonder whether it's related to [1].
>

It happens in aranym too. I tried strace,

execve("/root/dash", ["/root/dash", "-c", "/bin/echo"], ["PWD=/",
"HOME=/", "BOOT_IMAGE=vmlinux", "TERM=linux", "SHLVL=1",
"_=/usr/bin/strace"]) = 0

[...]

get_thread_area()                       = 0xc0022490
get_thread_area()                       = 0xc0022490
get_thread_area()                       = 0xc0022490
get_thread_area()                       = 0xc0022490
get_thread_area()                       = 0xc0022490
get_thread_area()                       = 0xc0022490
get_thread_area()                       = 0xc0022490
clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=NULL) = 415
wait4(-1,
0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=415, si_uid=0,
si_status=0, si_utime=0, si_stime=2} ---
rt_sigreturn({mask=[]})                 = -1 ECHILD (No child processes)
get_thread_area()                       = 0xc0022490
wait4(-1, 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
get_thread_area()                       = 0xc0022490
wait4(-1, 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
get_thread_area()                       = 0xc0022490
wait4(-1, 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
get_thread_area()                       = 0xc0022490
wait4(-1, 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)

The last two lines loop indefinitely, and dash never teminates, even
though the child process has terminated already (SIGCHLD can be seen
above).

--

> Adrian
>
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903514
>
>

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

John Paul Adrian Glaubitz
On 12/6/18 12:10 AM, Finn Thain wrote:
> It happens in aranym too. I tried strace,
>
> execve("/root/dash", ["/root/dash", "-c", "/bin/echo"], ["PWD=/",
> "HOME=/", "BOOT_IMAGE=vmlinux", "TERM=linux", "SHLVL=1",
> "_=/usr/bin/strace"]) = 0
> (...)
> The last two lines loop indefinitely, and dash never teminates, even
> though the child process has terminated already (SIGCHLD can be seen
> above).

Maybe Andreas knows about this issue. I have CC'ed him.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

Eero Tamminen
In reply to this post by Finn Thain
Hi,

On 12/6/18 1:10 AM, Finn Thain wrote:

> On Tue, 4 Dec 2018, John Paul Adrian Glaubitz wrote:
>> On 12/3/18 8:13 AM, Finn Thain wrote:
>>> The problem turns out to be dash. I got things working again by replacing
>>> /bin/sh and /bin/dash with symlinks to bash and then running
>>> 'apt --fix-broken install' to finish the upgrade.
>>
>> Thanks for the heads-up! I just ran into this problem with qemu-system but
>> not with qemu-user. I wonder whether it's related to [1].
>>
>
> It happens in aranym too. I tried strace,
>
> execve("/root/dash", ["/root/dash", "-c", "/bin/echo"], ["PWD=/",
> "HOME=/", "BOOT_IMAGE=vmlinux", "TERM=linux", "SHLVL=1",
> "_=/usr/bin/strace"]) = 0
>
> [...]
>
> get_thread_area()                       = 0xc0022490
> get_thread_area()                       = 0xc0022490
> get_thread_area()                       = 0xc0022490
> get_thread_area()                       = 0xc0022490
> get_thread_area()                       = 0xc0022490
> get_thread_area()                       = 0xc0022490
> get_thread_area()                       = 0xc0022490
> clone(child_stack=NULL,
> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=NULL) = 415
> wait4(-1,
> 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=415, si_uid=0,
> si_status=0, si_utime=0, si_stime=2} ---
> rt_sigreturn({mask=[]})                 = -1 ECHILD (No child processes)
> get_thread_area()                       = 0xc0022490
> wait4(-1, 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
> get_thread_area()                       = 0xc0022490
> wait4(-1, 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
> get_thread_area()                       = 0xc0022490
> wait4(-1, 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
> get_thread_area()                       = 0xc0022490
> wait4(-1, 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
>
> The last two lines loop indefinitely, and dash never teminates, even
> though the child process has terminated already (SIGCHLD can be seen
> above).

With Hatari (68000-68060 Atari) emulator, you should be able profile
what kernel is doing at CPU instruction level:
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-file/tip/doc/manual.html#Profiler

I don't think anybody's tried running full Linux with Hatari yet
(only no-MMU ones), but it shares CPU core with WinUAE, which has
been tested with NetBSD & Linux, so Linux "should" work fine e.g.
with Hatari's Atari TT emulation.

I can help with anything Hatari related (first thing, change crypto
from sha e.g. to md5, otherwise logging in takes ages, even if cycle-
exact emulation is disabled.  Higher emulation accuracy and no JIT,
makes Hatari *much* slower than Aranym).

Note: for 030/040/060 MMU + prefetch + i/d-cache emulation, you should
build Mercurial version of Hatari:
        hg clone http://hg.tuxfamily.org/mercurialroot/hatari/hatari

(Latest 2.1 Hatari release emulates either MMU or cache, not both at
the same time, is quite old and its MMU emulation had several bugs.
Aranym emulates only 040, and AFAIK doesn't have any cache emulation.)


        - Eero

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

Finn Thain
On Thu, 6 Dec 2018, Eero Tamminen wrote:

> On 12/6/18 1:10 AM, Finn Thain wrote:
> > On Tue, 4 Dec 2018, John Paul Adrian Glaubitz wrote:
> > > On 12/3/18 8:13 AM, Finn Thain wrote:
> > > > The problem turns out to be dash. I got things working again by
> > > > replacing /bin/sh and /bin/dash with symlinks to bash and then
> > > > running 'apt --fix-broken install' to finish the upgrade.
> > >
> > > Thanks for the heads-up! I just ran into this problem with
> > > qemu-system but not with qemu-user. I wonder whether it's related to
> > > [1].
> > >
> >
> > It happens in aranym too. I tried strace,
> >
> > execve("/root/dash", ["/root/dash", "-c", "/bin/echo"], ["PWD=/",
> > "HOME=/", "BOOT_IMAGE=vmlinux", "TERM=linux", "SHLVL=1",
> > "_=/usr/bin/strace"]) = 0
> >
> > [...]
> >
> > get_thread_area()                       = 0xc0022490
> > get_thread_area()                       = 0xc0022490
> > get_thread_area()                       = 0xc0022490
> > get_thread_area()                       = 0xc0022490
> > get_thread_area()                       = 0xc0022490
> > get_thread_area()                       = 0xc0022490
> > get_thread_area()                       = 0xc0022490
> > clone(child_stack=NULL,
> > flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=NULL) =
> > 415
> > wait4(-1,
> > 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
> > --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=415, si_uid=0,
> > si_status=0, si_utime=0, si_stime=2} ---
> > rt_sigreturn({mask=[]})                 = -1 ECHILD (No child processes)
> > get_thread_area()                       = 0xc0022490
> > wait4(-1, 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
> > get_thread_area()                       = 0xc0022490
> > wait4(-1, 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
> > get_thread_area()                       = 0xc0022490
> > wait4(-1, 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
> > get_thread_area()                       = 0xc0022490
> > wait4(-1, 0xefdaba3e, 0, NULL)          = -1 ECHILD (No child processes)
> >
> > The last two lines loop indefinitely, and dash never teminates, even
> > though the child process has terminated already (SIGCHLD can be seen
> > above).
>
> With Hatari (68000-68060 Atari) emulator, you should be able profile
> what kernel is doing at CPU instruction level:
> https://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-file/tip/doc/manual.html#Profiler
>

I suspect qemu-user avoids the problem by intercepting syscalls (implying
a 68k kernel bug).

And if a kernel bug was somehow exposed by recent changes to dash, I'd
expect hatari would behave the same as aranym and qemu-system.

> I don't think anybody's tried running full Linux with Hatari yet (only
> no-MMU ones), but it shares CPU core with WinUAE, which has been tested
> with NetBSD & Linux, so Linux "should" work fine e.g. with Hatari's
> Atari TT emulation.
>
> I can help with anything Hatari related (first thing, change crypto from
> sha e.g. to md5, otherwise logging in takes ages, even if cycle- exact
> emulation is disabled.  Higher emulation accuracy and no JIT, makes
> Hatari *much* slower than Aranym).
>
> Note: for 030/040/060 MMU + prefetch + i/d-cache emulation, you should
> build Mercurial version of Hatari:
> hg clone http://hg.tuxfamily.org/mercurialroot/hatari/hatari
>
> (Latest 2.1 Hatari release emulates either MMU or cache, not both at
> the same time, is quite old and its MMU emulation had several bugs.
> Aranym emulates only 040, and AFAIK doesn't have any cache emulation.)
>

Sounds very promising!

--

>
> - Eero
>
>

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

John Paul Adrian Glaubitz
In reply to this post by John Paul Adrian Glaubitz
There is another serious problem with glibc 2.28 on m68k which makes
some packages fail to build [1]:

cp -a doc/changes /<<PKGBUILDDIR>>/debian/hp2xx/usr/share/doc/hp2xx/changelog_old
cp -a hp-tests/* /<<PKGBUILDDIR>>/debian/hp2xx/usr/share/doc/hp2xx/hp-tests/
/bin/cp: cannot stat 'hp-tests/*': No such file or directory
make[1]: *** [debian/rules:15: override_dh_auto_install] Error 1
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:10: binary-arch] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned exit status 2

Downgrading from 2.28 to 2.27 fixes the problem:

(sid-m68k-sbuild)root@epyc:/build/hp2xx-j13jUj/hp2xx-3.4.4# ./debian/rules binary-arch          
dh binary-arch
   dh_testroot -a
   dh_prep -a
        rm -f -- debian/hp2xx.substvars
        rm -fr -- debian/.debhelper/generated/hp2xx/ debian/hp2xx/ debian/tmp/
   dh_installdirs -a
        install -d debian/hp2xx/usr/bin debian/hp2xx/usr/share/doc/hp2xx/hp-tests debian/hp2xx/usr/share/info debian/hp2xx/usr/share/man/man1
        rm -f debian/hp2xx.debhelper.log
   debian/rules override_dh_auto_install
make[1]: Entering directory '/build/hp2xx-j13jUj/hp2xx-3.4.4'
dh_auto_install -- prefix=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr \
        man1dir=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/man/man1 \
        infodir=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/info
        make V=1 -j1 install DESTDIR=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true" prefix=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr man1dir=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/man/man1 infodir=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/info
make[2]: Entering directory '/build/hp2xx-j13jUj/hp2xx-3.4.4'
cd sources; make install
make[3]: Entering directory '/build/hp2xx-j13jUj/hp2xx-3.4.4/sources'
cp hp2xx /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/bin
chmod 755 /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/bin/hp2xx
cp hp2xx.info /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/info
chmod 644 /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/info/hp2xx.info
cp ../doc/hp2xx.1 /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/man/man1
chmod 644 /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/man/man1/hp2xx.1
make[3]: Leaving directory '/build/hp2xx-j13jUj/hp2xx-3.4.4/sources'
make[2]: Leaving directory '/build/hp2xx-j13jUj/hp2xx-3.4.4'
cp -a /build/hp2xx-j13jUj/hp2xx-3.4.4/doc/changes /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/doc/hp2xx/changelog_old
cp -a /build/hp2xx-j13jUj/hp2xx-3.4.4/hp-tests/* /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/doc/hp2xx/hp-tests/
/bin/cp: cannot stat '/build/hp2xx-j13jUj/hp2xx-3.4.4/hp-tests/*': No such file or directory
make[1]: *** [debian/rules:15: override_dh_auto_install] Error 1
make[1]: Leaving directory '/build/hp2xx-j13jUj/hp2xx-3.4.4'
make: *** [debian/rules:10: binary-arch] Error 2
(sid-m68k-sbuild)root@epyc:/build/hp2xx-j13jUj/hp2xx-3.4.4# dpkg -i /tmp/*deb
dpkg: warning: downgrading libc-bin from 2.28-2 to 2.27-8
(Reading database ... 47196 files and directories currently installed.)
Preparing to unpack /tmp/libc-bin_2.27-8_m68k.deb ...
Unpacking libc-bin (2.27-8) over (2.28-2) ...
dpkg: warning: downgrading libc-dev-bin from 2.28-2 to 2.27-8
Preparing to unpack .../libc-dev-bin_2.27-8_m68k.deb ...
Unpacking libc-dev-bin (2.27-8) over (2.28-2) ...
dpkg: warning: downgrading libc6-dev:m68k from 2.28-2 to 2.27-8
Preparing to unpack /tmp/libc6-dev_2.27-8_m68k.deb ...
Unpacking libc6-dev:m68k (2.27-8) over (2.28-2) ...
dpkg: warning: downgrading libc6:m68k from 2.28-2 to 2.27-8
Preparing to unpack /tmp/libc6_2.27-8_m68k.deb ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
debconf: falling back to frontend: Readline
Unpacking libc6:m68k (2.27-8) over (2.28-2) ...
dpkg: warning: downgrading multiarch-support from 2.28-2 to 2.27-8
Preparing to unpack .../multiarch-support_2.27-8_m68k.deb ...
Unpacking multiarch-support (2.27-8) over (2.28-2) ...
Setting up libc6:m68k (2.27-8) ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
debconf: falling back to frontend: Readline
Setting up multiarch-support (2.27-8) ...
Setting up libc-bin (2.27-8) ...
Setting up libc-dev-bin (2.27-8) ...
Setting up libc6-dev:m68k (2.27-8) ...
Processing triggers for man-db (2.8.4-3) ...
Not building database; man-db/auto-update is not 'true'.
(sid-m68k-sbuild)root@epyc:/build/hp2xx-j13jUj/hp2xx-3.4.4# ./debian/rules binary-arch          
dh binary-arch
   dh_testroot -a
   dh_prep -a
        rm -f -- debian/hp2xx.substvars
        rm -fr -- debian/.debhelper/generated/hp2xx/ debian/hp2xx/ debian/tmp/
   dh_installdirs -a
        install -d debian/hp2xx/usr/bin debian/hp2xx/usr/share/doc/hp2xx/hp-tests debian/hp2xx/usr/share/info debian/hp2xx/usr/share/man/man1
        rm -f debian/hp2xx.debhelper.log
   debian/rules override_dh_auto_install
make[1]: Entering directory '/build/hp2xx-j13jUj/hp2xx-3.4.4'
dh_auto_install -- prefix=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr \
        man1dir=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/man/man1 \
        infodir=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/info
        make V=1 -j1 install DESTDIR=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true" prefix=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr man1dir=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/man/man1 infodir=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/info
make[2]: Entering directory '/build/hp2xx-j13jUj/hp2xx-3.4.4'
cd sources; make install
make[3]: Entering directory '/build/hp2xx-j13jUj/hp2xx-3.4.4/sources'
cp hp2xx /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/bin
chmod 755 /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/bin/hp2xx
cp hp2xx.info /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/info
chmod 644 /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/info/hp2xx.info
cp ../doc/hp2xx.1 /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/man/man1
chmod 644 /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/man/man1/hp2xx.1
make[3]: Leaving directory '/build/hp2xx-j13jUj/hp2xx-3.4.4/sources'
make[2]: Leaving directory '/build/hp2xx-j13jUj/hp2xx-3.4.4'
cp -a /build/hp2xx-j13jUj/hp2xx-3.4.4/doc/changes /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/doc/hp2xx/changelog_old
cp -a /build/hp2xx-j13jUj/hp2xx-3.4.4/hp-tests/* /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/doc/hp2xx/hp-tests/
make[1]: Leaving directory '/build/hp2xx-j13jUj/hp2xx-3.4.4'
   dh_installdocs -a
        install -d debian/.debhelper/generated/hp2xx
        cp --reflink=auto -a ./README debian/hp2xx/usr/share/doc/hp2xx
        cp --reflink=auto -a ./TODO debian/hp2xx/usr/share/doc/hp2xx
        cp --reflink=auto -a ./doc/hp_cmds.lst debian/hp2xx/usr/share/doc/hp2xx
        chown -R 0:0 debian/hp2xx/usr/share/doc
        chmod -R u\+rw,go=rX debian/hp2xx/usr/share/doc
        install -p -m0644 debian/copyright debian/hp2xx/usr/share/doc/hp2xx/copyright
   dh_installchangelogs -a
        install -p -m0644 debian/changelog debian/hp2xx/usr/share/doc/hp2xx/changelog.Debian
        install -p -m0644 ./CHANGES debian/hp2xx/usr/share/doc/hp2xx/changelog
   dh_installman -a
        man -l --recode UTF-8 ./debian/hp2xx/usr/share/man/man1/hp2xx.1 > debian/hp2xx/usr/share/man/man1/hp2xx.1.dh-new
        mv debian/hp2xx/usr/share/man/man1/hp2xx.1.dh-new debian/hp2xx/usr/share/man/man1/hp2xx.1
        chmod 0644 -- debian/hp2xx/usr/share/man/man1/hp2xx.1
   dh_perl -a
   dh_link -a
   dh_strip_nondeterminism -a
   dh_compress -a
        cd debian/hp2xx
        chmod a-x usr/share/doc/hp2xx/changelog usr/share/doc/hp2xx/changelog.Debian usr/share/doc/hp2xx/changelog_old usr/share/doc/hp2xx/hp-tests/286x192.5_lh.hpg usr/share/doc/hp2xx/hp-tests/286x192.5_lq.hpg usr/share/doc/hp2xx/hp-tests/286x192.5_qh.hpg usr/share/doc/hp2xx/hp-tests/286x192.5_qh2.hpg usr/share/doc/hp2xx/hp-tests/286x192.5_qq.hpg usr/share/doc/hp2xx/hp-tests/acad.hp usr/share/doc/hp2xx/hp-tests/inter.hp usr/share/doc/hp2xx/hp-tests/pages.1.eps usr/share/doc/hp2xx/hp-tests/pages.eps usr/share/doc/hp2xx/hp-tests/spectrum.plt usr/share/doc/hp2xx/hp-tests/win_1.hp usr/share/doc/hp2xx/hp_cmds.lst usr/share/info/hp2xx.info usr/share/man/man1/hp2xx.1
        gzip -9nf usr/share/doc/hp2xx/changelog usr/share/doc/hp2xx/changelog.Debian usr/share/doc/hp2xx/changelog_old usr/share/doc/hp2xx/hp-tests/286x192.5_lh.hpg usr/share/doc/hp2xx/hp-tests/286x192.5_lq.hpg usr/share/doc/hp2xx/hp-tests/286x192.5_qh.hpg usr/share/doc/hp2xx/hp-tests/286x192.5_qh2.hpg usr/share/doc/hp2xx/hp-tests/286x192.5_qq.hpg usr/share/doc/hp2xx/hp-tests/acad.hp usr/share/doc/hp2xx/hp-tests/inter.hp usr/share/doc/hp2xx/hp-tests/pages.1.eps usr/share/doc/hp2xx/hp-tests/pages.eps usr/share/doc/hp2xx/hp-tests/spectrum.plt usr/share/doc/hp2xx/hp-tests/win_1.hp usr/share/doc/hp2xx/hp_cmds.lst usr/share/info/hp2xx.info usr/share/man/man1/hp2xx.1
        cd '/build/hp2xx-j13jUj/hp2xx-3.4.4'
   dh_fixperms -a
        find debian/hp2xx -true -print0 2>/dev/null | xargs -0r chown --no-dereference 0:0
        find debian/hp2xx ! -type l -a -true -a -true -print0 2>/dev/null | xargs -0r chmod go=rX,u+rw,a-s
        find debian/hp2xx/usr/share/doc -type f -a -true -a ! -regex 'debian/hp2xx/usr/share/doc/[^/]*/examples/.*' -print0 2>/dev/null | xargs -0r chmod 0644
        find debian/hp2xx/usr/share/doc -type d -a -true -a -true -print0 2>/dev/null | xargs -0r chmod 0755
        find debian/hp2xx/usr/share/man -type f -a -true -a -true -print0 2>/dev/null | xargs -0r chmod 0644
        find debian/hp2xx -type f \( -name '*.so.*' -o -name '*.so' -o -name '*.la' -o -name '*.a' -o -name '*.js' -o -name '*.css' -o -name '*.scss' -o -name '*.sass' -o -name '*.jpeg' -o -name '*.jpg' -o -name '*.png' -o -name '*.gif' -o -name '*.cmxs' \) -a -true -a -true -print0 2>/dev/null | xargs -0r chmod 0644
        find debian/hp2xx/usr/bin -type f -a -true -a -true -print0 2>/dev/null | xargs -0r chmod a+x
   dh_missing -a
   dh_strip -a
        chmod 0644 -- debian/.debhelper/hp2xx/dbgsym-root/usr/lib/debug/.build-id/ab/3f4e1c882aa054cb852c38736c68a45de18d0f.debug
        chown 0:0 -- debian/.debhelper/hp2xx/dbgsym-root/usr/lib/debug/.build-id/ab/3f4e1c882aa054cb852c38736c68a45de18d0f.debug
        strip --remove-section=.comment --remove-section=.note debian/hp2xx/usr/bin/hp2xx
        objcopy --add-gnu-debuglink debian/.debhelper/hp2xx/dbgsym-root/usr/lib/debug/.build-id/ab/3f4e1c882aa054cb852c38736c68a45de18d0f.debug debian/hp2xx/usr/bin/hp2xx
   dh_makeshlibs -a
        rm -f debian/hp2xx/DEBIAN/shlibs
   dh_shlibdeps -a
        install -d debian/hp2xx/DEBIAN
        dpkg-shlibdeps -Tdebian/hp2xx.substvars debian/hp2xx/usr/bin/hp2xx
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/hp2xx/usr/bin/hp2xx was not linked against libz.so.1 (it uses none of the library's symbols)
   dh_installdeb -a
   dh_gencontrol -a
        echo misc:Depends= >> debian/hp2xx.substvars
        echo misc:Pre-Depends= >> debian/hp2xx.substvars
        dpkg-gencontrol -php2xx -ldebian/changelog -Tdebian/hp2xx.substvars -Pdebian/.debhelper/hp2xx/dbgsym-root -UPre-Depends -URecommends -USuggests -UEnhances -UProvides -UEssential -UConflicts -DPriority=optional -UHomepage -UImportant -DAuto-Built-Package=debug-symbols -DPackage=hp2xx-dbgsym "-DDepends=hp2xx (= \${binary:Version})" "-DDescription=debug symbols for hp2xx" -DBuild-Ids=ab3f4e1c882aa054cb852c38736c68a45de18d0f -DSection=debug -UMulti-Arch -UReplaces -UBreaks
        chmod 0644 -- debian/.debhelper/hp2xx/dbgsym-root/DEBIAN/control
        chown 0:0 -- debian/.debhelper/hp2xx/dbgsym-root/DEBIAN/control
        dpkg-gencontrol -php2xx -ldebian/changelog -Tdebian/hp2xx.substvars -Pdebian/hp2xx -UMulti-Arch
        chmod 0644 -- debian/hp2xx/DEBIAN/control
        chown 0:0 -- debian/hp2xx/DEBIAN/control
   dh_md5sums -a
        cd debian/hp2xx >/dev/null && xargs -r0 md5sum | perl -pe 'if (s@^\\@@) { s/\\\\/\\/g; }' > DEBIAN/md5sums
        chmod 0644 -- debian/hp2xx/DEBIAN/md5sums
        chown 0:0 -- debian/hp2xx/DEBIAN/md5sums
        cd debian/.debhelper/hp2xx/dbgsym-root >/dev/null && xargs -r0 md5sum | perl -pe 'if (s@^\\@@) { s/\\\\/\\/g; }' > DEBIAN/md5sums
        chmod 0644 -- debian/.debhelper/hp2xx/dbgsym-root/DEBIAN/md5sums
        chown 0:0 -- debian/.debhelper/hp2xx/dbgsym-root/DEBIAN/md5sums
   dh_builddeb -a
        dpkg-deb --build debian/hp2xx ..
dpkg-deb: building package 'hp2xx' in '../hp2xx_3.4.4-11_m68k.deb'.
        dpkg-deb --build debian/.debhelper/hp2xx/dbgsym-root ..
dpkg-deb: building package 'hp2xx-dbgsym' in '../hp2xx-dbgsym_3.4.4-11_m68k.deb'.
(sid-m68k-sbuild)root@epyc:/build/hp2xx-j13jUj/hp2xx-3.4.4#

> [1] https://buildd.debian.org/status/fetch.php?pkg=hp2xx&arch=m68k&ver=3.4.4-11&stamp=1544051323&raw=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

Finn Thain

On Thu, 6 Dec 2018, John Paul Adrian Glaubitz wrote:

> There is another serious problem with glibc 2.28 on m68k which makes
> some packages fail to build [1]:
>

Interesting.

> [...]
> Downgrading from 2.28 to 2.27 fixes the problem:
>
> (sid-m68k-sbuild)root@epyc:/build/hp2xx-j13jUj/hp2xx-3.4.4# ./debian/rules binary-arch          
> dh binary-arch
>    dh_testroot -a
>    dh_prep -a
>         rm -f -- debian/hp2xx.substvars
>         rm -fr -- debian/.debhelper/generated/hp2xx/ debian/hp2xx/ debian/tmp/
>    dh_installdirs -a
>         install -d debian/hp2xx/usr/bin debian/hp2xx/usr/share/doc/hp2xx/hp-tests debian/hp2xx/usr/share/info debian/hp2xx/usr/share/man/man1
>         rm -f debian/hp2xx.debhelper.log
>    debian/rules override_dh_auto_install
> make[1]: Entering directory '/build/hp2xx-j13jUj/hp2xx-3.4.4'
> dh_auto_install -- prefix=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr \
>         man1dir=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/man/man1 \
>         infodir=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/info
>         make V=1 -j1 install DESTDIR=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true" prefix=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr man1dir=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/man/man1 infodir=/build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/info
> make[2]: Entering directory '/build/hp2xx-j13jUj/hp2xx-3.4.4'
> cd sources; make install
> make[3]: Entering directory '/build/hp2xx-j13jUj/hp2xx-3.4.4/sources'
> cp hp2xx /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/bin
> chmod 755 /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/bin/hp2xx
> cp hp2xx.info /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/info
> chmod 644 /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/info/hp2xx.info
> cp ../doc/hp2xx.1 /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/man/man1
> chmod 644 /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/man/man1/hp2xx.1
> make[3]: Leaving directory '/build/hp2xx-j13jUj/hp2xx-3.4.4/sources'
> make[2]: Leaving directory '/build/hp2xx-j13jUj/hp2xx-3.4.4'
> cp -a /build/hp2xx-j13jUj/hp2xx-3.4.4/doc/changes /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/doc/hp2xx/changelog_old
> cp -a /build/hp2xx-j13jUj/hp2xx-3.4.4/hp-tests/* /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/doc/hp2xx/hp-tests/
> /bin/cp: cannot stat '/build/hp2xx-j13jUj/hp2xx-3.4.4/hp-tests/*': No such file or directory
> make[1]: *** [debian/rules:15: override_dh_auto_install] Error 1
> make[1]: Leaving directory '/build/hp2xx-j13jUj/hp2xx-3.4.4'
> make: *** [debian/rules:10: binary-arch] Error 2

That's -ENOENT from stat(2) from cp(1) when running under qemu-user,
right?

Can you stat these files using native tools (to bypass qemu-user, m68k
libc, etc) and confirm their presence?

> (sid-m68k-sbuild)root@epyc:/build/hp2xx-j13jUj/hp2xx-3.4.4# dpkg -i /tmp/*deb
> dpkg: warning: downgrading libc-bin from 2.28-2 to 2.27-8
> (Reading database ... 47196 files and directories currently installed.)
> Preparing to unpack /tmp/libc-bin_2.27-8_m68k.deb ...
> Unpacking libc-bin (2.27-8) over (2.28-2) ...
> dpkg: warning: downgrading libc-dev-bin from 2.28-2 to 2.27-8
> Preparing to unpack .../libc-dev-bin_2.27-8_m68k.deb ...
> Unpacking libc-dev-bin (2.27-8) over (2.28-2) ...
> dpkg: warning: downgrading libc6-dev:m68k from 2.28-2 to 2.27-8
> Preparing to unpack /tmp/libc6-dev_2.27-8_m68k.deb ...
> Unpacking libc6-dev:m68k (2.27-8) over (2.28-2) ...
> dpkg: warning: downgrading libc6:m68k from 2.28-2 to 2.27-8
> Preparing to unpack /tmp/libc6_2.27-8_m68k.deb ...
> debconf: unable to initialize frontend: Dialog
> debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
> debconf: falling back to frontend: Readline
> Unpacking libc6:m68k (2.27-8) over (2.28-2) ...
> dpkg: warning: downgrading multiarch-support from 2.28-2 to 2.27-8
> Preparing to unpack .../multiarch-support_2.27-8_m68k.deb ...
> Unpacking multiarch-support (2.27-8) over (2.28-2) ...
> Setting up libc6:m68k (2.27-8) ...
> debconf: unable to initialize frontend: Dialog
> debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
> debconf: falling back to frontend: Readline
> Setting up multiarch-support (2.27-8) ...
> Setting up libc-bin (2.27-8) ...
> Setting up libc-dev-bin (2.27-8) ...
> Setting up libc6-dev:m68k (2.27-8) ...
> Processing triggers for man-db (2.8.4-3) ...
> Not building database; man-db/auto-update is not 'true'.

I'll need to try downgrading the same packages, to see whether that
affects the -ECHILD failure from dash, because it's not clear that libc is
the cause of both errors.

Maybe you already tried that? Regardless, I think I was wrong to blame
dash for this: it seems that man fails in a similar way to dash. That is,
-ECHILD from waitpid...

# man man
man: waitpid failed: No child processes

--

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

John Paul Adrian Glaubitz
On 12/7/18 7:27 AM, Finn Thain wrote:
> That's -ENOENT from stat(2) from cp(1) when running under qemu-user,
> right?
>
> Can you stat these files using native tools (to bypass qemu-user, m68k
> libc, etc) and confirm their presence?

The interesting part is that "cp -a foo/* bar/" of these files works on
the command line. What does not work is when this happens inside
debian/rules.

> I'll need to try downgrading the same packages, to see whether that
> affects the -ECHILD failure from dash, because it's not clear that libc is
> the cause of both errors.

I am currently bisecting glibc. When building glibc from git with 2.28
installed, I am getting similar strange "No such file or directory"
errors.

> Maybe you already tried that? Regardless, I think I was wrong to blame
> dash for this: it seems that man fails in a similar way to dash. That is,
> -ECHILD from waitpid...
>
> # man man
> man: waitpid failed: No child processes

Maybe it's a problem with signal delivery in both cases?

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

Finn Thain
In reply to this post by Finn Thain

> On Thu, 6 Dec 2018, John Paul Adrian Glaubitz wrote:

> > (sid-m68k-sbuild)root@epyc:/build/hp2xx-j13jUj/hp2xx-3.4.4# dpkg -i /tmp/*deb

I installed those 2.27-8 packages and everything works again. Thanks.

root@panmac:/var/cache/apt/archives# dpkg -i *2.27-8*
dpkg: warning: downgrading libc-bin from 2.28-1 to 2.27-8
(Reading database ... 64219 files and directories currently installed.)
Preparing to unpack libc-bin_2.27-8_m68k.deb ...
Unpacking libc-bin (2.27-8) over (2.28-1) ...
dpkg: warning: downgrading libc-dev-bin from 2.28-1 to 2.27-8
Preparing to unpack libc-dev-bin_2.27-8_m68k.deb ...
Unpacking libc-dev-bin (2.27-8) over (2.28-1) ...
dpkg: warning: downgrading libc6-dev:m68k from 2.28-1 to 2.27-8
Preparing to unpack libc6-dev_2.27-8_m68k.deb ...
Unpacking libc6-dev:m68k (2.27-8) over (2.28-1) ...
dpkg: warning: downgrading libc6:m68k from 2.28-1 to 2.27-8
Preparing to unpack libc6_2.27-8_m68k.deb ...
Unpacking libc6:m68k (2.27-8) over (2.28-1) ...
dpkg: warning: downgrading multiarch-support from 2.28-1 to 2.27-8
Preparing to unpack multiarch-support_2.27-8_m68k.deb ...
Unpacking multiarch-support (2.27-8) over (2.28-1) ...
Setting up libc6:m68k (2.27-8) ...
Setting up multiarch-support (2.27-8) ...
Setting up libc-bin (2.27-8) ...
Setting up libc-dev-bin (2.27-8) ...
Setting up libc6-dev:m68k (2.27-8) ...
Processing triggers for man-db (2.8.4-3) ...

--

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

John Paul Adrian Glaubitz
In reply to this post by John Paul Adrian Glaubitz
>> Can you stat these files using native tools (to bypass qemu-user, m68k
>> libc, etc) and confirm their presence?
>
> The interesting part is that "cp -a foo/* bar/" of these files works on
> the command line. What does not work is when this happens inside
> debian/rules.
It's related to dash as well since GNU Make (which is what runs debian/rules)
uses /bin/sh which is pointing to dash:

(sid-m68k-sbuild)root@epyc:/build/hp2xx-j13jUj/hp2xx-3.4.4# dash
\u@\h:\w$ cp -a /build/hp2xx-j13jUj/hp2xx-3.4.4/hp-tests/* /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/doc/hp2xx/hp-tests/
/bin/cp: cannot stat '/build/hp2xx-j13jUj/hp2xx-3.4.4/hp-tests/*': No such file or directory
\u@\h:\w$
(sid-m68k-sbuild)root@epyc:/build/hp2xx-j13jUj/hp2xx-3.4.4# dpkg -i /tmp/libc6_2.27-8_m68k.deb /tmp/libc-bin_2.27-8_m68k.deb /tmp/libc-dev-bin_2.27-8_m68k.deb /tmp/multiarch-support_2.27-8_m68k.deb /tmp/libc6-dev_2.27-8_m68k.deb
dpkg: warning: downgrading libc6:m68k from 2.28-2 to 2.27-8
(Reading database ... 47706 files and directories currently installed.)
Preparing to unpack /tmp/libc6_2.27-8_m68k.deb ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
debconf: falling back to frontend: Readline
Unpacking libc6:m68k (2.27-8) over (2.28-2) ...
dpkg: warning: downgrading libc-bin from 2.28-2 to 2.27-8
Preparing to unpack /tmp/libc-bin_2.27-8_m68k.deb ...
Unpacking libc-bin (2.27-8) over (2.28-2) ...
dpkg: warning: downgrading libc-dev-bin from 2.28-2 to 2.27-8
Preparing to unpack .../libc-dev-bin_2.27-8_m68k.deb ...
Unpacking libc-dev-bin (2.27-8) over (2.28-2) ...
dpkg: warning: downgrading multiarch-support from 2.28-2 to 2.27-8
Preparing to unpack .../multiarch-support_2.27-8_m68k.deb ...
Unpacking multiarch-support (2.27-8) over (2.28-2) ...
dpkg: warning: downgrading libc6-dev:m68k from 2.28-2 to 2.27-8
Preparing to unpack /tmp/libc6-dev_2.27-8_m68k.deb ...
Unpacking libc6-dev:m68k (2.27-8) over (2.28-2) ...
Setting up libc6:m68k (2.27-8) ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
debconf: falling back to frontend: Readline
Setting up libc-bin (2.27-8) ...
Setting up libc-dev-bin (2.27-8) ...
Setting up multiarch-support (2.27-8) ...
Setting up libc6-dev:m68k (2.27-8) ...
Processing triggers for man-db (2.8.4-3) ...
Not building database; man-db/auto-update is not 'true'.
(sid-m68k-sbuild)root@epyc:/build/hp2xx-j13jUj/hp2xx-3.4.4# dash
\u@\h:\w$ cp -a /build/hp2xx-j13jUj/hp2xx-3.4.4/hp-tests/* /build/hp2xx-j13jUj/hp2xx-3.4.4/debian/hp2xx/usr/share/doc/hp2xx/hp-tests/
\u@\h:\w$

Maybe dash needs a rebuild on m68k.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

John Paul Adrian Glaubitz
Hi!

On 12/7/18 2:32 PM, John Paul Adrian Glaubitz wrote:
> It's related to dash as well since GNU Make (which is what runs debian/rules)
> uses /bin/sh which is pointing to dash:

I have opened a bug report against glibc now:

> https://sourceware.org/bugzilla/show_bug.cgi?id=23960

I don't see this problem on x86_64.

> Maybe dash needs a rebuild on m68k.

That didn't help neither did it help to build dash from git.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

John Paul Adrian Glaubitz
In reply to this post by John Paul Adrian Glaubitz
Hi!

On 12/6/18 2:12 PM, John Paul Adrian Glaubitz wrote:

> There is another serious problem with glibc 2.28 on m68k which makes
> some packages fail to build [1]:
>
> cp -a doc/changes /<<PKGBUILDDIR>>/debian/hp2xx/usr/share/doc/hp2xx/changelog_old
> cp -a hp-tests/* /<<PKGBUILDDIR>>/debian/hp2xx/usr/share/doc/hp2xx/hp-tests/
> /bin/cp: cannot stat 'hp-tests/*': No such file or directory
> make[1]: *** [debian/rules:15: override_dh_auto_install] Error 1
> make[1]: Leaving directory '/<<PKGBUILDDIR>>'
> make: *** [debian/rules:10: binary-arch] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned exit status 2

This seems to affect qemu-user only while the lock-up problem with dash
occurs on qemu-system only.

Finn, did you verify the lock-up problem on real hardware by any chance?

Just to make sure the lock-up is not a qemu bug.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

Finn Thain
On Sat, 8 Dec 2018, John Paul Adrian Glaubitz wrote:

>
> This seems to affect qemu-user only while the lock-up problem with dash
> occurs on qemu-system only.
>
> Finn, did you verify the lock-up problem on real hardware by any chance?
>

I don't have my 68k hardware with me at the moment.

> Just to make sure the lock-up is not a qemu bug.
>

Well, if it's a qemu bug then it's also an aranym bug.

If you want to reproduce on elgar, you only need 3 files:

# ls -lR
.:
total 8
drwxr-xr-x 2 root root 4096 Dec  3 07:31 bin
drwxr-xr-x 3 root root 4096 Nov 28 22:42 lib

./bin:
total 112
-rwxr-xr-x 1 root root 108220 Dec  3 07:31 dash
lrwxrwxrwx 1 root root      4 Dec  3 07:31 sh -> dash

./lib:
total 4
lrwxrwxrwx 1 root root   25 Nov 28 22:42 ld.so.1 -> m68k-linux-gnu/ld-2.28.so
drwxr-xr-x 2 root root 4096 Dec  3 07:31 m68k-linux-gnu

./lib/m68k-linux-gnu:
total 1412
-rwxr-xr-x 1 root root  120008 Nov 28 22:42 ld-2.28.so
lrwxrwxrwx 1 root root      10 Nov 28 22:42 ld.so.1 -> ld-2.28.so
-rwxr-xr-x 1 root root 1314040 Nov 28 22:42 libc-2.28.so
lrwxrwxrwx 1 root root      12 Nov 28 22:42 libc.so.6 -> libc-2.28.so
# chroot . /bin/sh
# /bin/sh -c foo
/bin/sh: 1: foo: not found

At this point dash has hung. If you strace that process from outside the
chroot, you can see it looping around wait4() = -1 ECHILD.

--

> Adrian
>
>

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

John Paul Adrian Glaubitz
On 12/8/18 12:37 AM, Finn Thain wrote:
> Well, if it's a qemu bug then it's also an aranym bug.
>
> If you want to reproduce on elgar, you only need 3 files:
> (...)
> At this point dash has hung. If you strace that process from outside the
> chroot, you can see it looping around wait4() = -1 ECHILD.

I can reproduce the issue with "man" on elgar. I don't want to try the test
with dash because that seems to be uninterruptible and I don't want to crash
elgar remotely.

root@elgar:~> LD_PRELOAD=/root/libc-2.28.so ./ld-2.28.so /usr/bin/man man
/usr/bin/man: waitpid failed: No child processes
root@elgar:~> /usr/bin/man
What manual page do you want?
root@elgar:~> /usr/bin/man man
MAN(1)                        Manual pager utils                        MAN(1)

NAME
       man - an interface to the on-line reference manuals

SYNOPSIS
       man  [-C  file]  [-d]  [-D]  [--warnings[=warnings]]  [-R encoding] [-L
       locale] [-m system[,...]] [-M path] [-S list]  [-e  extension]  [-i|-I]
       [--regex|--wildcard]   [--names-only]  [-a]  [-u]  [--no-subpages]  [-P
       pager] [-r prompt] [-7] [-E encoding] [--no-hyphenation] [--no-justifi-
       cation]  [-p  string]  [-t]  [-T[device]]  [-H[browser]] [-X[dpi]] [-Z]
       [[section] page[.section] ...] ...
       man -k [apropos options] regexp ...
       man -K [-w|-W] [-S list] [-i|-I] [--regex] [section] term ...
       man -f [whatis options] page ...
       man -l [-C file] [-d] [-D] [--warnings[=warnings]]  [-R  encoding]  [-L
       locale]  [-P  pager]  [-r  prompt]  [-7] [-E encoding] [-p string] [-t]
       [-T[device]] [-H[browser]] [-X[dpi]] [-Z] file ...
       man -w|-W [-C file] [-d] [-D] page ...
       man -c [-C file] [-d] [-D] page ...
       man [-?V]

DESCRIPTION
root@elgar:~>

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

Michael Schmitz-4
In reply to this post by Finn Thain
Finn,

Am 08.12.2018 um 12:37 schrieb Finn Thain:

> On Sat, 8 Dec 2018, John Paul Adrian Glaubitz wrote:
>
>>
>> This seems to affect qemu-user only while the lock-up problem with dash
>> occurs on qemu-system only.
>>
>> Finn, did you verify the lock-up problem on real hardware by any chance?
>>
>
> I don't have my 68k hardware with me at the moment.
>
>> Just to make sure the lock-up is not a qemu bug.
>>
>
> Well, if it's a qemu bug then it's also an aranym bug.
>
> If you want to reproduce on elgar, you only need 3 files:
>
> # ls -lR
> .:
> total 8
> drwxr-xr-x 2 root root 4096 Dec  3 07:31 bin
> drwxr-xr-x 3 root root 4096 Nov 28 22:42 lib
>
> ./bin:
> total 112
> -rwxr-xr-x 1 root root 108220 Dec  3 07:31 dash
> lrwxrwxrwx 1 root root      4 Dec  3 07:31 sh -> dash
>
> ./lib:
> total 4
> lrwxrwxrwx 1 root root   25 Nov 28 22:42 ld.so.1 -> m68k-linux-gnu/ld-2.28.so
> drwxr-xr-x 2 root root 4096 Dec  3 07:31 m68k-linux-gnu
>
> ./lib/m68k-linux-gnu:
> total 1412
> -rwxr-xr-x 1 root root  120008 Nov 28 22:42 ld-2.28.so
> lrwxrwxrwx 1 root root      10 Nov 28 22:42 ld.so.1 -> ld-2.28.so
> -rwxr-xr-x 1 root root 1314040 Nov 28 22:42 libc-2.28.so
> lrwxrwxrwx 1 root root      12 Nov 28 22:42 libc.so.6 -> libc-2.28.so
> # chroot . /bin/sh
> # /bin/sh -c foo
> /bin/sh: 1: foo: not found
>
> At this point dash has hung. If you strace that process from outside the
> chroot, you can see it looping around wait4() = -1 ECHILD.
>

Can you strace the whole procedure (i.e. starting with the call to
chroot) from the outside? With time stamps, for preference?

The strace you did show with dash does indicate that SIGCHLD was sent by
the child process / thread but even before that, the parent process got
-ECHILD.

To me, this would indicate that wait4 uses the wrong task struct to
search for childs / threads to check.

Might this have something to do with it?

> /*
>  * Why not generic sys_clone, you ask?  m68k passes all arguments on stack.
>  * And we need all registers saved, which means a bunch of stuff pushed
>  * on top of pt_regs, which means that sys_clone() arguments would be
>  * buried.  We could, of course, copy them, but it's too costly for no
>  * good reason - generic clone() would have to copy them *again* for
>  * do_fork() anyway.  So in this case it's actually better to pass pt_regs *
>  * and extract arguments for do_fork() from there.  Eventually we might
>  * go for calling do_fork() directly from the wrapper, but only after we
>  * are finished with do_fork() prototype conversion.
>  */
> asmlinkage int m68k_clone(struct pt_regs *regs)
> {
>         /* regs will be equal to current_pt_regs() */
>         return do_fork(regs->d1, regs->d2, 0,
>                        (int __user *)regs->d3, (int __user *)regs->d4);
> }
>

Other architectures seem to treat clone() different from fork()?

Cheers,

        Michael

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

Finn Thain
On Sat, 8 Dec 2018, Michael Schmitz wrote:

>
> Can you strace the whole procedure (i.e. starting with the call to
> chroot) from the outside? With time stamps, for preference?
>

I'd rather wait for the results of Adrian's git bisection before spending
more time on this bug.

> The strace you did show with dash does indicate that SIGCHLD was sent by
> the child process / thread but even before that, the parent process got
> -ECHILD.
>
> To me, this would indicate that wait4 uses the wrong task struct to
> search for childs / threads to check.
>
> Might this have something to do with it?
>
> > /*
> >  * Why not generic sys_clone, you ask?  m68k passes all arguments on stack.
> >  * And we need all registers saved, which means a bunch of stuff pushed
> >  * on top of pt_regs, which means that sys_clone() arguments would be
> >  * buried.  We could, of course, copy them, but it's too costly for no
> >  * good reason - generic clone() would have to copy them *again* for
> >  * do_fork() anyway.  So in this case it's actually better to pass pt_regs *
> >  * and extract arguments for do_fork() from there.  Eventually we might
> >  * go for calling do_fork() directly from the wrapper, but only after we
> >  * are finished with do_fork() prototype conversion.
> >  */
> > asmlinkage int m68k_clone(struct pt_regs *regs)
> > {
> >         /* regs will be equal to current_pt_regs() */
> >         return do_fork(regs->d1, regs->d2, 0,
> >                        (int __user *)regs->d3, (int __user *)regs->d4);
> > }
> >
>
> Other architectures seem to treat clone() different from fork()?
>

These are probably questions for Andreas. glibc internals are not my
forte.

--

> Cheers,
>
> Michael
>
>

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

John Paul Adrian Glaubitz
On 12/8/18 7:57 AM, Finn Thain wrote:
>> Can you strace the whole procedure (i.e. starting with the call to
>> chroot) from the outside? With time stamps, for preference?
>>
>
> I'd rather wait for the results of Adrian's git bisection before spending
> more time on this bug.

Working on this now. Bisecting between 2.27 and 2.28 and testing on qemu-system
now that I have a usable reproducer.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: libc6:m68k 2.28-1

John Paul Adrian Glaubitz
Hi!

On 12/8/18 9:34 AM, John Paul Adrian Glaubitz wrote:
> Working on this now. Bisecting between 2.27 and 2.28 and testing on qemu-system
> now that I have a usable reproducer.

I found the commit which broke glibc on m68k, it is:

b4a5d26d8835d972995f0a0a2f805a8845bafa0b is the first bad commit
commit b4a5d26d8835d972995f0a0a2f805a8845bafa0b
Author: Adhemerval Zanella <[hidden email]>
Date:   Thu Nov 2 11:04:18 2017 -0200

    linux: Consolidate sigaction implementation
   
    This patch consolidates all Linux sigaction implementations on the default
    sysdeps/unix/sysv/linux/sigaction.c.  The idea is remove redundant code
    and simplify new ports addition by following the current generic
    Linux User API (UAPI).
   
    The UAPI for new ports defines a generic extensible sigaction struct as:
   
      struct sigaction
      {
        __sighandler_t sa_handler;
        unsigned long sa_flags;
      #ifdef SA_RESTORER
        void (*sa_restorer) (void);
      #endif
        sigset_t sa_mask;
      };
   
    Where SA_RESTORER is just placed for compatibility reasons (news ports
    should not add it).  A similar definition is used on generic
    kernel_sigaction.h.
   
    The user exported sigaction definition is not changed, so for most
    architectures it requires an adjustment to kernel expected one for the
    syscall.
   
    The main changes are:
   
      - All architectures now define and use a kernel_sigaction struct meant
        for the syscall, even for the architectures where the user sigaction
        has the same layout of the kernel expected one (s390-64 and ia64).
        Although it requires more work for these architectures, it simplifies
        the generic implementation. Also, sigaction is hardly a hotspot where
        micro optimization would play an important role.
   
      - The generic kernel_sigaction definition is now aligned with expected
        UAPI one for newer ports, where SA_RESTORER and sa_restorer are not
        expected to be defined.  This means adding kernel_sigaction for
        current architectures that does define it (m68k, nios2, powerpc, s390,
        sh, sparc, and tile) and which rely on previous generic definition.
   
      - Remove old MIPS usage of sa_restorer.  This was removed since 2.6.27
        (2957c9e61ee9c - "[MIPS] IRIX: Goodbye and thanks for all the fish").
   
      - The remaining arch-specific sigaction.c are to handle ABI idiosyncrasies
        (like SPARC kernel ABI for rt_sigaction that requires an additional
        stub argument).
   
    So for new ports the generic implementation should work if its uses
    Linux UAPI.  If SA_RESTORER is still required (due some architecture
    limitation), it should define its own kernel_sigaction.h, define it and
    include generic header (assuming it still uses the default generic kernel
    layout).
   
    Checked on x86_64-linux-gnu, i686-linux-gnu, arm-linux-gnueabihf,
    aarch64-linux-gnu, sparc64-linux-gnu, sparcv9-linux-gnu, powerpc-linux-gnu,
    powerpc64-linux-gnu, ia64-linux-gnu and alpha-linux-gnu.  I also checked the
    build on all remaining affected ABIs.
   
            * sysdeps/unix/sysv/linux/aarch64/sigaction.c: Use default Linux version
            as base implementation.
            * sysdeps/unix/sysv/linux/arm/sigaction.c: Likewise.
            * sysdeps/unix/sysv/linux/i386/sigaction.c: Likewise.
            * sysdeps/unix/sysv/linux/sparc/sparc32/sigaction.c: Likewise.
            * sysdeps/unix/sysv/linux/sparc/sparc64/sigaction.c: Likewise.
            * sysdeps/unix/sysv/linux/x86_64/sigaction.c: Likewise.
            * sysdeps/unix/sysv/linux/alpha/kernel_sigaction.h: Add include guards,
            remove unrequired definitions and update comments.
            * sysdeps/unix/sysv/linux/kernel_sigaction.h: Likewise.
            * sysdeps/unix/sysv/linux/mips/kernel_sigaction.h: Likewise.
            * sysdeps/unix/sysv/linux/ia64/kernel_sigaction.h: New file.
            * sysdeps/unix/sysv/linux/m68k/kernel_sigaction.h: Likewise.
            * sysdeps/unix/sysv/linux/nios2/kernel_sigaction.h: Likewise.
            * sysdeps/unix/sysv/linux/powerpc/kernel_sigaction: Likewise.
            * sysdeps/unix/sysv/linux/s390/kernel_sigaction.h: Likewise.
            * sysdeps/unix/sysv/linux/sh/kernel_sigaction.h: Likewise.
            * sysdeps/unix/sysv/linux/sparc/kernel_sigaction.h: Likewise.
            * sysdeps/unix/sysv/linux/tile/kernel_sigaction.h: Likewise.
            * sysdeps/unix/sysv/linux/ia64/sigaction.c: Remove file.
            * sysdeps/unix/sysv/linux/mips/sigaction.c: Likewise.
            * sysdeps/unix/sysv/linux/s390/s390-64/sigaction.c: Likewise.
            * sysdeps/unix/sysv/linux/sigaction.c: Add STUB, SET_SA_RESTORER,
            and RESET_SA_RESTORER hooks.

:100644 100644 17506be6a9897f7dd3111752a9de0e0b060cec75 e7abee53e98c0b2e1362cb4913e2f4211b3747fa M      ChangeLog
:040000 040000 fa5f55cc57a1b1ec9a9bd3c5dc32986834e0af78 29aefea5f3bf96c2a78552305a9ee8b862619c92 M      sysdeps

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

12