Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-desktop
Lists: gentoo-desktop: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-desktop@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: System problems
Date: Sun, 20 Mar 2011 09:32:23 +0000 (UTC)
Lindsay Haisley posted on Sat, 19 Mar 2011 23:46:06 -0500 as excerpted:

> I'm caught between a rock and a hard place.
> I've been running this desktop box using kernel 2.6.23-gentoo-r3 and
> have come to the point at which there are too many dependencies and
> reverse dependencies, so I _have_ to upgrade to kernel 2.6.29-gentoo-r5
> and have been unable to bring the system up in the new kernel.  Here's
> what's happening.

You're still running 2.6.23 on a /desktop/?  I can see how it could be 
argued for a server that had /years/ of uptime, but for a desktop... I 
/really/ think you should upgrade a bit more often (as it would seem 
you're unfortunately finding out)...

> The newer kernel requires a newer version of udev, which I emerged.  The
> system came up with a root device of some sort mounted, I think in
> single-user mode, but couldn't mount other devices.
> So I changed the main drive designations to UUID's in /etc/fstab,
> re-emerged the newer udev, and tried again.  This time I got a message
> that the kernel needed a root parameter at boot time.  It seems that all
> my /dev/hda? drives have been renamed /dev/sda? so I set gave
> "root=/dev/sda4" as a kernel parameter and got a little further.

Yes.  The old IDE subsystem used hdX device names.  The newer libata based 
subsystem handles both PATA and SATA, using the traditionally SCSI device 
names of sdX instead of the traditionally IDE names of hdX.

Of course, that's years'-old news by now, for anyone taking the "rolling" 
in rolling update at anything close to face value...  Seriously.  If you 
/are/ going to let things get that outdated, I'd recommend something like 
CentOS.  At least there, such big updates so far apart are semi-standard, 
and thus, both the distribution itself and its community are better 
equipped to handle them.  

Gentoo, OTOH, is a /rolling/ /update/ distribution.  They actually find it 
necessary to warn people not to (routinely) sync more than once a day, and 
updating daily to perhaps at the outside monthly, really is how it works 
best.  I believe you've seen this "sermon" before so I'll keep it short, 
but honestly, I'm not just saying this, if you're not going to go rolling 
update with it, and rolling update is NOT for everybody, you really
/should/ reevaluate whether Gentoo is the really the best matching choice 
for your needs.  An "impedance mismatch" of that magnitude may be possible 
to work around, but just because it's possible doesn't mean it's the most 
efficient choice available, for sure.

(The two following paragraphs are recent personal experience with an
8-month-out update.  Skip if you wish...

FWIW, I just upgraded my netbook from about 8 months out, kde 4.4.5, 
skipping 4.5 entirely, to 4.6.1.  I was able to do it because I understand 
reasonably well both the kernel and the Gentoo distribution as well as the 
hardware, following developments quite closely even when I'm not actually 
updating, AND because I kept the usual incremental rolling updates on my 
workstation during the period, so I'd done all except the hardware-
specific updates before, just not all at once, but I'll tell you what, I'd 
have a whole lot rather kept it updated at least every 2-3 months maximum. 

... Further, while it's probably fair to say it was easier for me to do 
the 8-month update than to backup /etc, /home and the kernel config, and 
start from a clean stage-3 tarball, it wasn't so by much, and for people 
who don't keep such close track of Gentoo and Linux developments in 
general and/or who hadn't been regularly updating other systems so as to 
have gone thru most of the updates already, just not all at once, starting 
from that clean stage-3 probably would have been easier!  And I can say 
that as I recently helped a friend install from a stage-3, too, so I've 
done both recently.  Thus, I now have personal experience to confirm what 
has been previously stated in other threads, that a six-month update is 
approaching the outer limits of practicality for an ordinary Gentooer, and 
that somewhere between that six months and a year, installing from a fresh 
stage-3 does become the most practical option.)

> After
> "Checking root filesystem" in the boot sequence, I got a message that
> the UUID for the root filesystem wasn't understood in /etc/fstab.

> So I set the root filesystem in /etc/fstab to /dev/sda4, and got the
> same error - that "/dev/sda4" was not understood either, although the
> kernel seemed to understand this just fine as a boot parameter, and once
> again, I'm dumped into a very limited single-user mode.
> So I'm stuck!  I had to boot from a rescue disk, back-version to
> udev-141 and revert to kernel 2.6.23-gentoo-r3 to get my desktop back.
> What do I need to put into /etc/fstab to satisfy the kernel?  I need to
> move forward with this, but I need my desktop system to run my business.
> Any _real_ suggestions will be welcome.  Please be aware that I'm no
> Linux novice, so don't give me novice advice.  I've been building,
> running, and getting paid to admin Linux systems since 1995.

Do you run an initrd/initramfs?  (AFAIK you do if you use genkernel, since 
it pretty much compiles everything as modules, putting what it thinks 
necessary to load the real-root in the initrd/initramfs.)

I'll skip the detail on init(rd|ramfs) both because I don't use it myself 
and because as you mention, you /aren't/ a novice, so if you do use one, 
you can probably tell me more about how it works than I can tell you, but..


1)  it's loading the kernel and dropping you in the initrd/initramfs, 
because it can't load real-root,


2) It's loading root initially (either you don't have an initrd/initramfs 
or it gets past that), which normally defaults to read-only mode, and is 
failing when it tries to do the initial rootfs fsck and/or when it tries 
to do the remount read/write, which occurs just after that.

In either case, since you specifically mention that you get a limited 
single-user-mode, NOT a kernel panic as it tries to read the initial root 
(whether that's an initrd/initramfs or the real root), the kernel 
definitely DOES know how to read and mount that initial root and drop you 
into /some/ sort of user mode, even if limited single-user.

(It's worth noting here that one of the issues I experienced with that
8-month update above, was that somehow, when I updated the kernel from 
2.35-rc6-gitsomething, what I'd been running before, to 2.6.38, what I'm 
running now on both workstation and netbook, the config option for my SATA 
chipset vanished when I did make oldconfig, and my first kernel rebuild 
panicked when it couldn't find root.  I'm familiar enough with the 
kernel's boot messages and the hardware that I realized that it couldn't 
see sda at all, which meant either the hardware was dying and that didn't 
seem to be the case, or it wasn't loading the driver, so I deduced the 
problem almost immediately, and sure enough, when I checked the kernel 
config, it wasn't building that driver (I don't use modules, only the 
options I need, built-in), so change the option to build it, rebuild and 
install the kernel, and try again.  It worked once it had the driver for 
the sata controller, but the point is, I use all built-ins and no init(rd|
ramfs), so it kernel panicked before loading any userspace at all.)

If you do NOT use an initr*, the fact that it's loading even the single-
user userspace indicates that it not only properly loads the PATA driver 
and detects the hardware, but that it ALSO groks the rootfs and loads it 
read-only.  In that case, your problem really is one with fsck/mount/fstab 
or the scripts that invoke them.

OTOH, if you DO use an initr*, the first thing to determine is whether 
it's getting past that and dropping you into the real-root, in which case 
you have the same as above fsck/mount/fstab or script issues to look at, 
*OR*, whether you're getting dropped into that limited userspace while 
it's still initr*-based-only, in which case your problem is with the 
initr*, NOT with the real-root that the system later pivot-root-s to.

Given the info you posted, I'll predict that the most likely case, and I 
state this again with the caveat that I don't use initr* personally so 
don't know that much about it, is that you DO use an initr*, and are stuck 
in it, as it either doesn't have the correct kernel PATA driver and thus 
can't see the drive at all, or it has that but is missing the correct 
filesystem module, so it sees the drive but can't understand the 
filesystem you're pointing it at.

From what I've /read/ about initr*, back when initrds were the norm, the 
most common problem here was that either the updated kernel entry line 
still pointed at the old initrd, or that the initrd hadn't been updated at 
all.  In either case, the actually loaded initrd had the modules for the 
old kernel, which the new kernel would refuse to load.

Initramfs made that problem much less common as the initramfs is now 
appended to the end of the kernel file making it far more difficult to 
have a kernel/initr* mismatch, but the same effect sometimes happens, if 
the new kernel build doesn't build the appropriate modules or for whatever 
reason they're not included in the initramfs.

But beyond that you'll need to find someone with more initr* knowledge to 
help if it's an initr* issue, which I suspect it is.  It's a reasonably 
common problem, but one I have no experience with and don't know the 
details of the fix on.

If you're actually getting your real-root loaded, either because you don't 
use an initr* or because it's correct and you're successfully getting the 
pivot-root, then as I said, it would appear to be a problem with fsck, 
mount, fstab, or possibly the initscripts invoking them.  However, those 
are less common and there's not enough data in the original post to really 
go further with it at this point.

But I bet (and hope) it's an initr* problem... simply because those are 
most common, and normally easy to solve -- simply make sure you're loading 
the one corresponding to the new kernel and that it has the correct 
drivers and config...

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Re: System problems
-- Lindsay Haisley
System problems
-- Lindsay Haisley
Lists: gentoo-desktop: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: System problems
Next by thread:
Re: Re: System problems
Previous by date:
Re: System problems
Next by date:
Re: System problems

Updated Jun 28, 2012

Summary: Archive of the gentoo-desktop mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.