Re: Some issues on fresh installed Debian-Hurd
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
Reply to: