Hurd Tips

[Joshua Branson]

Hey Hurd people!

I've been using Emacs for so long, that I forget sometimes that it is
a little clunky to use.  C-y is paste?  C-x is NOT to cut text?  What!?
I love Emacs, but it is a little odd sometimes.  In a similiar vein, I
wanted to record some of the "papercuts" that using the Hurd currently
has, before I forget what the issues are.  Please do not take these
things as me saying the "Hurd sucks".  Rather, these are minor issues,
with maybe simple fixes.

- syncfs vs. sync -> Until syncfs' functionality can be merged into
  sync, maybe we should link sync to syncfs ?
  
- Upgrade issues:
  - When I used the stable release of Debian GNU/Linux, I used command
    this to upgrade:

    `    # apt update`

    `     # apt upgrade`.

    But the Hurd recommends to [use this update
    command](https://www.debian.org/ports/hurd/hurd-install):

    ```
      # apt upgrade --without-new-pkgs
    
      # apt full-upgrade
    ```

        Perhaps, this is the upgrade command that one should use when
    using the unstable Debian release? I have a hard time remembering
    the above command, so I define the alias "update" for it. Maybe we
    should define such an 'update' alias by default?

  - When I choose to upgrade the Hurd after starting i3, I patiently
    wait for the upgrade to finish.  I do not use any other programs
    or switch workspaces. When I have done so in the past, many times
    the Hurd slowed to a crawl and eventually X locked up on me.
    C-Alt-Del did not kill X, even though I have configured it to do
    so.  I have noticed that if X starts to lock up, then I have 5
    seconds to press C-Alt-Del, otherwise C-Alt-Del won't work.  I am
    using a T43 with 1.5 Gb of RAM, so maybe the hardware with limited
    resources is to blame?  Though OpenBSD can easily run with that
    amount of limited resources (though they make it a goal to support
    really old hardware).  Sometimes I believe that Hurd has been sooo
    slow, that I could not connect to it via ssh and halt it remotely.
    How hard would it be to add a GNU Mach specific ["raise the
    elephant"?  ](https://en.wikipedia.org/wiki/Magic_SysRq_key)

  - If the upgrade is major, (I have not upgraded in 2+ months), then
        I make sure that I run the upgrade in the Hurd console, which
        always works on major.  When I have upgraded the Hurd via a
        terminal in i3 on a major upgrade, then the Hurd got so busy that
        it stopped accepting my keystrokes.  C-Alt-Del failed to kill X.

- Lock screen issues (i3 & xlock): sometimes when I am performing an
  upgrade patiently waiting and not typing on the keyboard, the X lock
  screen will appear and not accept my keystrokes.  I will get stuck
  on the lock screen...and I will wait several minutes (max 10).  At
  that point, I hope the update finished, and I force shutoff the
  machine.  Sometimes I try ssh-ing into the machine to shut off the
  Hurd, and that doesn't work.
  
- One cannot do `# halt` when running X. [This is a known
  issue.](https://darnassus.sceen.net/~hurd-web/faq/x-exit/) The last
  time that I tried it on the Hurd, the OS did not return me a
  console, nor could I switch to another Hurd console.  The Hurd was
  still running, but was not responding to any keyboard commands.  I
  should try this again and see if I can ssh into the machine at this
  state. Not being able to run `# halt` will confuse the casual user.
  So to halt my machine, I still have to kill X, then run `#halt`. I
  tried running shutdown-hurd from inside X, as per Samuel's request.
  Weirdly enough, after I pressed return on that command, I could
  still move the cursor.  It took X maybe 5 or so minutes before it
  locked up on me and stopped accepting mouse movements.  Then I had
  to hard shutoff.  I believe I still had filesystem corruption that
  was fixed on next boot.

- `sudo service networking restart` normally fails.  I have to run `#
  service networking stop; service networking start; service
  networking start` to restart the hurd's networking, since the first
  "start" command always fails.  It is not the end of the world, that
  I have to run the "start command twice, but it is a little
  confusing.

- ftpfs doesn't work so well without internet (obviously)
  - settrans -c \~/hurd-iso /hurd/iso9660fs 
$HOME/ftp://ftp.someftpserver.org/img.iso
  - Often times I will be working offline editing the wiki, and I will
    type `ls ~/`, which will take one minute to list the directory
    contents.  C-c, works but really slowly (30 second lag).  It would
    be nice if during ftpfs startup, it could check if the Hurd has an
    active internet connection.  If the IP address is 0.0.0.0 maybe
    that means no internet?

- Starting X issue: This one took me a while to figure out.  The Hurd
  automatically runs fsck on your filesystems at boot, and it fixes
  all issues without user intervention!  BUT sometimes it is unable to
  automatically rid the filesystem of corruption, and the Hurd will
  mount your filesystem/s readonly.  When this happens, X will fail to
  start, because X needs to write some temporariy file in ~/ ...?
  Some type of socket or something?  Anyway, I have this poorly
  written script in my `.bashrc` to work around this issue:

# tell me if / or /home are writeable or not
myroot=$(fsysopts / | awk '{ print $2 }')
myroot=${myroot:2}

myhome=$(fsysopts /home | awk '{ print $2 }')
myhome=${myhome:2}

mytty=$(tty)
mytty=${mytty:0:9}

# autostart X if this is tty1 and / and /home are writable
if [[ $myhome == $myroot && $myhome == "writable" && $mytty == "/dev/tty1" ]]; 
then
    eval `ssh-agent -s`
    ssh-add
    startx;
else
    echo "/ is $myroot.";
    echo "/home is $myhome";
    echo "tty is $mytty.";
    echo "NOT starting X.";
fi

- Using the Hurd in qemu: I personally find that the Hurd is far more
  reliable to use on real hardware.  So I no longer use the Hurd via
  qemu.  I believe that the reason that I found it hard to use, was
  that the Hurd would "lock up" in qemu, I would then kill qemu, which
  would cause filesystem corruption.  (Yes users should try to ssh
  into the Hurd and kill it that way, but sometimes that won't work
  either).  Upon rebooting the Hurd in qemu, most of the time, the
  auto fsck worked.  BUT sometimes, it failed and mounted things
  readonly.  So I would be confused when apt failed to work.  At the
  time I did not know that users may need to manually fsck the Hurd's
  filesystem from GNU/Linux with lose2up (is that the right command?).
  I still don't know how to reliable fsck the Hurd via lose2up.
  Perhaps we could write a script, that would automatically use
  lose2up to fsck the filesystem, before starting it in qemu.

Thoughts?

Joshua


-- 

Joshua Branson
Sent from the Hurd