Thank you Samuel, I did post the configs already (but I guess they just got lost in the emails) here they are again:
https://justpaste.it/gg2af is config log from Debian Hurd In the meantime I got development from Qemu working thanks to your guys suggestions. (I already submitted a few small patches). Thanks for that. Cross compiling I haven't tried again. The log from that day is here: https://justpaste.it/fya16 Thanks again for all you do! On Sun, Jun 22, 2025, 7:27 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > Hello, > > Milos Nikic, le dim. 15 juin 2025 17:16:54 -0700, a ecrit: > > I am developing inside qemu (on Arch linux) with debian > > image debian-hurd-20230608.img. > > That image is quite old actually. Perhaps better use a more up-to-date > image, I have now uploaded 20250622. > > > When i ".configure" and then make gnumach it passes. > > However when i copy it to my /boot/ and then point GRUB to it, i get > kernel > > panic on next reboot:. > > > > "Kernel page fault at address 0xc1000000, eip = 0xc10a73f6 > > Kernel Page fault trap, eip 0xc10a73f6 > > kernel trap, type 14, code = 3 > > Dump of i386_saved_state c11dbe98: > > EAX fffffffc EBX c008993c ECX 3fc22677 EDX 00008000 > > ESI c0ff6e28 EDI c0fffffe EBP c07a3010 ESP 00000004 > > CS 0008 SS 0000 DS 0010 ES 0010 FS 0010 GS 0010 > > v86: DS 000c ES 0000 FS c037 GS c037 > > EIP c10a73f6 EFLAGS 00010016 > > trapno 14: Page fault, error 00000003 > > panic i386/i386/trap.c:347: kernel_trap: trap" > > Possibly the newer gnumach code has build troubles with the older > compiler from 2023. > > > Is a cross compiling route recommended instead? > > No, it's more hairy to set up. > > jbra...@dismail.de, le lun. 16 juin 2025 20:36:28 +0000, a ecrit: > > I think that way is fairly easy-ish. And it > > makes it easy to apply the Debian specific patches, which you WILL WANT > to do. > > The gnumach package does not have any important debian-specific patch. > The hurd package does have some, but you don't want to install hurd by > hand anyway. Like glibc and other such thing deeply integrated into the > distribution, it won't easily work except for simple cases such as > the ext2fs translator and such. The rest (configuration files, MAKEDEV > etc.) always remains quite distribution-specific, so for working on them > you'd indeed rather work on the debian package. > > > And apply the Debian specific patches. These are patches that mostly > work, > > but are NOT quite polished enough > > > > via ... I forget the command it's something like > > > > COMMAND_NAME -a > > dh_quilt_patch is simplest. > > > That applies all of the debian specific commands. Make your changes, > then > > just running make will make GNU Mach. I think 'make install' should > > install your changed kernel. > > But also headers and whatnot. Simpler to just copy over the kernel into > /boot/ > > Milos Nikic, le lun. 16 juin 2025 21:25:21 -0700, a ecrit: > > Yes I used the pristine gnumach and mig. Just cloned and pulled again > today. > > > > I compiled gnumach on my Linux Arch (cross compiled?). With a script > from [1] > > compile-scratch.sh > > Then I ran > > $ make tests/test-task.iso (from my build directory). > > The thing didn't even compile correctly: > > > > /usr/bin/ld: /tmp/ccYq0CRM.o: in function `test_task': > > > /home/user/Projects/hurd/gnumach/build/../tests/test-task.c:57:(.text+0x27e): > > undefined reference to `__stack_chk_fail_local' > > As I already mentioned, please post your config.log. Apparently gnumach > doesn't manage to disable the stack protection feature (not supported in > kernel mode), we need to determine why that fails on your host while it > does work on our hosts. > > > Lots of errors, such as: > > ../tests/test-task.c:28:10: fatal error: gnumach.user.h: No such file or > > directory > > 28 | #include <gnumach.user.h> > > > > Diego Nieto Cid, le mar. 17 juin 2025 13:38:53 +0100, a ecrit: > > On Mon, Jun 16, 2025 at 09:25:21PM -0700, Milos Nikic wrote: > > > $ cd gnumach > > > $ git fetch origin > > > $ git reset --hard origin/master > > > $ autoreconf -i > > > $ mkdir build > > > $ cd build > > > $ ../configure --host=i686-gnu CC='gcc -m32' > > > > I usually call configure without parameters and let it > > find the host triplet by itself (which usually is the same > > as the running system). > > If you happen to *need* these options to get things working, that's a > bug and we *need* to fix it rather than work around it. Again, posting > your config.log would allow us to actually understand what is happening > in your case, otherwise we will remain clueless. > > Diego Nieto Cid, le jeu. 19 juin 2025 01:16:20 +0100, a ecrit: > > On Tue, Jun 17, 2025 at 05:18:30PM -0700, Milos Nikic wrote: > > > > > > As far as that "n", I have no idea where that is coming from. It's not > > > happening when I try on the Host, only inside Hurd. > > > I see in the Makefile there is a line such as: > > > MIGCOM = $(MIG) -n -cc cat - /dev/null > > > > > > > It's USER_MIG that is missing. For some reason, on i386, gnumach's > configure > > doesn't set it. > > It does get set here. > > *Again*, posting config.log would allow us to determine why that doesn't > happen on that host. > > Diego Nieto Cid, le jeu. 19 juin 2025 01:42:28 +0100, a ecrit: > > On Thu, Jun 19, 2025 at 01:16:20AM +0100, Diego Nieto Cid wrote: > > > > > > You can also test by installing mig from the Debian repository instead > of > > > building it from source. > > > > > > > If you go that route you would need: > > > > sudo apt install mig-i686-gnu > > > > Or maybe the test makefiles need some fixing, not sure. > > Makefiles should be able to whatever is available on the system, yes. > > But we need config.log to determine how it's going wrong here. > > Samuel >
