Re: Some issues on fresh installed Debian-Hurd

[Jens Rehsack]

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)

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 ^^)

Maybe we should first check why /etc/hurd/rc is involved in boot-process?

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

Cheers
-- 
Jens Rehsack
rehsack@gmail.com