Hi Samuel,
On 28/09/2026 20:52, Samuel Thibault wrote:
Hello,
Michael Kelly, le lun. 28 sept. 2026 20:35:20 +0100, a ecrit:
On 12/09/2026 11:24, Michael Kelly wrote:
On 11/09/2026 21:57, Michael Kelly wrote:
Would you expect rumpkernel and/or Hurd to cope with a gpt
partitioned disk? Perhaps this is the block but I'll look tomorrow.
I found that parted was somehow blocked in a call to uuid_generate. I
haven't delved further yet into this but I suspect maybe a call into
'/dev/random' functionality is involved. For the
The lockup happens after uuid_generate() makes the call to getrandom().
getrandom() does attempt to lookup /dev/urandom but that fails with
EGRATUITOUS. The library code for uuid_generate() goes on to some fallback
code to generate random data involving gettimeofday(), getpid() and
getuid(). It's the call to getuid() that causes the lockup because it is
attempting to spin_lock using the invalid pointer 0x30. The root cause is
that _hurd_ports is NULL because _hurd_init() hasn't been called yet.
How is it that _hurd_init hasn't been called? What is the backtrace?
Isn't parted called from main()?
It's all certainly after main() but I haven't got a stack trace. ext2fs
doesn't even show as a task within the mach debugger at this stage and
exec shows a single thread with no useful information. In this instance,
I found it simpler just to add some printfs to illustrate when a few
functions were actually called. This is with a patch to libuuid.a that
allows boot to succeed.
This is the output from running ext2fs.static:
[ 1.2000050] wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2,
Ultra-DMA mode 5 (Ultra/100) (using DMA), NCQ (31
tags)
MK: ext2fs: pre-diskfs_init_main
MK: ext2fs: post-diskfs_init_main
Hurd server bootstrap: ext2fs[part:4:device:wd0] exec startup/hurd/proc:
Increasing priority failed: (os/kern) no access
proc auth.
MK: diskfs_S_fsys_init: calling _hurd_init
MK: glibc:_hurd_init entered
MK: glibc:_hurd_init exited
MK: diskfs_S_fsys_init: after call to _hurd_init
Starting runsystem
The printfs were wrapped around the call to _hurd_init from
within diskfs_S_fsys_init and also at the start/end of glibc _hurd_init.
I used mach_print for the output to avoid any issues with stderr being
redirected etc. _hurd_init is not called from anywhere else when running
ext2fs.static.
All the gpt parted code is run within diskfs_init_main.
Cheers,
Mike.
