Samuel Thibault, le sam. 27 mai 2023 12:16:50 +0200, a ecrit: > Sergey Bugaev, le ven. 26 mai 2023 17:31:40 +0300, a ecrit: > > On Fri, May 26, 2023 at 2:15 PM Samuel Thibault <samuel.thiba...@gnu.org> > > wrote: > > > It does load, but stays stuck when starting ext2fs: > > > > > > start ext2fs: > > > > Yes, I can reproduce this with your build of ext2fs.static > > > > Unfortunately there are no symbols (maybe you could teach me how to > > fetch and load separate debuginfo into gdb?), but it's crashing on: > > > > 0x000000000055cd00: push %rbp > > 0x000000000055cd01: mov %esi,%eax > > 0x000000000055cd03: mov %rdx,%rsi > > 0x000000000055cd06: mov %rsp,%rbp > > 0x000000000055cd09: push %r13 > > 0x000000000055cd0b: push %r12 > > 0x000000000055cd0d: push %rbx > > 0x000000000055cd0e: sub $0x1048,%rsp > > => 0x000000000055cd15: mov %fs:0x28,%rdx > > > > (gdb) p $fs_base > > $2 = 0 > > > > %fs:0x28 is tcb->stack_guard. The function is thread_set_state, I > > believe -- it's trying to set this very fs_base to the > > __init1_tcbhead. Clearly it gets built with the stack guard in > > your/Debian build, but not in mine or Flavio's. > > --enable-stack-protector=strong has been a default in debian for a long > time indeed. I guess we just need to add more of > > mach/Makefile:CFLAGS-mach_init.o = $(no-stack-protector) > > for now I'll disable the protector by hand to get something working.
Thanks for having investigated! Disabling the protector indeed helped a lot :) Packages are getting rebuilt (with debugging information, this time...), but I could already build some debian initrd image: https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz (500MB initrd size seems too much for the current kernel virtual memory layout, we should probably try to extend gnumach's kernel pmap size, but at least 300MB seems to be working for now). It booted up fine until: start ext2fs: Hurd server bootstrap: ext2fs[device:rd0] exec startup proc auth. /usr/libexec/console-run: /dev/console: Read-only file system task /bin/bash(1) decreasing a bogus port 82650 by 1, most probably a bug. bash: ../sysdeps/mach/hurd/mig-reply.c:84: __mig_dealloc_reply_port: Unexpected error: (os/kern) invalid name. the console warning is expected, we get the same with hurd-i386. But the bash port deallocation is bogus indeed. Samuel
