1 |
Dale posted on Thu, 09 Sep 2010 21:16:49 -0500 as excerpted: |
2 |
|
3 |
> Lindsay Haisley wrote: |
4 |
>> I recently tried a badly needed kernel upgrade on my desktop system, |
5 |
>> moving from kernel 2.6.23-gentoo-r3 to kernel 2.6.29-gentoo-r5. |
6 |
|
7 |
I'll say! Even 2.6.29 is ancient. 2.6.35.4 is I believe the current |
8 |
release, and I'm running 2.6.36-rc3. (I run linus git directly, but he |
9 |
has been away at a conference and there haven't been any updates for some |
10 |
days, so current git is still the rc3 he put out before he left... unless |
11 |
he got back and did some commits today.) |
12 |
|
13 |
But I'm curious; why 2.6.29? 2.6.27 was a long-term-stable-support |
14 |
release, still currently supported tho likely not for a lot longer, unless |
15 |
someone else picks it up, as the maintainer says he's about done with it, |
16 |
while 2.6.29 was on a normal release support schedule, AFAIK, with stable |
17 |
updates for it ending probably sometime after the +2 release (2.6.29 +2 = |
18 |
2.6.31). |
19 |
|
20 |
2.6.32 is the current long-term-stable-support release. If I were running |
21 |
my kernels as long as you do, that's what I'd be upgrading to, because |
22 |
it'll be supported (and get security and bug patch support in further |
23 |
stable releases) for some time yet, not the 2.6.29 that's no longer |
24 |
upstream supported. |
25 |
|
26 |
I'd STRONGLY suggest you do whatever research you might wish to, to |
27 |
confirm what I just stated, and then then seriously consider 2.6.32. |
28 |
Either that, or go back to 2.6.27, because altho its support is about to |
29 |
end (again, unless someone else picks it up), it has been supported as a |
30 |
long-term-stable for quite some time now and has a lot more of the bugs |
31 |
worked out than 2.6.29 will ever get. |
32 |
|
33 |
>> This |
34 |
>> also required an upgrade of udev from 141 to 151-r4. When I rebooted |
35 |
>> the box there was no /dev/hda4 which is normally the root filesystem, |
36 |
>> and instead what was the root filesystem had a device name of, I |
37 |
>> believe, "rootfs" in the kernel mount table which had the same files. |
38 |
>> A number of other mounts were gone as well (there was no /dev/hda at |
39 |
>> all, which has several partitions). |
40 |
|
41 |
You were playing irresponsible gentoo sysadmin who wants to live on the |
42 |
edge and risk breaking stuff because you didn't read your ewarn summaries, |
43 |
weren't you? Especially with boot-critical packages like udev, and |
44 |
*ESPECIALLY* when you're upgrading that far, you **REALLY** **NEED** to |
45 |
read those messages. |
46 |
|
47 |
Excerpt from udev-151-r4.ebuild: |
48 |
|
49 |
if use old-hd-rules; then |
50 |
ewarn |
51 |
ewarn "old-hd-rules use flag is enabled" |
52 |
ewarn "This adds the removed rules for /dev/hd* devices" |
53 |
else |
54 |
ewarn |
55 |
ewarn "This version of udev no longer has use flag old-hd- |
56 |
rules enabled" |
57 |
ewarn "So all special rules for /dev/hd* devices are |
58 |
missing" |
59 |
fi |
60 |
ewarn "Please migrate to the new libata if you need these rules." |
61 |
ewarn "They will be completely removed on the next udev update." |
62 |
|
63 |
Neither did you check the USE flag changes that emerge --pretend or emerge |
64 |
--ask would have shown you. From equery uses =udev-151-r4: |
65 |
|
66 |
- - old-hd-rules : Install rules for /dev/hd* devices, removed upstream |
67 |
at udev-148 |
68 |
|
69 |
>> The boot-up stumbled to a halt at a maintenance mode prompt with the |
70 |
>> root filesystem mounted R/O and of course no gnome desktop. I could |
71 |
>> use mount -o remount,rw / to make the root filesystem RW, which allowed |
72 |
>> me to re-emerge an earlier version of udev and boot to the previous |
73 |
>> kernel, but I'm stuck with an aging kernel, and other tools depend on a |
74 |
>> kernel and udev upgrade so sooner or later I'm going to be just, plain, |
75 |
>> stuck :( |
76 |
|
77 |
What's it they say about naughty gentoo sysadmins who can't do responsible |
78 |
upgrades, checking their USE flag changes or AT LEAST the ewarn |
79 |
summaries? Oh, yeah, "If it breaks, you get to keep the pieces." Well, |
80 |
you didn't read either one, and not without surprise for something left |
81 |
that long, then upgraded irresponsibly, entirely heedless of any warnings |
82 |
or USE flag changes, it broke... |
83 |
|
84 |
Of course, it /is/ fixable. You won't be left with pieces that you can't |
85 |
put back together. =:^) |
86 |
|
87 |
>> The drive setup is a bit complex. The actual hard drive mounting |
88 |
>> (excluding things like proc, udev, devpts, etc.) look like: |
89 |
>> |
90 |
>> /dev/hda4 on / |
91 |
|
92 |
>> The underlying drives are SATA drives which show up as |
93 |
>> /dev/sd[a-d]1 in /dev. |
94 |
>> |
95 |
>> This setup must be maintained in a functional state across any kernel |
96 |
>> and udev upgrades. |
97 |
|
98 |
You said it, not me. It must be /maintained/. That's a responsibility. |
99 |
Gentoo can't do that for you, neither does it even try to. If you can't |
100 |
even read the warnings the gentoo devs spend their time on... <shrug> |
101 |
|
102 |
You also said it yourself. The devices are /dev/sd*, not /dev/hd*. The |
103 |
direct change to your fstab (and lvm and etc config, if necessary), then, |
104 |
should be pretty simple, a pretty much direct substitution: s/hd/sd/g |
105 |
(substitute, for hd, sd, globally). It's possible the [a-d] bit will |
106 |
change order, but I doubt it, as you've been depending on udev's hd rules |
107 |
for some time now, and I'm almost certain (without actually checking, one |
108 |
could check the udev ruleset if they wanted to be sure) they default to |
109 |
using the same device letter if possible. |
110 |
|
111 |
>> I've been careful to use the .config from the working kernel as the |
112 |
>> start for configuring a kernel for the newer kernel, using make |
113 |
>> oldconfig. |
114 |
>> |
115 |
>> Does anyone have any idea what's wrong here? Am I required in recent |
116 |
>> kernels to identify all physical drives in /etc/fstab (and anywhere |
117 |
>> else it matters) with a UUID instead of a /dev device name? I've |
118 |
>> wasted an entire day on this problem, which I can ill afford, but I |
119 |
>> have to get past this roadblock and get my kernel up-to-date. |
120 |
|
121 |
If you couldn't afford it, why did you crassly upgrade a boot-critical |
122 |
package and then reboot, without reading the ewarns, /especially/ when |
123 |
upgrading that far at once? Do you regularly play Russian Roulette as |
124 |
well? How many bullets do you load when you do? |
125 |
|
126 |
Come on! This isn't rocket science! You're using a rolling distribution; |
127 |
you let your packages get /years/ out of date, and then you upgrade boot- |
128 |
critical packages without either doing any research on what has changed in |
129 |
the mean time, or AT LEAST reading the warnings! What do you EXPECT to |
130 |
happen? Under such circumstances, I know what I'd expect. I'd expect a |
131 |
tough time getting back up and running, when the system broke because I'd |
132 |
effectively played Russian Roulette with my computer, with five bullets in |
133 |
a six-shooter! Gentoo can put the warnings in the ebuild and cause them |
134 |
to display, get mailed to you, whatever, depending on how you've |
135 |
configured it, but you can lead a horse to water but can't make him drink, |
136 |
and Gentoo can put the warnings there but can't make you read them. |
137 |
|
138 |
This is especially true when you already know that the drives are SATAs |
139 |
and appear as /dev/sd*, not /dev/hd*. There would be a /bit/ more excuse, |
140 |
if you'd just upgraded legacy PATA drives, as the they are now taken care |
141 |
of by libata as well by default, and switching from /dev/hd* to /dev/sd*. |
142 |
But you already knew your drives were /dev/sd*, so why /on/ /earth/ were |
143 |
you using /dev/hd* in your fstab, anyway? For the folks with PATA drives |
144 |
who have been living under rocks and in caves for several years now, |
145 |
there's at least /some/ explanation, since the switch to /dev/sd* could |
146 |
take them by surprise (again, if they've been living under a rock or in a |
147 |
cave, I'd not expect a responsible sysadmin who has been around to have |
148 |
missed that), but you... you knew your drives were /dev/sd* already? Why |
149 |
on /earth/ were you using /dev/hd* then? |
150 |
|
151 |
> I ran into this a few weeks ago. I to have the old IDE hard drives. I |
152 |
> had to switch to PATA which means my drives are now sd* instead of hd*. |
153 |
|
154 |
As I said, at least there's /some/ excuse with PATA/IDE. |
155 |
|
156 |
> I don't use LVM tho. I set LABELS on mine and use that to boot and |
157 |
> mount the partitions where that are supposed to mount. It worked pretty |
158 |
> well and since I'm using LABELS I can also boot the older kernels and |
159 |
> hopefully any future kernels that come out. |
160 |
|
161 |
Actually, that's the way I have mine setup now too, with labels. That |
162 |
way, it shouldn't matter if the partition is on /dev/hda, /dev/md3, /dev/ |
163 |
sdz, or something else, mount and the kernel should be able to figure it |
164 |
out. |
165 |
|
166 |
> I *think* LVM can use LABELS to. If so, that would be my suggestion. |
167 |
> That way you can move things around as needed and them still boot as |
168 |
> they still be able to find your partitions. |
169 |
|
170 |
Seconded. |
171 |
|
172 |
The one thing that can be a bit confusing then, however, especially with |
173 |
multiple layers such as mdraid, dmraid, lvm, etc, is keeping straight |
174 |
which devices are which, when maintenance using the device nodes instead |
175 |
of the labels is needed. |
176 |
|
177 |
> So far, I have not been able to get Grub to see the LABELS. I just |
178 |
> haven't been able to do much testing on it yet. |
179 |
|
180 |
AFAIK (and this is why I replied here, instead of directly to the above |
181 |
post), grub-1 (0.97-r*, called "legacy" and unsupported for years |
182 |
upstream, even well before grub2's on-disk format stabilized, in that |
183 |
regard they pulled a KDE, leaving the current actually working version |
184 |
without support, while the new version was still way broken, tho luckily |
185 |
in the grub case, the community was big enough that community patches have |
186 |
continued to sustain grub-legacy over the gap, adding new features like gpt |
187 |
partition support, ext4 filesystem support, etc, well after upstream |
188 |
abandoned their stable code but years before the new version was even |
189 |
generally usable, let alone production-ready) can't use labels. It's |
190 |
/possible/ grub2 might, but I don't know for sure as I've not upgraded to |
191 |
it yet. |
192 |
|
193 |
> If LVM can work with this, it should be backward compatible |
194 |
> with the kernels. |
195 |
|
196 |
I don't believe lvm works with labels directly, because labels are a |
197 |
file-system-level feature, and lvm is a below-file-system-level layer. |
198 |
Neither does mdraid (mdadm), for much the same reason. |
199 |
|
200 |
However, mdadm DOES allow device sequence change flexibility, because it |
201 |
puts MORE than enough data in its medadata headers to easily identify the |
202 |
mdraid devices on its own -- as long as you point it at the correct set of |
203 |
devices. (If no DEVICE line, what it uses to configure where it scans, is |
204 |
present, it scans devices listed in /proc/partitions, a sane default.) |
205 |
|
206 |
FWIW, I ran lvm for awhile, but decided that now that mdraid handles |
207 |
partitioned raid, there wasn't much need for it any longer, and what with |
208 |
lvm on mdraid (partitions) on raw disk partitions, the complexity both of |
209 |
keeping track of it all, AND of keeping enough of both the mdadm and lvm |
210 |
administration commands in my head to properly fix things if something |
211 |
went wrong... was getting dangerously high. As complex as it was, I was |
212 |
thus more likely to make a critical data-loss mistake. As such, I decided |
213 |
it was better to dump the lvm, and deal simply with partitioned RAID. |
214 |
Unfortunately, I've forgotten enough about lvm since then that I don't |
215 |
remember exactly what features it did have in this regard, but as I said, |
216 |
I doubt it has label support because labels are a file-system-level |
217 |
feature, and the filesystems go on lvm, not lvm on the filesystems. But I |
218 |
expect it DOES have UID and scanning support. |
219 |
|
220 |
FWIW2, as disks increase beyond the 2-T barrier, with legacy MBR style |
221 |
partitioning reaching its limits at 2-T, the newer GPT (GUID Partitioning |
222 |
Table, originally developed as part of EFI (Extensible Firmware Interface, |
223 |
think Apple and Intel), but backward compatible with BIOS based machines |
224 |
as well) is likely to take over. GPT has a number of advantages, |
225 |
including keeping redundant copies at each end of the disk and checksums |
226 |
for reliability and doing away with the primary/secondary/extended |
227 |
partition distinction, but ALSO including a partition-level label-type |
228 |
feature. Given that, as GPT becomes more common, it's very likely the |
229 |
various above-partition-below-filesystem level tools and systems, |
230 |
including mdraid/mdadm and lvm/devicemapper/dmraid, will grow support for |
231 |
partition labels as well. Until that point, however, the much less human |
232 |
readable UUID/GUID system is the closest it can get. |
233 |
|
234 |
BTW (or FWIW3, if you prefer), the whole idea behind udev is that it's now |
235 |
user customizable. You can make the devices show up either directly, or |
236 |
via symlink, as whatever name you want. If you want to name your hard |
237 |
drives after the planets, /dev/mercury instead of /dev/sda (or hda), |
238 |
followed by venus, earth, mars... instead of sdb, sdc, sdd... that's |
239 |
doable. |
240 |
|
241 |
It is of course also doable to find and save the old udev hd* |
242 |
compatibility rules, if you want, keeping them around for continued use. |
243 |
That's even easier than devising your own rules, since they're pre-made. |
244 |
Just find and save somewhere the file(s) that take care of that, before |
245 |
doing the upgrade. You can read about it in the udev manpage if you like, |
246 |
but the default rules location is /lib(64)?/udev/rules.d, so you'll |
247 |
probably find them there (tho there might be a helper script that you need |
248 |
to save as well), while the custom rules location is /etc/udev/rules.d, so |
249 |
that's where you should copy them too. |
250 |
|
251 |
Again, Gentoo has documentation on this, the udev guide. You can get as |
252 |
deeply into it, designing as complex a ruleset doing who knows what, as |
253 |
you want. As is normally the case with Gentoo, it's all up to you. But |
254 |
again, if you want to just do upgrades without reading any warnings or |
255 |
documentation, even when it's spit-out in ewarns in the upgrade itself, |
256 |
well, I suggest you go looking for a different distribution, because |
257 |
Gentoo wasn't designed as a babysitter, and really, there /are/ others |
258 |
that better fit that bill. |
259 |
|
260 |
-- |
261 |
Duncan - List replies preferred. No HTML msgs. |
262 |
"Every nonfree program has a lord, a master -- |
263 |
and if you use the program, he is your master." Richard Stallman |