help-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some issues on fresh installed Debian-Hurd


From: Jens Rehsack
Subject: Re: Some issues on fresh installed Debian-Hurd
Date: Mon, 2 Jun 2014 12:28:16 +0200

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

> Quoting Jens Rehsack (2014-06-02 11:46:10)
>> Am 02.06.2014 um 11:21 schrieb Justus Winter 
>> <4winter@informatik.uni-hamburg.de>:
>> 
>> [...]
>> 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?
> 
> `> 
[...]
>>> 
>>> 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.

Didn't got installed ...
Now it's 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

Finally there is something - even if I don't know what:
# ls -l /proc | wc -l
75
# cat /proc/1/cmdline
init [2]

So it seems to me something what feels like a procfs is there - but what ;)

But /proc/mounts doesn't show itself (what else could be missing?)

Cheers
-- 
Jens Rehsack
rehsack@gmail.com








reply via email to

[Prev in Thread] Current Thread [Next in Thread]