Re: [gentoo-user] Re: I guess it is time to update udev from 171-r10 to 197-r8...
On 18/03/2013 12:14, Tanstaafl wrote: > On 2013-03-18 4:18 AM, (Nuno Silva) 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
Re: [gentoo-user] Re: I guess it is time to update udev from 171-r10 to 197-r8...
On 2013-03-18 4:18 AM, (Nuno Silva) 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... Thanks, Charles
[gentoo-user] Re: I guess it is time to update udev from 171-r10 to 197-r8...
On 2013-03-17, Tanstaafl wrote:
> On 2013-03-17 2:17 PM, Neil Bothwick wrote:
>> On Sun, 17 Mar 2013 13:46:39 -0400, Tanstaafl wrote:
>>
>>> Also, should I manually fix the blockers:
>>>
[blocks B ] sys-apps/module-init-tools
("sys-apps/module-init-tools" is blocking sys-apps/kmod-12-r1)
[blocks B ] sys-apps/kmod ("sys-apps/kmod" is blocking
sys-apps/module-init-tools-3.16-r2)
>>>
>>> by doing "emerge -C module-init-tools && emerge kmod" *before*
>>> upgrading udev?
>>
>> No, because that adds kmod to world. Just unmerge module-init-tools and
>> then emerge world, letting portage install what it needs
>
> 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.
--
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/
