Hello, Sorry in advance for my bad English,
I faced that problem with the latest image. What I did was to resize the image with +5GB see https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/README.txt The issue seems that the latest image missed space for swap out or for another reason. I don't know if diagnosis is correct or I was lucky. Try to increase the image size to see it solves your issue. Le 30 mars 2022 17:29:05 GMT+02:00, jbra...@dismail.de a écrit : >March 30, 2022 2:54 AM, "Samuel Thibault" <samuel.thiba...@gnu.org> wrote: > >> jbra...@dismail.de, le mer. 30 mars 2022 01:51:07 +0000, a ecrit: >> >>> I run into various issues all the time. Networking doesn't work, weird >>> issues that I assume >>> are hardware corruption, etc. >> >> How do you run the Hurd? >> >> I'm not getting issues when running in qemu. >> >>> Maybe I am just not technical enough to help out. >> >> Technicity is something one can *acquire*, it's not a divine gift. >> >> Samuel > >Thanks for reaching out Samuel! I actually just tried the latest qemu image, >and the ext2fs translator died on 1st boot. Then it tries to reboot. The >following is just my long summation of what I did: > >** Trying out the vm image [2022-03-30 Wed] > > >Add yourself to the kvm group. This group lets you start a kernel-ized >virtual machine. >You can check to which groups you belong with: >#+BEGIN_SRC sh :results output :exports both >groups joshua >#+END_SRC > >#+RESULTS: >: http video audio > >#+BEGIN_SRC sh :results output :exports both >$ wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz >$ tar -xz < debian-hurd.img.tar.gz >#+END_SRC > >Then I went to read the readme: >https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/README > >#+BEGIN_EXAMPLE >Make sure that you can access /dev/kvm to get full KVM speed (otherwise KVM >will >be terribly slow). You can easily check with > > $ file -s /dev/kvm > >that you properly get "ERROR: cannot read `/dev/kvm' (Invalid argument)", >which means that "file" was properly able to open kvm, just not smart enough >to use it :) >#+END_EXAMPLE > >That's what happened to me. Let's run this monster! > >#+BEGIN_SRC shell >$ qemu-system-i386 -m 4G -display curses -drive >cache=writeback,file=./debian-hurd-20220226.img >#+END_SRC > >So you're not gonna believe this, but it booted, then immediately rebooted. No >idea why it needed to reboot. But this is the error message that I recieve >after fsck fails: > >#+BEGIN_EXAMPLE >/dev/hd0s2: Entry 'dmesg' in /var/log (8107) has deleted/unused inode 8808. >CLEARED. >/dev/hd0s2: Entry 'dmesg.1.gz' in /var/log (8107) has deleted/unused inode >8807. > CLEARED. >/dev/hd0s2: Entry 'resolv.conf' in /etc (16193) has deleted/unused inode 17182. > CLEARED. >/dev/hd0s2: Entry '.clean' in /tmp (72881) has deleted/unused inode 73676. >CLEA >RED. >/dev/hd0s2: Missing '.' in directory inode 98103. > > >/dev/hd0s2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. > (i.e., without -a or -p options) >fsck exited with status code 4 >failed (code 4). >An automatic file system check (fsck) of the root filesystem failed. A manual >fs >ck must be performed, then the system restarted. The fsck should be performed >in > maintenance mode with the root filesystem mounted in read-only mode. ... > failed >! >The root filesystem is currently mounted in read-only mode. A maintenance shell >will now be started. After performing system maintenance, press CONTROL-D to >ter >minate the maintenance shell and restart the system. ... (warning). >Press Enter for maintenance > >#+END_EXAMPLE > >That's probably my fault! I was using termite, which is an upsupported terminal >(it's developers tell you to use something else) and I was running the fish >shell to start the hurd. Perhaps that just did something funky. And I don't >feel >like re-learn how to run fsck on the root filesystem. Also if I have to run >fsck >on the root filesystem at first boot, then it is probably best just to start >over. This time I as using xfce4-terminal and bash only. > >#+BEGIN_SRC scheme >$ rm debian-hurd-20220226.img >$ tar -xz < debian-hurd.img.tar.gz >$ qemu-system-i386 -m 4G -display curses -drive >cache=writeback,file=./debian-hurd-20220226.img >#+END_SRC > >While it's booting let's go read up on some of the documentation: > >Hey I found the actual hurd wiki that is more up to date! >https://darnassus.sceen.net/~hurd-web/hurd/running/qemu/ > >Ahh! That page has some more tips on how to hurd the Hurd in qemu: >Namely '-no-reboot' > >Also when I started this time, I am pretty sure that it booted twice again. It >did NOT leave me in a "you need to run fsck", but it did have a warning about >the root filesystem not having enough room mounting /tmp. Also It did get to a >login screen after what I think was a reboot. Again not entirely certain >because I was half watching the boot up and looking at documentation. > >BUT when it did get to the login screen > >#+BEGIN_EXAMPLE > Timeout reached while wating for return value > /bin/console: Could not receive return value from daemon process: Connection > tim > ed out > Starting enhanced syslogd: rsyslogdrsyslogd: could not load module 'imklog', > err > ors: trying to load module /usr/lib/i386-gnu/rsyslog/imklog.so: > /usr/lib/i386-gn > u/rsyslog/imklog.so: undefined symbol: klogWillRunPrePrivDrop [v8.39.0 try > http: > //www.rsyslog.com/e/2066 ] > . > Starting periodic command scheduler: cron. > Can't start system message bus - /proc is not mounted ... failed! > Starting OpenBSD Secure Shell server: sshd. > > Debian GNU/Hurd bookworm/sid debian console > > login: >#+END_EXAMPLE > >I cannot login. I am typing root, and RET, but nothing happens. The screen >appears to be froze. Ok. I am going to assume that it rebooted, which I have >heard is a great way for the Hurd to get filesystem corruption. So let's try >again. My host machine is Guix System running sway. > >#+BEGIN_SRC scheme >$ rm debian-hurd-20220226.img >$ tar -xz < debian-hurd.img.tar.gz >$ qemu-system-i386 -m 4G -display curses -drive >cache=writeback,file=./debian-hurd-20220226.img -no-reboot >#+END_SRC > >Ok! This time I watched the boot process and did not look away. 1st I got a >warning that the root filesystem did NOT have enough space and /tmpfs was >going to be mounted. Later I got a warning that the system needed to reboot, >because ext2fs had died. Then it tried to reboot, and qemu would not let it. >So I guess it halted. > >This is what I see after it has halted: > >#+BEGIN_SRC EXAMPLE >joshua@crazyhorse ~/prog/gnu/hurd/vm$ qemu-system-i386 -m 4G -display curses >-drive cache=writeback,file=./debian-hurd-20220226.img -no-reboot >WARNING: Image format was not specified for './debian-hurd-20220226.img' and >probing guessed raw. > Automatically detecting the format is dangerous for raw images, write > operations on block 0 will be restricted. > Specify the 'raw' format explicitly to remove the restrictions. >#+END_SRC > >Well I suppose that there should NOT be any filesystem corruption...since it >did >not reboot. Let's try specifiying format raw. > >#+BEGIN_SRC scheme >$ qemu-system-i386 -m 4G -display curses -drive >format=raw,cache=writeback,file=./debian-hurd-20220226.img -no-reboot >#+END_SRC > >Ok root filesystem seems to have some curruption. Here is what I see: > >#+BEGIN_EXAMPLE >INIT: No inittab.d directory found >Using makefile-style concurrent boot in runlevel S. >mount: /proc already mounted >chmod: changing permissions of '/dev/shm': Read-only file system >Activating swap...done. >Checking root file system.../dev/hd0s2 was not cleanly unmounted, check forced. >/dev/hd0s2: Deleted inode 17353 has zero dtime. FIXED. >/dev/hd0s2: Entry 'xconsole' in /dev (8109) has deleted/unused inode 8809. >CLEA >RED. >/dev/hd0s2: Unattached inode 9422 > > >/dev/hd0s2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. > (i.e., without -a or -p options) >fsck exited with status code 4 >failed (code 4). >An automatic file system check (fsck) of the root filesystem failed. A manual >fs >ck must be performed, then the system restarted. The fsck should be performed >in > maintenance mode with the root filesystem mounted in read-only mode. ... > failed >! >The root filesystem is currently mounted in read-only mode. A maintenance shell >will now be started. After performing system maintenance, press CONTROL-D to >ter >minate the maintenance shell and restart the system. ... (warning). >Press Enter for maintenance >(or press Control-D to continue): >#+END_EXAMPLE > >Again, if I am having to fsck a root filesystem before adding in a regular >user, >then it is probably time to start over again. I am trying to brainstorm what >could be the problem...Is the 5G image too small? Does the Hurd need to start >distribting larger qemu images? Would a debian/linux qemu image of 5G be >enough? > > >This time I will try another terminal emulator: qterminal >#+BEGIN_SRC scheme >$ rm debian-hurd-20220226.img >$ tar -xz < debian-hurd.img.tar.gz >$ qemu-system-i386 -m 4G -display curses -drive >format=raw,cache=writeback,file=./debian-hurd-20220226.img -no-reboot >#+END_SRC > >Ok, I had the same issue. A warning message appeared that said something like >"root filesystem has insufficient free space mounting tmpfs or /tmp". Then >later on it said something about the ext2fs translator had died, so it needed >to >reboot. Then it tried to reboot, and qemu would not let it. The last time I >tried to reboot an image that had to reboot because the ext2fs translator had >died it had / filesystem corrucption and told me to run fsck. Let's just >restart again. > >Is kvm kernel module loaded? > >#+BEGIN_SRC shell >$ modprobe kvm_intel >#+END_SRC > >#+BEGIN_SRC scheme >$ rm debian-hurd-20220226.img >$ tar -xz < debian-hurd.img.tar.gz >$ qemu-system-i386 -m 4G -display curses -drive >format=raw,cache=writeback,file=./debian-hurd-20220226.img -no-reboot >#+END_SRC > >So I have been seening this 800 by 600 graphic mode in blue letters at start >up. >I get the same warning about the root filesystem not having enough space, >ext2fs >crashes, and it tried and fails to reboot. Is -display curses causing stuff to >not work? I suppose that is possible. BUT I do not know how I can use the Hurd >on my laptop, which has a physical dvorak layout... Let's try without curses... > >#+BEGIN_SRC scheme >$ rm debian-hurd-20220226.img >$ tar -xz < debian-hurd.img.tar.gz >$ qemu-system-i386 -m 4G -drive >format=raw,cache=writeback,file=./debian-hurd-20220226.img -no-reboot >#+END_SRC > >Nope. =-display curses= is NOT the problem. I tried booting a freshly created >image again, and I went through the same whoopsie daisy again: root filesystem >does not have enough space, ext2fs crashes, and it tries to reboot. I suppose >since I am on Guix system, I could try using the hurd vm image that Guix >supports. But I know it is a little dated. > >Anyway, I have a little side project that I am currently working on for Guix >System (an opensmtpd configuration). I think I will spend the rest of the day >working on that instead of trying to get a Hurd vm working. I am planning on >setting up an Dell Optiplex 7020 server in a soonish. Maybe that is old-ish >enough >to run the Hurd in real hardware. We'll find out! >
