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!
