Michael Kelly, le lun. 28 sept. 2026 23:22:13 +0100, a ecrit: > 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
Ah, libdiskfs itself calls _hurd_init to set things up: when we don't have the initial portarray and intarray glibc doesn't call it itself... I would say that you can make getuid() immediately return 0 when _hurd_ports is null, because that can only happen during system bootstrap. Samuel
