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 |