Hi: I read your explaination. The script https://github.com/AlmuHS/gnumach_dev_scripts/blob/main/compile_scratch.sh is mine, and it's designed to compile a gnumach-smp kernel, with APIC and rumpdisk enabled, from Linux. So, if you try to boot the gnumach compiled with this script, you have to be sure that the /etc/fstab name the disk devices like wd0 or similar. If the disk is named like hd0, you have to rename it to wd0. In other case, rumpdisk will not be able to detect the disk.
In the repository there are more scripts to generate the VM and run it in Qemu, and these scripts allows some arguments to customize the process. Now I will have to update the download URL to the latest image. Read the README to know more about these scripts. Thanks El dom, 22 jun 2025 a las 17:55, Milos Nikic (<nikic.mi...@gmail.com>) escribió: > 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 >> >
