On 2009-01-21, Grant Edwards <grante@visi.com> wrote:

> I noticed the same thing in the install I did a few days ago.
> Later in that install grub failed to install and after
> rebooting, my /dev directory was missing just about everything.
>
> Here's the /dev directory in the chroot'ed environment I got
> using stage3-i686-20090114.tar.bz2:
>
> livecd linux # ls -l /dev
> total 12
> lrwxrwxrwx 1 root root 15 Jan 20 21:30 MAKEDEV -> ../sbin/MAKEDEV
> -rw-r--r-- 1 root root 75 Jan 20 21:49 null
> drwxr-xr-x 2 root root 4096 Jan 13 19:29 pts
> drwxr-xr-x 2 root root 4096 Jan 13 19:29 shm

It looks like stage3-i686-20090114.tar.bz2 is broken.

The stage3 tar files for the previous two weeks are missing
(the DIGEST and CONTENTS files are on the mirrors, but no
tar.bz2).

stage3-i686-20081224.tar.bz2 seems to have the proper /dev
entries.

> I'm a little confused. Is there supposed to be an additional
> installation step to populate the /dev directory when using
> recent stage3 snapshots?

I guess the additional step is to not use a broken stage3
tarball.

--
Grant

Am Mittwoch, den 21.01.2009, 04:04 +0000 schrieb ext Grant Edwards:

> I'm a little confused. Is there supposed to be an additional
> installation step to populate the /dev directory when using
> recent stage3 snapshots?

One usually bind-mounts /dev, /proc and /sys into the chroot, like

mount --bind /dev /newinstall/dev # dito for /proc, /sys
chroot /newinstall

If this isn't documented, you should file a bug.

HTH...

Dirk

On Tue, Jan 20, 2009 at 11:52 PM, Dirk Heinrichs <dirk.heinrichs.ext@nsn.com> wrote:

Am Mittwoch, den 21.01.2009, 04:04 +0000 schrieb ext Grant Edwards:



> I'm a little confused. Is there supposed to be an additional

> installation step to populate the /dev directory when using

> recent stage3 snapshots?



One usually bind-mounts /dev, /proc and /sys into the chroot, like



mount --bind /dev /newinstall/dev # dito for /proc, /sys

chroot /newinstall



If this isn't documented, you should file a bug.



HTH...



* * * *Dirk






The best gentoo chroot guide I know of is:
http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2


Obviously, throw out any 32-bit specific stuff if you aren't doing 32-bit on a 64-bit machine.

Nick

On 2009-01-21, Dirk Heinrichs <dirk.heinrichs.ext@nsn.com> wrote:
> Am Mittwoch, den 21.01.2009, 04:04 +0000 schrieb ext Grant Edwards:
>
>> I'm a little confused. Is there supposed to be an additional
>> installation step to populate the /dev directory when using
>> recent stage3 snapshots?
>
> One usually bind-mounts /dev, /proc and /sys into the chroot, like
>
> mount --bind /dev /newinstall/dev # dito for /proc, /sys
> chroot /newinstall


> If this isn't documented, you should file a bug.

That's docuemented in the "normal" install doc, but not in the
quick install doc.

But, that doesn't really solve the problem, since after a
reboot the /dev directory will be empty again and you end up
with problems such as no console during startup.

--
Grant Edwards grante Yow! RELATIVES!!
at
visi.com

2009/1/21 Grant Edwards <grante@visi.com>

On 2009-01-21, Dirk Heinrichs <dirk.heinrichs.ext@nsn.com> wrote:

> Am Mittwoch, den 21.01.2009, 04:04 +0000 schrieb ext Grant Edwards:

>

>> I'm a little confused. Is there supposed to be an additional

>> installation step to populate the /dev directory when using

>> recent stage3 snapshots?

>

> One usually bind-mounts /dev, /proc and /sys into the chroot, like

>

> mount --bind /dev /newinstall/dev # dito for /proc, /sys

> chroot /newinstall





> If this isn't documented, you should file a bug.



That's docuemented in the "normal" install doc, but not in the

quick install doc.



But, that doesn't really solve the problem, since after a

reboot the /dev directory will be empty again and you end up

with problems such as no console during startup.



--

Grant Edwards * * * * * * * * * grante * * * * * * Yow! RELATIVES!!

* * * * * * * * * * * * * * * * *at

* * * * * * * * * * * * * * * visi.com






IIRC thats because* /dev should be populated on startup by udev so i would check that udev is installed and working properly, if you use openrc then this could be the cause as openrc now starts udev through normal scripts i think, sometimes on upgrade from baselayout 1 they may not be automatically added to the right runlevels.


- Nick

On Wed, 21 Jan 2009 15:50:17 +0000, Nick Cunningham wrote:

> > But, that doesn't really solve the problem, since after a
> > reboot the /dev directory will be empty again and you end up
> > with problems such as no console during startup.

> IIRC thats because /dev should be populated on startup by udev so i
> would check that udev is installed and working properly, if you use
> openrc then this could be the cause as openrc now starts udev through
> normal scripts i think, sometimes on upgrade from baselayout 1 they may
> not be automatically added to the right runlevels.

You still need /dev/console in the dev directory of the root partition,
along with /dev/null. Anything else is a waste of disk space and inodes
as the static /dev/devices are hidden as soon as udev starts. If the
tarball doesn't contain /dev/console it is broken, but it is also broken
if it contains thousands of device entries.


--
Neil Bothwick

Do not merely believe in miracles; rely on them. * Finagle

On 2009-01-21, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 21 Jan 2009 15:50:17 +0000, Nick Cunningham wrote:
>
>>> But, that doesn't really solve the problem, since after a
>>> reboot the /dev directory will be empty again and you end up
>>> with problems such as no console during startup.
>
>> IIRC thats because /dev should be populated on startup by udev so i
>> would check that udev is installed and working properly, if you use
>> openrc then this could be the cause as openrc now starts udev through
>> normal scripts i think, sometimes on upgrade from baselayout 1 they may
>> not be automatically added to the right runlevels.
>
> You still need /dev/console in the dev directory of the root
> partition, along with /dev/null. Anything else is a waste of
> disk space and inodes as the static /dev/devices are hidden as
> soon as udev starts. If the tarball doesn't contain
> /dev/console it is broken, but it is also broken if it
> contains thousands of device entries.

Then all the stage3 tarballs I've ever seen are broken. They
either contain 5000+ entries, or nothing but these:

drwxr-xr-x root/root 0 2009-01-13 21:20 ./dev/
-rw-r--r-- root/root 0 2009-01-13 21:20 ./dev/null
lrwxrwxrwx root/root 0 2009-01-13 19:29 ./dev/MAKEDEV -> ../sbin/MAKEDEV
-rw-r--r-- root/root 0 2009-01-13 19:29 ./dev/.keep
drwxr-xr-x root/root 0 2009-01-13 19:29 ./dev/shm/
-rw-r--r-- root/root 0 2009-01-13 19:29 ./dev/shm/.keep
drwxr-xr-x root/root 0 2009-01-13 19:29 ./dev/pts/
-rw-r--r-- root/root 0 2009-01-13 19:29 ./dev/pts/.keep

What I do know is that using a stage3 with 5000+ entries allows
you to install using either the normal or quick install
instructions. Using one with just the above /dev entries
causes problems either way -- more so if using the quick
install instructions since there is no step where you mount
udev to /mnt/gentoo/dev.

--
Grant Edwards grante Yow! I'm sitting on my
at SPEED QUEEN ... To me,
visi.com it's ENJOYABLE ... I'm WARM
... I'm VIBRATORY ...

Am Mittwoch, 21. Januar 2009 17:48:27 schrieb Grant Edwards:

> Then all the stage3 tarballs I've ever seen are broken. They
> either contain 5000+ entries, or nothing but these:

Yes they are. Having 5000+ entries in there while udev is in used is just
stupid. I'm glad they've fixed that know.

> drwxr-xr-x root/root 0 2009-01-13 21:20 ./dev/
> -rw-r--r-- root/root 0 2009-01-13 21:20 ./dev/null
> lrwxrwxrwx root/root 0 2009-01-13 19:29 ./dev/MAKEDEV ->
> ../sbin/MAKEDEV -rw-r--r-- root/root 0 2009-01-13 19:29 ./dev/.keep
> drwxr-xr-x root/root 0 2009-01-13 19:29 ./dev/shm/
> -rw-r--r-- root/root 0 2009-01-13 19:29 ./dev/shm/.keep
> drwxr-xr-x root/root 0 2009-01-13 19:29 ./dev/pts/
> -rw-r--r-- root/root 0 2009-01-13 19:29 ./dev/pts/.keep

Yes, that's broken as well. All you need, as Neil wrote, is null and console.

> What I do know is that using a stage3 with 5000+ entries allows
> you to install using either the normal or quick install
> instructions.

And forcing you to remove them later, since they just waste inodes (on an
inode based fs, of course).

> Using one with just the above /dev entries
> causes problems either way -- more so if using the quick
> install instructions since there is no step where you mount
> udev to /mnt/gentoo/dev.

So you need to file two bug reports ;-)

Bye...

Dirk

On 2009-01-21, Dirk Heinrichs <dirk.heinrichs@online.de> wrote:
> Am Mittwoch, 21. Januar 2009 17:48:27 schrieb Grant Edwards:
>
>> Then all the stage3 tarballs I've ever seen are broken. They
>> either contain 5000+ entries, or nothing but these:
>
> Yes they are. Having 5000+ entries in there while udev is in
> used is just stupid. I'm glad they've fixed that know.
>
>> drwxr-xr-x root/root 0 2009-01-13 21:20 ./dev/
>> -rw-r--r-- root/root 0 2009-01-13 21:20 ./dev/null
>> lrwxrwxrwx root/root 0 2009-01-13 19:29 ./dev/MAKEDEV ->
>> ../sbin/MAKEDEV -rw-r--r-- root/root 0 2009-01-13 19:29 ./dev/.keep
>> drwxr-xr-x root/root 0 2009-01-13 19:29 ./dev/shm/
>> -rw-r--r-- root/root 0 2009-01-13 19:29 ./dev/shm/.keep
>> drwxr-xr-x root/root 0 2009-01-13 19:29 ./dev/pts/
>> -rw-r--r-- root/root 0 2009-01-13 19:29 ./dev/pts/.keep
>
> Yes, that's broken as well. All you need, as Neil wrote, is
> null and console.
>
>> What I do know is that using a stage3 with 5000+ entries allows
>> you to install using either the normal or quick install
>> instructions.
>
> And forcing you to remove them later, since they just waste
> inodes (on an inode based fs, of course).
>
>> Using one with just the above /dev entries causes problems
>> either way -- more so if using the quick install instructions
>> since there is no step where you mount udev to
>> /mnt/gentoo/dev.
>
> So you need to file two bug reports ;-)

Yup, I'll put them on my list of things to do:

1) bug report for quick-install

2) bug report for 2008.0 stage3 (too many useless /dev entries)

3) bug report for weekly autobuild stage3 (missing /dev/console)

--
Grant Edwards grante Yow! I'm ZIPPY the PINHEAD
at and I'm totally committed
visi.com to the festive mode.

On 2009-01-21, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 21 Jan 2009 15:50:17 +0000, Nick Cunningham wrote:
>
>>> But, that doesn't really solve the problem, since after a
>>> reboot the /dev directory will be empty again and you end up
>>> with problems such as no console during startup.
>
>> IIRC thats because /dev should be populated on startup by udev
>> so i would check that udev is installed and working properly,
>> if you use openrc then this could be the cause as openrc now
>> starts udev through normal scripts i think, sometimes on
>> upgrade from baselayout 1 they may not be automatically added
>> to the right runlevels.
>
> You still need /dev/console in the dev directory of the root partition,
> along with /dev/null.

Try telling that to somebody in the Gentoo forum hiding behind
the screen name "desultory". Sheesh. I reported the issue to
the forum thread as requested by the article on www.gentoo.org,
and I got a very hostile reaction. Bascially I got a snide,
insulting response, a complete denial that there was a problem
with the tarball in question, and a denial that either
/dev/console or /dev/null is needed at boot time.

That's the last time I waste my time with that forum. I should
have known. Web forums all suck. Web forum UIs are all
completely abominable, and they seem to be inhabited almost
exclusively by surly, unjustifiably arrogant junior-high kids
hiding behind stupid screen names and even worse avatars.

> Anything else is a waste of disk space and inodes as the
> static /dev/devices are hidden as soon as udev starts.

Yup.

> If the tarball doesn't contain /dev/console it is broken, but
> it is also broken if it contains thousands of device entries.

--
Grant