Re: Some issues on fresh installed Debian-Hurd
Am 02.06.2014 um 11:21 schrieb Justus Winter <firstname.lastname@example.org>:
> Quoting Jens Rehsack (2014-06-02 10:58:17)
>> Am 02.06.2014 um 10:47 schrieb Justus Winter <email@example.com>:
>>> 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
>> # 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
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:
Error, do this: mount -t proc proc /proc