Quoting Jens Rehsack (2014-06-02 10:58:17) > Am 02.06.2014 um 10:47 schrieb Justus Winter > <[email protected]>: > > > 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
