March 30, 2022 2:17 PM, "Samuel Thibault" <samuel.thiba...@gnu.org> wrote:
> jbra...@dismail.de, le mer. 30 mars 2022 15:29:05 +0000, a ecrit: > >> So you're not gonna believe this, but it booted, then immediately rebooted. > > Uh. More precisely it seems that ext2fs is crashing right after boot is > finished. No idea about this, never seen that before. I'll try to > rebuild a new image, because such a crash would be difficult to debug. > > Guy-Fleury Iteriteka, le mer. 30 mars 2022 17:47:04 +0200, a ecrit: > >> I faced that problem with the latest image. What I did was to resize the >> image >> with +5GB see >> [1]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. > > It rather looks like luck: swap is at the *beginning* of the disk, and > 5GiB is *amply* enough to run the Hurd. > > jbra...@dismail.de, le mer. 30 mars 2022 15:29:05 +0000, a ecrit: >> #+BEGIN_SRC shell >> $ qemu-system-i386 -m 4G -display curses -drive >> cache=writeback,file=./debian-hurd-20220226.img > > Note: this is missing -enable-kvm, so that'll terribly slow! > > Samuel This is just me thinking out loud...I now have a working hurd vm, but it does not have internet access. I'll play with it some more another day. Thanks for the help people. And thank Guy. Your tip worked. ** Trying out the Hurd part 2 [2022-03-30 Wed] I posted a LONG email to bug-hurd, and I got this email from someone: #+BEGIN_EXAMPLE 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. #+END_EXAMPLE Well let's give that a try! #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm qemu-img resize debian-hurd*.img +50G #+END_SRC #+RESULTS: : Image resized. #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm $ parted debian-hurd*.img (parted) resizepart 2 100% (parted) quit #+END_SRC #+RESULTS: #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm sudo losetup -o $((512*1953792)) /dev/loop0 debian-hurd*.img sudo resize2fs /dev/loop #+END_SRC #+RESULTS: : resize2fs 1.46.4 (18-Aug-2021) : Resizing the filesystem on /dev/loop0 to 14143232 (4k) blocks. : The filesystem on /dev/loop0 is now 14143232 (4k) blocks long. #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm sudo losetup -d /dev/loop0 #+END_SRC Well let's try running it again #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm :results raw ls -lha # the img is now 55G #+END_SRC #+RESULTS: total 1.9G drwxr-xr-x 2 joshua users 4.0K Mar 30 13:33 . drwxr-xr-x 3 joshua users 4.0K Mar 30 09:16 .. -rw-r--r-- 1 joshua users 55G Mar 30 14:15 debian-hurd-20220226.img -rw-r--r-- 1 joshua users 386M Feb 26 05:50 debian-hurd.img.tar.gz #+BEGIN_SRC sh $ qemu-system-i386 -m 4G -display curses -drive format=raw,cache=writeback,file=./debian-hurd-20220226.img -no-reboot #+END_SRC This time boot worked! For a second I was actually able to type too! Then I switch to a different virtual desktop to copy the output of boot. When I switched back to try to press return, the Hurd seemed to freeze. I see =login: root=, but trying to type or press enter does not appear to change anything. #+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. #+END_EXAMPLE It probably NOT a good sign that proc is not mounted. I think I may have actually made a mistake when I was resizing the image. And perhaps since I am running on sway, and the Hurd is running on a terminal that only runs in X is causing some issues. Anyway I'll try again with terminal sakura. #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm rm debian-hurd-20220226.img tar -xz < debian-hurd.img.tar.gz qemu-img resize debian-hurd*.img +50G #+END_SRC #+RESULTS: : Image resized. #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vms parted debian-hurd*.img (parted) resizepart 2 100% (parted) quit #+END_SRC #+RESULTS: #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vms sudo losetup -o $((512*1953792)) /dev/loop1 debian-hurd*.img sudo resize2fs /dev/loop1 #+END_SRC #+RESULTS: : resize2fs 1.46.4 (18-Aug-2021) : Resizing the filesystem on /dev/loop0 to 14143232 (4k) blocks. : The filesystem on /dev/loop0 is now 14143232 (4k) blocks long. #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm sudo losetup -d /dev/loop1 #+END_SRC #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm :results raw ls -lha #+END_SRC #+RESULTS: total 1.9G drwxr-xr-x 2 joshua users 4.0K Mar 30 14:29 . drwxr-xr-x 3 joshua users 4.0K Mar 30 09:16 .. -rw-r--r-- 1 joshua users 55G Mar 30 14:49 debian-hurd-20220226.img -rw-r--r-- 1 joshua users 386M Feb 26 05:50 debian-hurd.img.tar.gz Samuel mentioned that we really should have this =--enable-kvm= option #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm qemu-system-i386 -m 4G -display curses -drive format=raw,cache=writeback,file=./debian-hurd-20220226.img -no-reboot --enable-kvm #+END_SRC Ok that seems to work! Let's change the root password in the vm #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm passwd #+END_SRC That worked. Let's reboot and try to get it so that I can ssh into the vm. #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm halt #+END_SRC Ok =halt= seems to have broken the machine...It is now just sitting there. C-c and C-d is doing nothing. I cannot get back to a prompt. And the hurd does not seem to be shutting down. What is the command to turn poweroff the hurd? =poweroff=? =shutdown=? Ahh the README has this info #+BEGIN_EXAMPLE One can safely shut down the system with $ sudo poweroff #+END_EXAMPLE Ok, the hurd does NOT seem to be halting...So I am going to force close the terminal window and see what happens. I will also try using the same image, but there's a good chance that I am going to get filesystem corruption. And #guix irc mentioned that I should try out =foot= as a minimal wayland only terminal. #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm qemu-system-i386 -m 4G -display curses -drive format=raw,cache=writeback,file=./debian-hurd-20220226.img -no-reboot --enable-kvm #+END_SRC Well apparently =halt= + me force closing the terminal window caused some filesystem corruption. At bootup, the Hurd said that it noticed some issues with the root filesystem that it tried to correct. It was unable to mount it. It tried to do a reboot, which of course failed because qemu won't let it (because rebooting the Hurd causes filesystem corruption). Well let's try this again... :DeletingHurdImageAndReInstalling: #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm rm debian-hurd-20220226.img tar -xz < debian-hurd.img.tar.gz qemu-img resize debian-hurd*.img +50G #+END_SRC #+RESULTS: : Image resized. #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vms parted debian-hurd*.img (parted) resizepart 2 100% (parted) quit #+END_SRC #+RESULTS: #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vms sudo losetup -o $((512*1953792)) /dev/loop0 debian-hurd*.img sudo resize2fs /dev/loop0 #+END_SRC #+RESULTS: : resize2fs 1.46.4 (18-Aug-2021) : Resizing the filesystem on /dev/loop0 to 14143232 (4k) blocks. : The filesystem on /dev/loop0 is now 14143232 (4k) blocks long. #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vms sudo losetup -d /dev/loop0 #+END_SRC #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm :results raw ls -lha #+END_SRC #+RESULTS: total 1.9G drwxr-xr-x 2 joshua users 4.0K Mar 30 15:10 . drwxr-xr-x 3 joshua users 4.0K Mar 30 09:16 .. -rw-r--r-- 1 joshua users 55G Mar 30 15:11 debian-hurd-20220226.img -rw-r--r-- 1 joshua users 386M Feb 26 05:50 debian-hurd.img.tar.gz :END: maybe this time I will try to use the correct options for networking. #+BEGIN_SRC sh :dir ~/prog/gnu/hurd/vm qemu-system-i386 -m 4G -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000 -display curses -drive format=raw,cache=writeback,file=./debian-hurd-20220226.img -no-reboot --enable-kvm #+END_SRC Login worked. Changing the root password worked. =ping -c 3 gnu.org= failed. 100% packets lost. I did run ping as root, which should work right? =adduser joshua= -> -bash: adduser: command not found As the demo user =sudo poweroff= works. Let's power it back on and see if I can ssh into the box. Am I doing it wrong? #+BEGIN_EXAMPLE joshua@crazyhorse ~ (master)> ssh localhost:2222 ssh: Could not resolve hostname localhost:2222: Name or service not known joshua@crazyhorse ~ (master) [255]> ssh 127.0.0.1:2222 ssh: Could not resolve hostname 127.0.0.1:2222: Name or service not known joshua@crazyhorse ~ (master) [255]> ssh 127.0.0.1 ssh: connect to host 127.0.0.1 port 22: Connection refused joshua@crazyhorse ~ (master) [255]> ssh 127.0.0.1 ssh: connect to host 127.0.0.1 port 22: Connection refused #+END_EXAMPLE =ping -c 3 gnu.org= still is not working. There is some tips about how to get networking to work here: https://www.debian.org/ports/hurd/hurd-install, https://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#index7h1, and https://darnassus.sceen.net/~hurd-web/hurd/running/qemu/networking/ Where should I start? It looks like dhcp should work? Is that running? It looks like pfinet does the TCP stuff. Is that running? =/servers/socket/2= does exist... The guides online suggest to make sure =/etc/resolv.conf= is correct. #+BEGIN_SRC shell cat /etc/resolv.conf #+END_src #+Results: nameserver 10.0.2.3 Looks good! [[https://www.debian.org/ports/hurd/hurd-install][this guide says that eth0 is in /dev/eth0]] and eth0 does exist! as well as eth1, eth2, eth3. #+BEGIN_EXAMPLE The Debian way is supported starting from sysvinit 2.88dsf-48 and hurd 1:0.5.git20140320-1: /etc/network/interfaces is used like on Linux. The only difference is that network boards appear in /dev, and interfaces should thus be specified as /dev/eth0 etc. #+END_EXAMPLE It looks like /etc/network/interfaces is an important file in the hurd #+BEGIN_SRC sh :dir /ssh:demo@127.0.0.1:/home/demo cat /etc/network/interfaces #+END_SRC #+RESULTS: : # This file describes the network interfaces available on your system : # and how to activate them. For more information, see interfaces(5). : : source /etc/network/interfaces.d/* : : # The loopback network interface : auto lo : iface lo inet loopback : : # The primary network interface : auto /dev/eth0 : iface /dev/eth0 inet dhcp Well I should take a look at =man 5 interfaces= apparently.
