Quoting Jens Rehsack (2014-06-02 11:46:10) > Am 02.06.2014 um 11:21 schrieb Justus Winter > <4win...@informatik.uni-hamburg.de>: > > > Quoting Jens Rehsack (2014-06-02 10:58:17) > >> Am 02.06.2014 um 10:47 schrieb Justus Winter > >> <4win...@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. > > 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
Fair enough. Gnumach is our kernel allright. I wonder why 1.3.99 is still available. Samuel? `> > >> 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 :) Good. That means (most likely), that your hurd console isn't running. > From original mail now only the nfs issue remains. Our nfs client is likely just crappy. > 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? Hurd's mount simply does not work like Linux' mount. Our mount doesn't parse /proc/mounts. It should do so, if only to avoid this reoccurring confusion. > BTW: why I initially assumed the is a problem with the way mounting /proc: > > # top > Error, do this: mount -t proc proc /proc At this point, did you verify that /proc is mounted at all? But indeed: $ mount -t proc proc ./foo procfs: Too many arguments Try `procfs --help' or `procfs --usage' for more information. mount: cannot start translator /hurd/procfs: Translator died That's bad. Justus -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140602102236.10651.93...@thinkbox.jade-hamburg.de