Hello, [email protected], le lun. 24 nov. 2025 14:08:18 +0000, a ecrit: > November 23, 2025 at 3:47 PM, "Samuel Thibault" <[email protected] > mailto:[email protected]?to=%22Samuel%20Thibault%22%20%3Csamuel.thibault%40gnu.org%3E > > wrote: > > [email protected], mailto:[email protected], le dim. 23 nov. 2025 > > 21:43:38 +0100, a ecrit: > > > Nov 23, 2025, 19:24 by [email protected]: > > > Samuel Thibault, le mer. 19 nov. 2025 16:23:02 +0100, a ecrit: > > > > > > yelninei--- via Bug reports for the GNU Hurd, le mer. 19 nov. 2025 > > > 15:11:28 +0100, a ecrit: > > > > Trying to run a x86_64 hurd image with qemu and it fails to boot when > > > the -m option is too high. Something gets stuck after grub, the last > > > message is > > > > ext2fs: part:1:device:wd0: Input/output error > > > > > > > > After reducing the ram to < 3584 the issue goes away. > > > > > > > > This happens both with images cross compiled with guix and the > > > debian-hurd-amd64-20250807.img. > > > > > > > > Is this limitation currently known? > > > > > > No, we have some buildds with 16GB ram. > > > > > > Perhaps try with -M q35: perhaps there are issues with some virtual > > > devices when using 64b physical addresses. > > > > > > HI Samuel, > > > Thanks a lot, that seems to solve it > > > > > As a reminder, readme files are meant to be read, they notably say to > > use -M q35. > > Should I go ahead and start moving the wiki pages to encourage people to use > the 64 bit hurd by default ?
64b is still for now a bit less stable with rump drivers than 32b (as the very example shown above shows), so if we recommend something that'd rather be 32b. Samuel
