On 18/03/2013 12:14, Tanstaafl wrote: > On 2013-03-18 4:18 AM, (Nuno Silva) <nunojsi...@ist.utl.pt> wrote: >> On 2013-03-17, Tanstaafl wrote: >>> Ah, ok... but as for the rest... I should be able to safely upgrade >>> udev, with a reasonable (I know there are no guarantees) expectation >>> of everything 'just working' (ie, my lvm managed /usr partition >>> shouldn't be an issue like it would have been earlier on in this >>> process)? > >> From what I know (no LVM experience here), if you had it working with >> 171, it will work with a newer udev. There were no changes regarding how >> stuff from /usr is used between 171 and the newer udevs. > > Well, there were 'big scary warnings'(tm) a while back that screamed of > major breakage with the newer udevs for those poor lost souls who had > /usr on a separate partiton (lvm managed or not), then, at some later > point, I guess because of the 'wailing and gnashing of teeth'(tm), the > devs relented and changed things so that a separate /usr was supported > except under certain specific circumstances... but since I'm not a > programmer, I didn't (and still don't) understand most of it, hence my > asking for confirmation here... > > My system is fairly simple, all local storage, with only /usr, /var and > /home on separate lvm managed partitions (root is *not* on lvm)... > > So, I'm here asking if anyone who had waited (masked everything above > 171) has unmasked it and updated since, and whether or not they had any > problems booting afterwards...
No issues here. I have a variety of systems with different configs. I followed the elog and news messages: DEVTMPFS enable in kernel edit fs type for /dev IF listed in fstab Remove all those persistent-rules files remove udev-postmount from runlevels and every time it all worked out find. The one case I don't have is / in lvm or code in /usr needed at early-start time; I think that was the key thing and nicely side-stepped any possible lurking issues -- Alan McKinnon alan.mckin...@gmail.com
