Gentoo Archives: gentoo-desktop

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-desktop@l.g.o
Subject: [gentoo-desktop] Re: System problems
Date: Sun, 20 Mar 2011 09:34:23
Message-Id: pan.2011.03.20.09.32.22@cox.net
In Reply to: [gentoo-desktop] System problems by Lindsay Haisley
1 Lindsay Haisley posted on Sat, 19 Mar 2011 23:46:06 -0500 as excerpted:
2
3 > I'm caught between a rock and a hard place.
4 >
5 > I've been running this desktop box using kernel 2.6.23-gentoo-r3 and
6 > have come to the point at which there are too many dependencies and
7 > reverse dependencies, so I _have_ to upgrade to kernel 2.6.29-gentoo-r5
8 > and have been unable to bring the system up in the new kernel. Here's
9 > what's happening.
10
11 You're still running 2.6.23 on a /desktop/? I can see how it could be
12 argued for a server that had /years/ of uptime, but for a desktop... I
13 /really/ think you should upgrade a bit more often (as it would seem
14 you're unfortunately finding out)...
15
16 > The newer kernel requires a newer version of udev, which I emerged. The
17 > system came up with a root device of some sort mounted, I think in
18 > single-user mode, but couldn't mount other devices.
19 >
20 > So I changed the main drive designations to UUID's in /etc/fstab,
21 > re-emerged the newer udev, and tried again. This time I got a message
22 > that the kernel needed a root parameter at boot time. It seems that all
23 > my /dev/hda? drives have been renamed /dev/sda? so I set gave
24 > "root=/dev/sda4" as a kernel parameter and got a little further.
25
26 Yes. The old IDE subsystem used hdX device names. The newer libata based
27 subsystem handles both PATA and SATA, using the traditionally SCSI device
28 names of sdX instead of the traditionally IDE names of hdX.
29
30 Of course, that's years'-old news by now, for anyone taking the "rolling"
31 in rolling update at anything close to face value... Seriously. If you
32 /are/ going to let things get that outdated, I'd recommend something like
33 CentOS. At least there, such big updates so far apart are semi-standard,
34 and thus, both the distribution itself and its community are better
35 equipped to handle them.
36
37 Gentoo, OTOH, is a /rolling/ /update/ distribution. They actually find it
38 necessary to warn people not to (routinely) sync more than once a day, and
39 updating daily to perhaps at the outside monthly, really is how it works
40 best. I believe you've seen this "sermon" before so I'll keep it short,
41 but honestly, I'm not just saying this, if you're not going to go rolling
42 update with it, and rolling update is NOT for everybody, you really
43 /should/ reevaluate whether Gentoo is the really the best matching choice
44 for your needs. An "impedance mismatch" of that magnitude may be possible
45 to work around, but just because it's possible doesn't mean it's the most
46 efficient choice available, for sure.
47
48 (The two following paragraphs are recent personal experience with an
49 8-month-out update. Skip if you wish...
50
51 FWIW, I just upgraded my netbook from about 8 months out, kde 4.4.5,
52 skipping 4.5 entirely, to 4.6.1. I was able to do it because I understand
53 reasonably well both the kernel and the Gentoo distribution as well as the
54 hardware, following developments quite closely even when I'm not actually
55 updating, AND because I kept the usual incremental rolling updates on my
56 workstation during the period, so I'd done all except the hardware-
57 specific updates before, just not all at once, but I'll tell you what, I'd
58 have a whole lot rather kept it updated at least every 2-3 months maximum.
59
60 ... Further, while it's probably fair to say it was easier for me to do
61 the 8-month update than to backup /etc, /home and the kernel config, and
62 start from a clean stage-3 tarball, it wasn't so by much, and for people
63 who don't keep such close track of Gentoo and Linux developments in
64 general and/or who hadn't been regularly updating other systems so as to
65 have gone thru most of the updates already, just not all at once, starting
66 from that clean stage-3 probably would have been easier! And I can say
67 that as I recently helped a friend install from a stage-3, too, so I've
68 done both recently. Thus, I now have personal experience to confirm what
69 has been previously stated in other threads, that a six-month update is
70 approaching the outer limits of practicality for an ordinary Gentooer, and
71 that somewhere between that six months and a year, installing from a fresh
72 stage-3 does become the most practical option.)
73
74 > After
75 > "Checking root filesystem" in the boot sequence, I got a message that
76 > the UUID for the root filesystem wasn't understood in /etc/fstab.
77
78 > So I set the root filesystem in /etc/fstab to /dev/sda4, and got the
79 > same error - that "/dev/sda4" was not understood either, although the
80 > kernel seemed to understand this just fine as a boot parameter, and once
81 > again, I'm dumped into a very limited single-user mode.
82 >
83 > So I'm stuck! I had to boot from a rescue disk, back-version to
84 > udev-141 and revert to kernel 2.6.23-gentoo-r3 to get my desktop back.
85 >
86 > What do I need to put into /etc/fstab to satisfy the kernel? I need to
87 > move forward with this, but I need my desktop system to run my business.
88 > Any _real_ suggestions will be welcome. Please be aware that I'm no
89 > Linux novice, so don't give me novice advice. I've been building,
90 > running, and getting paid to admin Linux systems since 1995.
91
92 Do you run an initrd/initramfs? (AFAIK you do if you use genkernel, since
93 it pretty much compiles everything as modules, putting what it thinks
94 necessary to load the real-root in the initrd/initramfs.)
95
96 I'll skip the detail on init(rd|ramfs) both because I don't use it myself
97 and because as you mention, you /aren't/ a novice, so if you do use one,
98 you can probably tell me more about how it works than I can tell you, but..
99
100 Either...
101
102 1) it's loading the kernel and dropping you in the initrd/initramfs,
103 because it can't load real-root,
104
105 OR
106
107 2) It's loading root initially (either you don't have an initrd/initramfs
108 or it gets past that), which normally defaults to read-only mode, and is
109 failing when it tries to do the initial rootfs fsck and/or when it tries
110 to do the remount read/write, which occurs just after that.
111
112 In either case, since you specifically mention that you get a limited
113 single-user-mode, NOT a kernel panic as it tries to read the initial root
114 (whether that's an initrd/initramfs or the real root), the kernel
115 definitely DOES know how to read and mount that initial root and drop you
116 into /some/ sort of user mode, even if limited single-user.
117
118 (It's worth noting here that one of the issues I experienced with that
119 8-month update above, was that somehow, when I updated the kernel from
120 2.35-rc6-gitsomething, what I'd been running before, to 2.6.38, what I'm
121 running now on both workstation and netbook, the config option for my SATA
122 chipset vanished when I did make oldconfig, and my first kernel rebuild
123 panicked when it couldn't find root. I'm familiar enough with the
124 kernel's boot messages and the hardware that I realized that it couldn't
125 see sda at all, which meant either the hardware was dying and that didn't
126 seem to be the case, or it wasn't loading the driver, so I deduced the
127 problem almost immediately, and sure enough, when I checked the kernel
128 config, it wasn't building that driver (I don't use modules, only the
129 options I need, built-in), so change the option to build it, rebuild and
130 install the kernel, and try again. It worked once it had the driver for
131 the sata controller, but the point is, I use all built-ins and no init(rd|
132 ramfs), so it kernel panicked before loading any userspace at all.)
133
134 If you do NOT use an initr*, the fact that it's loading even the single-
135 user userspace indicates that it not only properly loads the PATA driver
136 and detects the hardware, but that it ALSO groks the rootfs and loads it
137 read-only. In that case, your problem really is one with fsck/mount/fstab
138 or the scripts that invoke them.
139
140 OTOH, if you DO use an initr*, the first thing to determine is whether
141 it's getting past that and dropping you into the real-root, in which case
142 you have the same as above fsck/mount/fstab or script issues to look at,
143 *OR*, whether you're getting dropped into that limited userspace while
144 it's still initr*-based-only, in which case your problem is with the
145 initr*, NOT with the real-root that the system later pivot-root-s to.
146
147 Given the info you posted, I'll predict that the most likely case, and I
148 state this again with the caveat that I don't use initr* personally so
149 don't know that much about it, is that you DO use an initr*, and are stuck
150 in it, as it either doesn't have the correct kernel PATA driver and thus
151 can't see the drive at all, or it has that but is missing the correct
152 filesystem module, so it sees the drive but can't understand the
153 filesystem you're pointing it at.
154
155 From what I've /read/ about initr*, back when initrds were the norm, the
156 most common problem here was that either the updated kernel entry line
157 still pointed at the old initrd, or that the initrd hadn't been updated at
158 all. In either case, the actually loaded initrd had the modules for the
159 old kernel, which the new kernel would refuse to load.
160
161 Initramfs made that problem much less common as the initramfs is now
162 appended to the end of the kernel file making it far more difficult to
163 have a kernel/initr* mismatch, but the same effect sometimes happens, if
164 the new kernel build doesn't build the appropriate modules or for whatever
165 reason they're not included in the initramfs.
166
167 But beyond that you'll need to find someone with more initr* knowledge to
168 help if it's an initr* issue, which I suspect it is. It's a reasonably
169 common problem, but one I have no experience with and don't know the
170 details of the fix on.
171
172 If you're actually getting your real-root loaded, either because you don't
173 use an initr* or because it's correct and you're successfully getting the
174 pivot-root, then as I said, it would appear to be a problem with fsck,
175 mount, fstab, or possibly the initscripts invoking them. However, those
176 are less common and there's not enough data in the original post to really
177 go further with it at this point.
178
179 But I bet (and hope) it's an initr* problem... simply because those are
180 most common, and normally easy to solve -- simply make sure you're loading
181 the one corresponding to the new kernel and that it has the correct
182 drivers and config...
183
184 --
185 Duncan - List replies preferred. No HTML msgs.
186 "Every nonfree program has a lord, a master --
187 and if you use the program, he is your master." Richard Stallman

Replies

Subject Author
Re: [gentoo-desktop] Re: System problems Lindsay Haisley <fmouse-gentoo@×××.com>