Installation Issues With Current Stage3 Tarballs

[gabrielferreira]

I tried your solution. Unfortunately it didn't work. It can't umounr /dev. Says it's busy. I exited the chroot and umounted proc and boot but /mnt/gentoo/dev it isn't able to umount. So I am forced to poweroff or reboot.

I had the same problem, but then I realized that I forgot the "-l" option for the "umount"

Code: Select all

umount -l /mnt/gentoo/dev

Maybe it helps you

[disi]

I tried your solution. Unfortunately it didn't work. It can't umounr /dev. Says it's busy. I exited the chroot and umounted proc and boot but /mnt/gentoo/dev it isn't able to umount. So I am forced to poweroff or reboot.

I had the same problem, but then I realized that I forgot the "-l" option for the "umount"

Code: Select all

umount -l /mnt/gentoo/dev

Maybe it helps you

Be careful, -l doesn't really umount the volume/partition. It just unlinks it everywhere and removes the entry in /etc/mtab, you are still writing on the former mounted volume.

umount -l is only useful, if you are 100% sure the volume isn't there any more, like an external USB stick that you removed and forgot to umount it first.

The proper way would be to boot from live medium, mount the partition and then create the nodes on that partition in /dev...

[shazam75]

Hello friends

I have also the same problem, but let me tell you what my setup is.

I have an original gentoo install on /dev/sda (which is an IDE Drive). From my working original install, i have created a new gentoo install on /dev/sdc (which is a new SATA drive). When I try and boot the new Gentoo install, I am having this same problem where the boot is hanging and not going any further.

Now to fix this problem as Neddy suggested, can I do this by

1. mount /dev/sdc1 /mnt/NEWGentooBoot (boot)
2. mount /dev/sdc3 /mnt/NEWGentoo (root)

then do the fix as Neddy suggested by going into
cd /mnt/NEWGentoo/dev
rm null
mknod --mode=600 console c 5 1
mknod --mode=666 null c 1 3
mknod --mode=666 zero c 1 5

then chroot into new install and rc-update add udev sysinit

Will this work?

Thank you
Shelton.

[shazam75]

Hi - maybe try loading with a LiveCD and follow these instructions?

Code: Select all

The recent stage 3 archives (May 2011) are the first the include our new init
system OpenRC.
There are some quirks still that need some manual work to resolve.

NOTICE: Some places suggest enabling CONFIG_DEVTMPFS in your kernel.
This is a workaround which will make your system boot, but is not a proper
fix.

The most typical symptom you might experience is that the system does not boot
after you have completed the installation. To fix this, you have to execute
the following steps.
If you read this during your installation, you can fix this while still on the
LiveCD, if not, please reboot your machine into the LiveCD environment, just
like you did while installing.

The following instructions assume that you have mounted your complete Gentoo
filesystem in /mnt/gentoo/ EXCEPT for the bind-mount of /dev.

First, some device node files need fixing: From within the LiveCD (not
chrooted), execute:
# cd /mnt/gentoo/dev
# rm null
# mknod --mode=600 console c 5 1
# mknod --mode=666 null c 1 3
# mknod --mode=666 zero c 1 5

Now, chroot into your installation (chroot /mnt/gentoo /bin/bash) and execute:
# rc-update add udev sysinit

By doing these steps, you allow udev to correctly start and populate /dev for
you.

Additionally, you might have to create the init scripts for your network
devices:
# cd /mnt/gentoo/etc/init.d
# ln -s net.lo net.ethX
execute this step for each of your network interface cards, replacing X with
the device number.

Cheers
Shelton.

[cwr]

One thing that bit me when I went to update /dev (thanks, Neddy) was that I didn't
remove the existing /dev/null file, and either mknod didn't give an error, or I missed
it. Might be worth checking that /dev is empty before adding the essential nodes.

Will

(And if you use lvm, don't forget to add it to the boot runlevel, along with udev
in sysinit).

[shazam75]

Hello friends

I have also the same problem, but let me tell you what my setup is.

I have an original gentoo install on /dev/sda (which is an IDE Drive). From my working original install, i have created a new gentoo install on /dev/sdc (which is a new SATA drive). When I try and boot the new Gentoo install, I am having this same problem where the boot is hanging and not going any further.

Now to fix this problem as Neddy suggested, can I do this by

1. mount /dev/sdc1 /mnt/NEWGentooBoot (boot)
2. mount /dev/sdc3 /mnt/NEWGentoo (root)

then do the fix as Neddy suggested by going into
cd /mnt/NEWGentoo/dev
rm null
mknod --mode=600 console c 5 1
mknod --mode=666 null c 1 3
mknod --mode=666 zero c 1 5

then chroot into new install and rc-update add udev sysinit

Will this work?

Thank you
Shelton.

[liunx]

Thanks very much, i was puzzled by this problem many days!

[Rinkhals]

I'm borked as well.

Been on this since Monday and it's now Friday Afternoon.

I am using the stage3-i686-20110614.tar.bz2 tarball.

Code: Select all

# cd /mnt/gentoo/dev
# rm null
# mknod --mode=600 console c 5 1
mknod: `console': File exists
# mknod --mode=666 null c 1 3
# mknod --mode=666 zero c 1 5
mknod: `zero': File exists

Chrooted into the install, cd to /etc/runlevels/sysinit/, symlink udev to /etc/init.d/udev

Code: Select all

ls -l /etc/runlevels/sysinit/
total 0
lrwxrwxrwx 1 root root 17 Jun 28 12:15 devfs -> /etc/init.d/devfs
lrwxrwxrwx 1 root root 17 Jun 28 12:15 dmesg -> /etc/init.d/dmesg
lrwxrwxrwx 1 root root 16 Jul  1 11:37 udev -> /etc/init.d/udev

Looks ok.

Code: Select all

rc-update add udev sysinit
 * rc-update: udev already installed in runlevel `sysinit'; skipping

Reboot.

New install still borked.

Stops at

Code: Select all

init.sh used greatest stack depth: 6276 bytes left 

Which is progress, I guess. It used to stop at

Code: Select all

init-early.sh used greatest stack depth: 6284 bytes left 

which is one line back.


[Edit: Sorry for being such an arse! I had created a little script which did all the steps in the install, and one of the things it did was mount --rbind /dev /mnt/gentoo/dev which obviously invalidated the whole process. What an idiot.]

[vladthedog]

thanks. i decided to try to install gentoo ( for the first time!) from within an arch install on my laptop. i was starting to get frustrated because I couldn't figure out what I did wrong. it's up and running and now compiling kde-meta so I really appreciate the help

[Whitewolf Fox]

Hi everyone,

the fix described by NeddySeagoon in the first place fixed my issues. Thank you for that!

Is this issue actually fixed in current stage3 snapshots? If it is not: I'd like to understand what makes this take so long to fix it. I'm allready addicted to Gentoo - so no risk to loose a user here But if someone tries to use Gentoo for the first time, spends several hours in installing it the manual way and ends up with a not booting system he wouldn't consider to use this distribution, I guess.
Another point is, that this fix looks quite simple to me: Just have 3 files created and it works. What makes it so difficult to add these files to the stage files?

I don't want to attack anybody - I'd just like to understand this to tighten my understanding of Gentoo's internel organisation and build - process, since I often had the feeling that issues are difficult to solve and to track in Gentoo (had several bugs filed with strange workflows and results lately).

[swathe]

Hi everyone,

the fix described by NeddySeagoon in the first place fixed my issues. Thank you for that!

Is this issue actually fixed in current stage3 snapshots?

I just did an install today with the latest snapshot and the issue still exists. This fix resolves the issue perfectly though.

[Whitewolf Fox]

This brings me back to my question/statement: There seems to be something terribly wrong with Gentoo's update workflow and quality management, when a known issue with a simple and known fix, which prevents users from installing Gentoo with the corresponding manual, isn't fixed for one month and 8 days now!

[angry_vincent]

The issue is fixed in latest tarballs (the one i tested is stage3-amd64-20110630.tar.bz2).

[swathe]

I still had the issue with an x86 install.

[BServiss]

This brings me back to my question/statement: There seems to be something terribly wrong with Gentoo's update workflow and quality management, when a known issue with a simple and known fix, which prevents users from installing Gentoo with the corresponding manual, isn't fixed for one month and 8 days now!

I raise this question as well after spending two days trying to install. I am also disgusted by this.

Also, it seems the when setting up the file systems with the handbook, ext3 is actually ext4 or least I had to add the ext4 drivers to get to the point where I find this error which is a month old and minor.

Truly sorry I came back and wont make the same mistake again

[swathe]

It does suck but there may be more work required behind the scenes than it takes to do the simple fix. I think that just mentioning this fix in the handbook for now would be fine as it takes less than a minute to fix. Unfortunately I lack the knowledge to be able to troubleshoot and try to come up with a fix for the issue, but I view this as an inconvenience more than anything else, and it will take more than a minor setback to stop me from using Gentoo.

[Whitewolf Fox]

Exactly this "required work behind the scenes" I'd like to know about. What does it take to do such a fix?

I don't want to anybody misunderstand me: I have a very high opinion about the Gentoo - Developers and the overall quality of Gentoo! But from time to time it looks "from the outside" like there's pure chaos in the development. Bugs not even looked at for months, known and perfectly tested fixes not distributed to the current stages, documentation timed out (which is known, since if one asks in the #gentoo on freenode or this forum he get's the answer how to ship around the issue), etc. Maybe it is necessary to rethink the workflow of Gentoo? Because I see that the developers know what they do - but sometimes it looks like they just cannot continue their work because of missing permissions, lacking reviews, etc.

Is there a developer out there who might briefly draft the steps necessary for a fix like this to reach the current stages or even the needed steps to take until such a hint is written to the handbook? That would be very interesting to understand Gentoo's insides and the "work behind the scenes".

Thank you!

[swathe]

I guess you could try and get on the relevant mailing list and try and get some more info.

[Whitewolf Fox]

I already am on the lists. But all I see are the discussions, not the workflow around them. What you can see on that lists for example are questions and discussions between the devs. Finally, you read something like "I now have changed x or y" - but who is in charge to write changes to the core - files or because of the rights he has the possibility to do so, you cannot see.

[lyallp]

Thanks for the post.
I was doing a fresh install on 19-Jul-2011 and hit this problem. Your solution worked!

[NeddySeagoon]

As I've posted further up the thread, a lot of effort went into checking out the upgrade path from baselayout1 to baselaoout2, so that is fairly smooth.

However, the weekly stage3 autobuilds were not tested ubtil baselayout2 actually went stable and the issues here were discovered.
This made life difficult for new users. The rest is history, as the stages are now fixed.

[malto]

remark: all was rightly-right, but week ago in routine eix-sync && genkernel --menuconfig all to enable modules and after compilation and rebootion - kernel-2.6.38r5 (3.0.1 either) extremely want to using mount -t auto -o ro.

In loaded system everything works fine, but normal user cant open gnome-terminal - grantpt failed: error - it says.

Tried steps from LiveDVD:

Code: Select all

mount /dev/sda3/ mnt/gentoo
cd /mnt/gentoo/dev
rm null console zero
mknod --mode=600 console c 5 1
mknod --mode=666 null c 1 3
mknod --mode=666 zero c 1 5
rc-update delete udev sysinit
rc-update add udev sysinit

Code: Select all

crw-rw-rw- 1 root root 1, 3 Aug 10 12:40 /dev/null
crw-rw-rw- 1 root root 1, 5 Aug 10 12:40 /dev/zero
crw------- 1 root root 5, 1 Aug 10 12:39 /dev/console

Code: Select all

0 lrwxrwxrwx 1 root root 16 Aug 10 16:41 /etc/runlevels/sysinit/udev -> /etc/init.d/udev

rc-update show - http://paste.pocoo.org/show/456025/
grub.conf - http://paste.pocoo.org/show/456029/
mount - http://paste.pocoo.org/show/456034/
fstab - http://paste.pocoo.org/show/456040/

Nothing happens, no changes as allays extremely want to using mount -t auto -o ro.

So it's very strange if it happens in that routine way, just eix-sync and genkernel.
Now it works on kernel-2.6.38r5 (thanks to backup in /boot/).

NeddySeagoon what do you think about that? Anyone?

Regards to everyone.

PS: empty /dev/pts/ and grantpt failed: error in gnome-terminal - SOLVED by adding in kernel 3.0.1 DEVTMPFS [=y] and DEVTMPFS_MOUNT [=y] plus updating genkernel to last ~x86 (no matter isntit?), but using mount -t auto -o ro still the same.

[jnagyjr]

I'm using the 2011-08-11 minimal CD (I'm returning to Gentoo and real linux after using Windows and Ubuntu for too long), x86 (AMD Sempron, 1.5GB RAM) and am having boot issues.

Everything goes fine up until kernel config. I've done it manually (make menuconfig from /usr/src/linux with the latest gentoo sources) and automagically (genkernel). No matter which method I use, when I go to reboot I have two issues.

1) Booting into Gentoo. It cannot find a valid root system even though everything is listed exactly like it needs to be according to the Installation Guide.

/dev/sda1 /boot
/dev/sda2 swap
/dev/sda3 /
/dev/sda4 /home

(with options set properly, of course)

The only things I can think of is that /dev/sda3 is ext3 and /dev/sda4 is ext4.

2) Booting in to Windows. hd1,1 (hd1,0 is taken up by the recovery partition put there by Compaq) is valid, but it just sits there after I select it and hit enter in GRUB (Windows XP SP3, fwiw).

All the operations performed before unmounting from the minimal live CD and rebooting seem to go well, I get no errors to report (genkernal and manual kernel config complain about one certain flag not being found but since the Installation Guide doesn't address it and it doesn't seem to affect the rest of the system, I have been assuming it's a non-issue).

Do I need to make my /home and / partitions the same? I figured using genkernel support for ext3 and ext4 would be automagically included, if this is not the case...? I know when I configured the kernel manually, I included full support for ext2, 3, and 4. I compiled everything into the kernel I could instead of having to mess with modules. Is there anyway to automatically generate a valid modules load file (modules.conf, iirc)? I have quite a few options selected (but not nearly all) to make sure all my hardware works. This is really frustrating, I was hoping my memory wasn't rose-tinted (I don't remember having these problems in the past, but a forum search might prove me wrong :p), or else I've just gotten really stupid.

[NeddySeagoon]

jnagyjr,

As your system cannot find a root filesystem, its not got as far as reading /etc/fstabl, which is on the root filesystem.

It would be useful to have some of your kernel panic message, in particular the part that reads unknown-block (x,y) as the numbers tell a lot about the reasn the root filesystem cannot be mounted.

Here are the main reasons, is some sort of logical order.

1. Your kernel must have the partition type code included or it can't read the partition table.
On a PC, its usually MSDOS Partition tables.

2. You must have SCSI disk support built in. It must be <*>, not <M> think about it. SCSI disk support is needed to mount the root filesystem, If the SCSI disk module is a module located on the root filesyatem, how will you mount the root filesystem to read a module you need to mount the root filesystem.

3. Your low lever chipset driver, probably from the SATA menu must be build in as <*>

4. Your root filesystem driver must also be built in. <*> not <M>

5. you must install your kernel properly.

That really is all you need to boot from an internal drive.
Genkernel will make you a fully modular kernel with an initrd. The initrd is a temporary root filesystem that aboids the requirements above.

For detailed help, please post your lspci output.

Linux tends to autoload needed modules these days, there are three kernel module loading mechanisims.
The only thing you will need to load in the modules file is your network card module.

[jnagyjr]

The problem was in the Installation documentation. Changing the drive designators from /dev/sda# to /dev/hda# fixed the problems.