March 30, 2022 2:54 AM, "Samuel Thibault" <samuel.thibault@gnu.org> wrote:
jbranso@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!