Re: Some issues on fresh installed Debian-Hurd

[Jens Rehsack]

Am 02.06.2014 um 11:21 schrieb Justus Winter 
<4winter@informatik.uni-hamburg.de>:

> 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.

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
rehsack@gmail.com