[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