the experimental stages (i tried stage3-amd64-20090115.tar.bz2 and the corresponding x86) do not contain too many files in dev: rbu@peanut ~/tmp/stage3-amd64-20090115/dev $ ls -la total 16K drwxr-xr-x 4 rbu rbu 4.0K 2009-01-15 04:48 . drwxr-xr-x 17 rbu rbu 4.0K 2009-01-15 08:10 .. drwxr-xr-x 2 rbu rbu 4.0K 2009-01-15 02:29 pts drwxr-xr-x 2 rbu rbu 4.0K 2009-01-15 02:29 shm -rw-r--r-- 1 rbu rbu 0 2009-01-15 02:29 .keep lrwxrwxrwx 1 rbu rbu 15 2009-01-19 22:22 MAKEDEV -> ../sbin/MAKEDEV -rw-r--r-- 1 rbu rbu 0 2009-01-15 04:48 null First of all, the "null" node is actually a file (so data going to /dev/null will be stored in there), and most notably the console node is missing. You cannot boot a system without either of those. all other missing nodes will be populated with the first boot, but at least console and null are needed. furthermore, there's no "2009" or "autobuild" available as version in this bugzilla product.
I'd noticed this same thing myself, but I assume it was a change in the baselayout ebuild that was causing this and that it was intentional.
I'm not sure what triggered this, but it appears that baselayout was being emerged in the stage ROOT with USE=-build and then never getting rebuilt. My guess is a behavior change with portage-2.1.6 was causing it to not get rebuild any longer. I removed the --noreplace option being passed to emerge when the rest of the packages are emerged in the stage1 ROOT, so that baselayout will be re-emerged with USE=build, which will create the /dev nodes. I haven't tested the fix, but when the x86/amd64 autobuilds run later this week on poseidon, we'll know one way or the other.
Not fun! I've gone crazy figuring this out...
This looks fixed now, though :)
