IRC channel logs
2026-04-12.log
back to list of logs
<diegonc>I can't find the last rm in the iso rule at user-qemu.mk <diegonc>and I'm not sure why is there, module-% seems important to debug the test booted from the ISO <diegonc>well, yeah, I guess. I'd need qemu in Hurd? <damo22>i submitted the 5 patches based on someone elses attempt <diegonc>hmm that would also remove the need to sync the sources and build tree with the runner <diegonc>qemu-system-data/unstable 1:10.2.2+ds-1 all <diegonc> QEMU full system emulation (data files) <sam_>qemu is in freeze for a release shortly, i suggest pinging them once 11 is out <damo22>bonzini said he was going to merge my series "soon" <damo22>ive pinged them on their channel about it <diegonc>ifconfig (hangs at socket_create) -> pfinet (hangs at device_write, called from ethernet_xmit) -> netdde ( ? seems to be hung at ddekit_sem_down at several threads) <diegonc>this VirtualBox stuff is tricky, and I can't take anything away from the VM as it's the nete failing :) <rrq>do you have an UEFI boot for hurd? <rrq>I made that crosshurd-image package and script to build a hurd setup using crosshurd; it prepares a disk with legacy bios boot for eg qemu <rrq>I didn't manage to make it have UEFI variant though <damo22>i think you just need a grub-efi image <rrq>well, that seemed to mess with the build system; I couldn't make it be confined to the disk image <rrq>seems to be intended to be used only from within a running system <rrq>that doesn't apply to an existing disk image; it creates one <damo22>i think you can create a disk image manually using that <rrq>well it also needs modules and config; since hurd is a multiboot story <damo22>you can bake all the modules into the binary <damo22>then you just need to pass it a config <rrq>is "the binary" = BOOTX64.EFI ? <damo22>it has to be called that filename for EFI to detect it <rrq>yes, and it loads the N hurd boot modules into different memory areas, then returns with telling UEFI which of thoes memory areas to start <damo22>yes, but so long as the .EFI binary is present with the right modules, you get a grub shell <rrq>you think grub-mkstandalone creates me such a BOOTX64.EFI ? <bjc>esp is normally fat32 <damo22>grub-mkstandalone -o BOOTX64.EFI -O x86_64-efi ... <rrq>and grub-mkstandalone does not at all refer to (or mess with) the build system? <damo22>but you need the modules for efi already installed <damo22>even though your build system grub can be different <damo22>so it can grab them to make the binary <rrq>can I get the efi modules on my build system without that installation messing with my build system boot? <damo22>eg on debian, you just install grub-efi-bin i think <damo22>grub-efi-amd64-bin/stable 2.12-9+deb13u1 amd64 <damo22> GRand Unified Bootloader, version 2 (EFI-AMD64 modules) <rrq>thanks seems I have a new avenue to tread :) <damo22>the -bin is important so it only gets the modules does not try to install grub-efi on your host <nexussfan>Looks like the new Trisquel has IceCat packages! <nexussfan>Maybe they can be used as a foundation for icecat on upstream debian and maybe on debian/hurd <jab`>So I should be able to try installing the Hurd on a T430 soon...maybe in a day or two. <jab`>I'll report back here how it goes. <diegonc>rumpnet isn't working in VirtualBox either :( <diegonc>I don't know what takes so long but after 100s it seems the card is detected <etno>The 100s thing reminds me of some ACPI initialization timeout I had on real hardware. <etno>I did not solve it though <jab`>Is virtualbox non-free ? <diegonc>there are community and enterprise versions I think, but not sure about which liscence they have <diegonc>hmm....maybe it's just slow, I'll leave it a few hours :P <diegonc>irqhelp: cannot grab acpi device, continuing <diegonc>I also get that during boot, not sure whether it's serious or not (it comes from irqhelp_init)