Am 02.06.2014 um 11:21 schrieb Justus Winter <[email protected]>:
> 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. 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 >> 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 :) From original mail now only the nfs issue remains. 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? BTW: why I initially assumed the is a problem with the way mounting /proc: # top Error, do this: mount -t proc proc /proc Cheers -- Jens Rehsack [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
