[gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...

[gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...

[Tanstaafl]

Ok, I sync'd this morning, and now see the warning about udev 171-r10 
being masked, so I guess it is time..

I know this was discussed quite a bit a few months ago, but just to 
refresh my memory...

My question is, if I am currently running 171-r10 on my server, and I 
have a separate lvm managed /usr partition, is it now safe to comment 
out my udev masks and update udev, with a reasonable expectation that 
doing so won't break my boot ability?

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? Or does it matter?

Thanks...

Re: [gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

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.


-- 
Neil Bothwick

I don't know what makes you tick but I wish it was a time bomb.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...

[Tanstaafl]

On 2013-03-17 2:17 PM, Neil Bothwick <neil@digimed.co.uk> 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)?

Thanks Neil

Re: [gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

On Sun, 17 Mar 2013 14:33:50 -0400, 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)?

It worked for me on more than one machine, but that's no guarantee that
it will even work for me again, let alone for you.

It should work, and if it doesn't, at least you get to keep the pieces...


-- 
Neil Bothwick

New sig wanted good price paid.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: I guess it is time to update udev from 171-r10 to 197-r8...

[Nuno Silva]

On 2013-03-17, Tanstaafl wrote:

> On 2013-03-17 2:17 PM, Neil Bothwick <neil@digimed.co.uk> 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/

Re: [gentoo-user] Re: I guess it is time to update udev from 171-r10 to 197-r8...

[Tanstaafl]

On 2013-03-18 4:18 AM,  (Nuno Silva) <nunojsilva@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...

Thanks,

Charles

Re: [gentoo-user] Re: I guess it is time to update udev from 171-r10 to 197-r8...

[Alan McKinnon]

On 18/03/2013 12:14, Tanstaafl wrote:
> On 2013-03-18 4:18 AM,  (Nuno Silva) <nunojsilva@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.mckinnon@gmail.com

Re: [gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...

[Tanstaafl]

Ok, spent a little time re-reading the old threads about this...

Just to confirm, changes I should make in my /etc/fstab...

<snip> normal fs lines
 > # NOTE: The next line is critical for boot!
 > none       /proc           proc            defaults        0 0

I can/should simply delete the above two lines?

then

 > # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
 > # POSIX shared memory (shm_open, shm_unlink).
 > # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
 > #  use almost no memory if not populated with files)
 > shm       /dev/shm        tmpfs        nodev,nosuid,noexec     0 0

I should change the above line to:

 > tmpfs     /dev/shm        tmpfs        nodev,nosuid,noexec     0 0

Combined with the other recommended changes:

 > - Remove udev-postmount from runlevels.
 >
 > - Enable CONFIG_DEVTMPFS=y in the kernel;

I've also seen recommendation to enable:

CONFIG_DEVTMPFS_MOUNT=y ?

 > need to verify the fstype for possible /dev line in /etc/fstab is
 > devtmpfs (and not, for example, tmpfs)

I have no /dev line, and only one network adapter, so nothing to do here

 > - The case of separate /usr; if it worked for you with 171 it will
 >   continue to work for you with 197 (or newer). We still recommend
 >   initramfs with separate /usr mounting capabilities because you
 >   might need packages like sys-apps/kbd (keymaps in /usr) or
 >   net-wireless/bluez (possible keyboard) in early boot.

Ok, this one is unclear...

My system is currently indeed (and always has been) booting fine with a 
separate /usr (on lvm)... but...

The above reference to 'might need packages like sys-apps/kbd', which is 
now *required* by udev, suggests that now I again do need an initramsf?

Thanks for ya'lls patience. I have a feeling this is going to be another 
non-event, but I'd much prefer a little pre-update pain than a lot of 
post-update pain... ;)

Re: [gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

On Mon, 18 Mar 2013 07:15:39 -0400, Tanstaafl wrote:

> Thanks for ya'lls patience. I have a feeling this is going to be
> another non-event, but I'd much prefer a little pre-update pain than a
> lot of post-update pain... ;)

quickpkg udev before the update. Then if it all goes TU, you can boot from
a live disc and untar the package into your root directory.


-- 
Neil Bothwick

Remember that the Titanic was built by experts, and the Ark by a newbie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] I guess it is time to update udev from 171-r10 to 197-r8...

[Tanstaafl]

On 2013-03-18 7:15 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> The above reference to 'might need packages like sys-apps/kbd', which is
> now *required* by udev, suggests that now I again do need an initramsf?

That was silly - I saw kbd and read it as kmod... ok, this one is no 
problem either...

One new concern - I just confirmed that I do *not* have CONFIG_DEVTMPFS 
enabled in my current running kernel. I also am running an older kernel 
that is no longer in portage (I know, I know), so I want to recompile my 
existing kernel and get it booting with the new/updated u dev before 
upgrading it (will do that immediately once the udev update is done).

I've never recompiled and replaced a running kernel before, so...

I'm just going to recompile it with everything enabled, copy the new 
kernel over to /boot with a slightly different name, then reboot to the 
new kernel.

But looking at:

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7

It says to enable the following:

Device Drivers --->
   Generic Driver Options --->
     [*] Maintain a devtmpfs filesystem to mount at /dev
     [ ]   Automount devtmpfs at /dev, after the kernel mounted the rootfs
...
File systems --->
(Select one or more of the following options as needed by your system)
...
   Pseudo Filesystems --->
     [*] /proc file system support
     [*] Virtual memory file system support (former shm fs)
(In my current kernel the option is 'Tmpfs virtual memory file system 
support (former shm fs)
...
(Enable GPT partition label support if you used that previously)
-*- Enable the block layer --->
     ...
     Partition Types --->
     [*] Advanced partition selection
       ...
       [*] EFI GUID Partition support

Now, when exiting menuconfig I get the following warnings:

  # make menuconfig
scripts/kconfig/mconf Kconfig
warning: (HAVE_TEXT_POKE_SMP) selects STOP_MACHINE which has unmet 
direct dependencies (SMP && MODULE_UNLOAD || HOTPLUG_CPU)
warning: (HAVE_TEXT_POKE_SMP) selects STOP_MACHINE which has unmet 
direct dependencies (SMP && MODULE_UNLOAD || HOTPLUG_CPU)
#
# configuration written to .config

Is this something I need to fix?

Lastly, doing the actual updates once I have a supported kernel ready...

Neil suggested just unmerging module-init-tools and then letting emerge 
world install kmod, but I like doing things in smaller steps. An emerge 
world wants to update a number of other non udev related things (like 
apache), so what I'd like to do is get udev updated first, reboot, then 
finish updating world, so what I'm thinking of doing (after fixing my 
kernel issue) is:

emerge -C module-init-tools && emerge -1 kmod
then
emerge -C sysvinit && emerge -1 util-linux
then
emerge -vuDN udev
reboot
emerge -vuDN world

My question is, is the above any 'safer' than just doing:

emerge -C module-init-tools && emerge -C sysvinit && emerge -vuDN udev
reboot

?

Thanks