Re: Some issues on fresh installed Debian-Hurd

[Justus Winter]

Quoting Jens Rehsack (2014-06-02 11:46:10)
> Am 02.06.2014 um 11:21 schrieb Justus Winter 
> <4winter@informatik.uni-hamburg.de>:
> 
> > Quoting Jens Rehsack (2014-06-02 10:58:17)
> >> Am 02.06.2014 um 10:47 schrieb Justus Winter 
> >> <4winter@informatik.uni-hamburg.de>:
> >> 
> >>> Hi :)
> >>> 
> >>> Quoting Jens Rehsack (2014-06-02 08:28:50)
> >>> 
> >>>> Beside the kernel choice the installation went smoothly (a problem
> >>>> Debian-Hurd shares with Debian-kFreeBSD ^^).
> >>> 
> >>> I don't follow.
> >> 
> >> I most likely pebcak :)
> >> Generally it's (for me) poorly documented which kernel is meant by hurd-1 
> >> vs. hurd-1.3.nnn
> >> I got it later by doing apt-cache search (but initial boot was with 
> >> 1.3.nnn)
> > 
> > I still don't follow.  Hurd is not a kernel.  There is no package hurd-1 or 
> > hurd-1.3.nnn.
> 
> Ok - what I was talking about (and I'm sure the installer named it kernel or 
> with a similar term) was
> 
> gnumach-image-1.3.99-486 vs. gnumach-image-1.4-486

Fair enough.  Gnumach is our kernel allright.  I wonder why 1.3.99 is
still available.  Samuel?

`> 
> >> Same at kFreeBSD - it's for first attempt unclear whether kernel-8 is 
> >> favored over kernel (and which version is kernel - 8+patches, 9, ???)
> >> Enlightening comes later by trying it out ...
> >> 
> >> But beside that - Hurd installation was impressive sane for "experimental" 
> >> why kFreeBSD crashs because it always installs 9'er kernel (regardless the 
> >> choice I make at installer - but maybe PEBCAK, let's do Hurd first).
> >> 
> >>>> I had to modify line 117 in /etc/hurd/rc: "settrans -c /proc
> >>>> /hurd/procfs --compatible" -> "settrans -c /proc /hurd/procfs",
> >>>> otherwise the /proc file > system didn't came up.
> >>>> 
> >>>> That reduces the noise during boot dramatically (cannot stat /proc
> >>>> or something like that).
> >>> 
> >>> Which is very strange, as we switched to sysv-rc and don't use
> >>> /etc/hurd/rc no more.  Could you please double check that
> >>> (e.g. update-alternatives --display runsystem should say
> >>> /etc/hurd/runsystem.sysv).
> >> 
> >> # update-alternatives --display runsystem
> >> runsystem - auto mode
> >>  link currently points to /etc/hurd/runsystem.sysv
> >> /etc/hurd/runsystem.gnu - priority 5
> >>  slave halt: /sbin/halt-hurd
> >>  slave reboot: /sbin/reboot-hurd
> >> /etc/hurd/runsystem.sysv - priority 10
> >>  slave halt: /sbin/halt-sysv
> >>  slave reboot: /sbin/reboot-sysv
> >> Current 'best' version is '/etc/hurd/runsystem.sysv'.
> >> 
> >> I cannot say why no proc was mounted before I removed --compatible when 
> >> /etc/hurd/rc isn't used.
> >> But it works (proved by visual examination ^^)
> > 
> > Also, --compatible is a valid argument and it is recommended to use
> > that for compatibility with Linux' /proc.  There is no reason to
> > believe it should cause any trouble.
> 
> I cannot tell why it caused trouble - but now after I uninstalled 
> gnumach-image-1.3.99-486 the issue disappears.
> 
> >> Maybe we should first check why /etc/hurd/rc is involved in boot-process?
> > 
> > Yes.  Add exit 0 at the top.  It is not used.
> 
> Done without harming anything - seems to have a relation to 
> gnumach-image-1.3.99-486
> 
> >>>> But still (the VM is 06:03:47 up 3 days, 10:16) the console (xl
> >>>> vncviewer) doesn't come to a prompt. OpenSSH-Server runs, so I can
> >>>> access remotely. I'm quite unsure if it has to do with procfs or
> >>>> another issue (nothing suspicious in log or on screen) - but I'd
> >>>> like to mention it.
> >>> 
> >>> Check that the hurd console is running.  Also, check that you have an
> >>> entry like
> >>> 
> >>> c:23:respawn:/sbin/getty 38400 console
> >>> 
> >>> in your /etc/inittab to get a getty on the mach console (of course
> >>> inittab is only used if you use sysvinit).
> >> 
> >> I have some lines looking similar (was 'c' a placeholder for [1-9]?)
> >> 
> >> 1:2345:respawn:/sbin/getty 38400 tty1
> >> 2:23:respawn:/sbin/getty 38400 tty2
> >> 3:23:respawn:/sbin/getty 38400 tty3
> > 
> > No it's not.  Apparently, 'c' is a valid identifier.  If you have no
> > getty for the console, please add it. ttyX is used when the Hurd
> > console is running, 'console' refers to the mach console.
> 
> Added and there is a login :)

Good.  That means (most likely), that your hurd console isn't running.

> From original mail now only the nfs issue remains.

Our nfs client is likely just crappy.

> Playing around I see differences between
> 
> $ mount # no output, returns immediately
> # mount
> typed:device:hd0s1 on / type ext2fs (rw,no-inherit-dir-group)
> # cat /proc/mounts
> /dev/hd0s1 / ext2fs writable,no-inherit-dir-group,store-type=typed 0 0
> none /run /hurd/tmpfs 
> writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=102148K 0 0
> none /run/lock /hurd/tmpfs 
> writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=5M 0 0
> none /run/shm /hurd/tmpfs 
> writable,no-suid,no-exec,no-inherit-dir-group,no-sync,size=613980K 0 0
> waldorf:/data/pkgsrc /data/pkgsrc /hurd/nfs 
> hard,read-size=8192,write-size=8192,stat-timeout=3,cache-timeout=3,init-transmit-timeout=1,max-transmit-timeout=30,name-cache-timeout=3,name-cache-neg-timeout=3
>  0 0
> 
> Is there any reason for it?

Hurd's mount simply does not work like Linux' mount.  Our mount
doesn't parse /proc/mounts.  It should do so, if only to avoid this
reoccurring confusion.

> BTW: why I initially assumed the is a problem with the way mounting /proc:
> 
> # top
> Error, do this: mount -t proc proc /proc

At this point, did you verify that /proc is mounted at all?

But indeed:

$ mount -t proc proc ./foo
procfs: Too many arguments
Try `procfs --help' or `procfs --usage' for more information.
mount: cannot start translator /hurd/procfs: Translator died

That's bad.

Justus