Re: Some issues on fresh installed Debian-Hurd

[Justus Winter]

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.

> 
> 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.

> 
> 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.

> 
> >> 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.

Justus