DON'T UPGRADE glibc for now... (Was: glibc transition ongoing)
Samuel Thibault, le mar. 09 août 2022 16:37:24 +0200, a ecrit:
> Samuel Thibault, le mar. 09 août 2022 15:06:03 +0200, a ecrit:
> > Richard Braun, le mar. 09 août 2022 14:18:44 +0200, a ecrit:
> > > On Mon, Aug 08, 2022 at 09:31:31PM +0200, Samuel Thibault wrote:
> > > > There's a glibc transition which is ongoing, whose consequence is
> > > > that upgrading libc0.3-dev to 2.34-3
> > > I've upgraded on darnassus.sceen.net and the system cannot boot properly
> > > any more.
> >
> > Oh? I'm not getting the issue on my box.
>
> But it happens on exodar too indeed. The boot CD there allows to chroot
> into the system. I tried dpkg-reconfigure hurd, that didn't help.
Ok, now I see the issue, it's indeed on basically all boxes except mine
because I tinkered with /dev/random.
There is a funky initialization loop with glibc 2.34:
- glibc initialization calls getrandom()
- getrandom() checks whether the process has a __trivfs_server_name
variable, to check whether it points to "random", in that case it just
returns early
- getrandom() opens /dev/urandom or /dev/random
- the /dev/{u,}random translator auto-starts
I had introduced the second step to avoid that very loop. But currently
the hurd boxes are configured to use a random-hurd.sh shell scripts that
starts the /hurd/random translator with proper parameters. That was
meant to make the hurd translator configurable, but it is here bringing
more harm than good.
Also, glibc tries to open files in /proc, and thus /hurd/random startup
would trigger starting procfs, and its glibc initialization would try to
open /dev/urandom, and we get the loop.
I'm thus having a look at removing that random alternative and the
auto-started /proc, to simplify the system startup.
Samuel
Reply to: