IRC channel logs
2026-01-23.log
back to list of logs
<youpi>damo22: for user32 build, I use MIGUSER=x86_64-gnu-mig CCASFLAGS="-fdebug-prefix-map=$PWD=." CFLAGS="-ffile-prefix-map=$PWD=. -Wall -g -pipe -fno-strict-aliasing -no-pie -fno-PIE -fno-pie -Wformat -Werror=format-security -O2" ../configure --host=x86_64-gnu LD=x86_64-linux-gnu-ld CC=x86_64-linux-gnu-gcc MIG=x86_64-gnu-mig --enable-user32 USER_CC=i686-linux-gnu-gcc USER_CPP="i686-linux-gnu-gcc -E" --disable-linux-groups <damo22>are you sure MIGUSER is the correct param? it doesnt exist in the code, but USER_MIG does <damo22>checking for i686-gnu-mig... x86_64-gnu-mig <damo22>checking for x86_64-linux-gnu-gcc... i686-linux-gnu-gcc <damo22>checking for x86_64-linux-gnu-gcc... i686-linux-gnu-gcc -E <damo22>doesnt USER_MIG need to be i686-gnu-mig? <youpi>possibly my line is wrong, yes <damo22>no problem, so do we actually need both versions of mig for user32? <youpi>tests/configfrag.ac:[if test x"$enable_user32" = xyes ; then <youpi>tests/configfrag.ac: ac_miguser=$user32_cpu-gnu-mig <youpi>so it should be the 32b mig for userland at least <youpi>for kenel land, I guess it should be 64b indeed <youpi>since we convert, and after that we call the kernel stub which assumes 64b layout <damo22>ok i got user32 to work, but it has ERROR: 1 on one of the tests only <damo22>youpi: perhaps i should make the ci print the contents of test-suite.log in the log? <damo22>or add an option to make the tests more verbose when they fail <damo22>gnumach-test-failure MIG_TYPE_ERROR (0xfffffed4): host_get_time64 <damo22>ERROR tests/test-mach_host (exit status: 99) <azeem>there seems to be something wrong with w on x86-64, the idle is nonsensical: <azeem>$ LANG=C w 07:53:31 up 1 day, 16:10, 8 users, load average: 1,00, 0,00, 1,03 <azeem>USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT <azeem>login tty3 - Mi15 144days 2:11m ? /bin/bash -noprofile /bin/loginpr <azeem>sorry for the bad linebreak, but the uptime is 1d, 16h <youpi>iirc idle doesn't notice reboots <youpi>it's really just about last login <azeem>yeah sorry, I should've checked on x86-32 first <rrq>how do I chroot from a linux/debian into a hurd filesystem? is that available? or "stupid idea"? <rrq>better question: how do I prime a disk image for running hurd to be bootable? <azeem>I don't think you can do the first, not without qemu or something <azeem>rrq: why is the disk image not bootable in the first place? <rrq>I just made it and populated p1 with crosshurd <azert>rrq: currently the Hurd doesn’t run on the Linux kernel, it requires you to boot the very specific GnuMach kernel in a vm <rrq>yes I did that (mboot) some year or so ago using syslinux, but I suspect there is something better available now <rrq>right; can I run grub on linux to prime that disk image? <rrq>(I've only ever used grub to prime the system it runs within) <azert>Linux Grub and Hurd Grub are the same <azert>You could even dd your Linux grub <azert>on the disk image. It would probably work <rrq>well doesn't hurd need multiboot with the triple of root facilities? <rrq>maybe that's a next layer <azert>Yes but the Linux Grub is capable of that <azert>Grub has all that complexity programmed in, even if very few use it <rrq>ok; let me study the manuals for a bit, and recall the magic :) <damo22>its fairly non-trivial to invent the module loading parameters from nothing, youre better off looking at an existing grub.cfg for a hurd system <rrq>hmm how do I get grub-install to install to my disk image file "base.img" ? <rrq>and I want the VM to boot as legacy bios while my host is uefi ... <rrq>doesn't seem to be a supported use case for grub-install :( <azert>rrq: installing grub on a disk image had been done since forever <azert>grub install have a target option allowing you to chose the kind of bios <rrq>mmm can I install grub-pc on the host without that it changes grub for the host? <rrq>no need something else (/usr/lib/grub/i386-pc/modinfo.sh) <rrq>ok; unpacking usr/lib/grub/i386-pc manually worked to bring me to grub rescue prompt ... but it has captured a uuid of the host <rrq>nope grub-install says "File system `ext2' doesn't support embedding; error: embedding is not possible, but this is required for cross-disk install" .. <youpi>rrq: is your disk partitioned ? <youpi>grub indeed needs room where it can fit, usually it's before the first partition <rrq>yes it's partitioned alike the amd64 snapshot we currently run <rrq>i.e. 1 partition starting at 2048 <youpi>and you provide the disk image to grub, not the partition ? <rrq>yes, loop mounted, and cwd is in the mounted loop0p1 <rrq>a bit worried; I tried once with cwd outside loop0p1 and then it didn't say anything, so I'm afraid it has messed up my host <rrq>since it stamped the uuid of my host / into the boot of the diskimage <gnu_srs>sobkas: That box is not available right now. But, I've now built mesa on hurd-amd64 and it works fine also under X windows. <gnu_srs>For hurd-i386 the error remains, both with my mesa patches and libdrm and with your patches. <gnu_srs>Cannot access memory at address 0xfab2000, etc. See for yourself. <sobkas>I'm unable to make hurd-i386 work with kvm, even with the same vm that works with hurd-amd64 <gnu_srs>qemu-system-x86_64 -enable-kvm -m 3072 -net nic,model=e1000 -net user,hostfwd=tcp::5556-:22 -drive cache=writeback,index=0,media=disk,file=hurd.img <sobkas>I was able to start install by using i440FX <sobkas>Ok have 32bit system, will test opengl as soon as I can <damo22>rrq grub-install does not run on cwd <damo22>i think you have to pass the target as a parameter <rrq>yeah; I want to prepare a VM-bootable disk image file for Hurd/amd64 on a Debian/Linux/amd64, and as far as my attempts say, doing so is *not* a supported use case for grub. <rrq>I'm not sure I want to dive into that code myself, but it seems to be either that, or instead use extlinux for initial boot equipment, plus a first-run-fixup that installs grub <rrq>(and extlinux is a bit iffy on that use case too; with the additional complication of configuring its mboot for Hurd) <rrq>it gets iffy I think because the ext2/Hurd filesystem is different from ext2/Linux