[gentoo-user] udev-197: what to do

[gentoo-user] udev-197: what to do

[Allan Gottlieb]

I have read the news item and still have questions.  The news item
covers several points.

1. remove udev-postmount:
   I did this but worry that I now cannot reboot until I upgrade
   udev.  Is that correct?

2. Add CONFIG_DEVTMPFS=y.  Easy.  Kernel rebuilt and installed
   in /boot (but have not rebooted).

3. Predictable network interface names.
   I have the problematic udev rule.
   Specifically 70-persistent-net.rules has (on one line)

   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
   ATTR{address}=="00:1e:c9:48:f9:a0", ATTR{type}=="1",
   KERNEL=="eth*", NAME="eth0"

   I read the bug report, but it is not as clear as I would like.
   Is it true that I can change my file to simply

   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
   ATTR{address}=="00:1e:c9:48:f9:a0", ATTR{type}=="1",
   KERNEL=="eth*", NAME="net0"

   That is just change the NAME from eth0 to net0 ?

4. No support for kernels older than 2.6.39.  No problem.

5. Separate /usr not affected.  Good.

The news item does not mention the problem of moving files
from /usr/lib/udev/rules.d to /lib/udev/rules.d.  Am I correct in
believing that we still need one of the equivalents of
   equery belongs -n /usr/lib/udev | xargs emerge -pv

I used that successfully when one of my testing systems went to
udev-197.  I would think it is needed (before reboot) on my stable
systems as well so I am surprised it is not in the news item.

thanks,
allan

[gentoo-user] Re: udev-197: what to do

[walt]

On 01/26/2013 10:30 AM, Allan Gottlieb wrote:
> I have read the news item and still have questions.  The news item
> covers several points.
> 
> 1. remove udev-postmount:
>    I did this but worry that I now cannot reboot until I upgrade
>    udev.  Is that correct?

A reasonable question and I don't know the answer, but you can get
that file back by re-emerging your existing version of udev first.
You can always remove it later after everything is working okay,
which is what I did.

> 3. Predictable network interface names.
>    I have the problematic udev rule.
>    Specifically 70-persistent-net.rules has (on one line)
> 
>    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>    ATTR{address}=="00:1e:c9:48:f9:a0", ATTR{type}=="1",
>    KERNEL=="eth*", NAME="eth0"
> 
>    I read the bug report, but it is not as clear as I would like.
>    Is it true that I can change my file to simply
> 
>    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>    ATTR{address}=="00:1e:c9:48:f9:a0", ATTR{type}=="1",
>    KERNEL=="eth*", NAME="net0"
> 
>    That is just change the NAME from eth0 to net0 ?

I kept my persistent-net rules and I still have a working eth0. Am
I politically incorrect to run this way?  Dunno (and don't care ;)

> The news item does not mention the problem of moving files
> from /usr/lib/udev/rules.d to /lib/udev/rules.d.  Am I correct in
> believing that we still need one of the equivalents of
>    equery belongs -n /usr/lib/udev | xargs emerge -pv

Yes -- if you still have any files in /usr/lib/udev/rules.d you should
re-emerge those packages so they are re-installed in /lib/udev/rules.d
before rebooting.  At least, I know that's what I should have done :)

Re: [gentoo-user] udev-197: what to do

[Matthias Hanft]

Allan Gottlieb wrote:
> 
> 1. remove udev-postmount:
>    I did this but worry that I now cannot reboot until I upgrade
>    udev.  Is that correct?

Based on my experience, you just don't care about udev-postmount.
It will automagically be removed when you upgrade from udev-171
to udev-197.

-Matt

Re: [gentoo-user] udev-197: what to do

[Florian Philipp]

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

Am 26.01.2013 19:30, schrieb Allan Gottlieb:
> I have read the news item and still have questions.  The news item
> covers several points.
> 
> 1. remove udev-postmount:
>    I did this but worry that I now cannot reboot until I upgrade
>    udev.  Is that correct?
> 

It's a bit of a gamble but I guess the worst that could happen is that
you are dropped into a basic shell. Then it is easy to add
udev-postmount again and reboot.

> The news item does not mention the problem of moving files
> from /usr/lib/udev/rules.d to /lib/udev/rules.d.  Am I correct in
> believing that we still need one of the equivalents of
>    equery belongs -n /usr/lib/udev | xargs emerge -pv
> 
> I used that successfully when one of my testing systems went to
> udev-197.  I would think it is needed (before reboot) on my stable
> systems as well so I am surprised it is not in the news item.
> 

I wondered about this as well but at least on my systems, /usr/lib/udev
is already gone. I guess all packages were rev-bumped to fix it.
BTW: A fast way to express `equery belongs -n /usr/lib/udev | xargs
emerge -pv` is simply `emerge -pv1 /usr/lib/udev`

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] udev-197: what to do -- S0LVED

[Allan Gottlieb]

On Sat, Jan 26 2013, Allan Gottlieb wrote:

> I have read the news item and still have questions.  The news item
> covers several points.
>
> 1. remove udev-postmount:
>    I did this but worry that I now cannot reboot until I upgrade
>    udev.  Is that correct?
>
> 2. Add CONFIG_DEVTMPFS=y.  Easy.  Kernel rebuilt and installed
>    in /boot (but have not rebooted).
>
> 3. Predictable network interface names.
>    I have the problematic udev rule.
>    Specifically 70-persistent-net.rules has (on one line)
>
>    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>    ATTR{address}=="00:1e:c9:48:f9:a0", ATTR{type}=="1",
>    KERNEL=="eth*", NAME="eth0"
>
>    I read the bug report, but it is not as clear as I would like.
>    Is it true that I can change my file to simply
>
>    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>    ATTR{address}=="00:1e:c9:48:f9:a0", ATTR{type}=="1",
>    KERNEL=="eth*", NAME="net0"
>
>    That is just change the NAME from eth0 to net0 ?
>
> 4. No support for kernels older than 2.6.39.  No problem.
>
> 5. Separate /usr not affected.  Good.
>
> The news item does not mention the problem of moving files
> from /usr/lib/udev/rules.d to /lib/udev/rules.d.  Am I correct in
> believing that we still need one of the equivalents of
>    equery belongs -n /usr/lib/udev | xargs emerge -pv

Thanks for all the suggestions.  I did the following, which worked.

1. Built and installed kernel with CONFIG_DEVTMPFS=y

2. Moved udev-postmount back to /etc/init.d (I had moved it to /tmp).
   rc-update add udev-postmount default.
3. Reboot with new kernel (udev unchanged).  Success.

4. Changed NAME=eth0 to NAME=net0 in 70-persistent-net.rules and
   eliminated clauses so have only (on one line)
     SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1e:c9:48:f9:a0",
     NAME="net0"
   Corresponding changes to /etc/init.d /etc/runlevels/default

5. Emerge update world to get new udev (just -1 udev has blocks)

6. Change kernel configs as per udisks emerge output

7. /usr/lib/udev already empty (due to make world?) so nothing to do

8. Reboot with new kernel.  Success

allan

Re: [gentoo-user] udev-197: what to do -- S0LVED

[Stefan G. Weichinger]

Am 28.01.2013 00:00, schrieb Allan Gottlieb:

> Thanks for all the suggestions.  I did the following, which worked.
> 
> 1. Built and installed kernel with CONFIG_DEVTMPFS=y
> 
> 2. Moved udev-postmount back to /etc/init.d (I had moved it to /tmp).
>    rc-update add udev-postmount default.
> 3. Reboot with new kernel (udev unchanged).  Success.
> 
> 4. Changed NAME=eth0 to NAME=net0 in 70-persistent-net.rules and
>    eliminated clauses so have only (on one line)
>      SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1e:c9:48:f9:a0",
>      NAME="net0"
>    Corresponding changes to /etc/init.d /etc/runlevels/default
> 
> 5. Emerge update world to get new udev (just -1 udev has blocks)
> 
> 6. Change kernel configs as per udisks emerge output
> 
> 7. /usr/lib/udev already empty (due to make world?) so nothing to do
> 
> 8. Reboot with new kernel.  Success

As I prepare/consider to upgrade a remote gentoo server later this
evening I prefer to ask twice:

the running kernel 3.5.7 does not have CONFIG_DEVTMPFS=y

I built a new kernel (upgrading it to 3.6.11 btw) with CONFIG_DEVTMPFS=y
and plan to reboot the server at first.

After a hopefully correct reboot (can't access that server physically) I
plan to upgrade udev ... (I won't enable the new networking naming, btw).

Right now I upgrade lvm2 in advance as it doesn't pull in udev yet.

Pls comment or correct my plans ;-)  thanks, Stefan

[gentoo-user] Re: udev-197: what to do -- S0LVED

[Nuno Silva]

On 2013-02-15, Stefan G. Weichinger wrote:

> Am 28.01.2013 00:00, schrieb Allan Gottlieb:
>
>> Thanks for all the suggestions.  I did the following, which worked.
>> 
>> 1. Built and installed kernel with CONFIG_DEVTMPFS=y
>> 
>> 2. Moved udev-postmount back to /etc/init.d (I had moved it to /tmp).
>>    rc-update add udev-postmount default.
>> 3. Reboot with new kernel (udev unchanged).  Success.
>> 
>> 4. Changed NAME=eth0 to NAME=net0 in 70-persistent-net.rules and
>>    eliminated clauses so have only (on one line)
>>      SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1e:c9:48:f9:a0",
>>      NAME="net0"
>>    Corresponding changes to /etc/init.d /etc/runlevels/default
>> 
>> 5. Emerge update world to get new udev (just -1 udev has blocks)
>> 
>> 6. Change kernel configs as per udisks emerge output
>> 
>> 7. /usr/lib/udev already empty (due to make world?) so nothing to do
>> 
>> 8. Reboot with new kernel.  Success
>
> As I prepare/consider to upgrade a remote gentoo server later this
> evening I prefer to ask twice:
>
> the running kernel 3.5.7 does not have CONFIG_DEVTMPFS=y
>
> I built a new kernel (upgrading it to 3.6.11 btw) with CONFIG_DEVTMPFS=y
> and plan to reboot the server at first.
>
> After a hopefully correct reboot (can't access that server physically) I
> plan to upgrade udev ... (I won't enable the new networking naming, btw).

If you depend in the network device order in any way, and you used names
like the ones the kernel uses, you *have* to do something about the
network device naming.

For example, if you have eth0 and eth1 and you rely on eth0 being A and
eth1 B, you can't  do that anymore with plain udev, even if the rules
are still in place. eth0 may become B and eth1 A.

> Right now I upgrade lvm2 in advance as it doesn't pull in udev yet.
>
> Pls comment or correct my plans ;-)  thanks, Stefan
>
>
>

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: udev-197: what to do -- S0LVED

[Stefan G. Weichinger]

Am 15.02.2013 18:41, schrieb  (Nuno Silva):

> If you depend in the network device order in any way, and you used 
> names like the ones the kernel uses, you *have* to do something
> about the network device naming.
> 
> For example, if you have eth0 and eth1 and you rely on eth0 being A 
> and eth1 B, you can't  do that anymore with plain udev, even if the 
> rules are still in place. eth0 may become B and eth1 A.

No order needed as there is only one adapter in there:

# lspci  | grep net
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 01)

# cat /etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:21:85:62:4f:0b",
KERNEL=="eth*", NAME="eth0"

thanks, Stefan

Re: [gentoo-user] Re: udev-197: what to do -- S0LVED

[Stefan G. Weichinger]

Am 15.02.2013 18:45, schrieb Stefan G. Weichinger:
> Am 15.02.2013 18:41, schrieb  (Nuno Silva):
> 
>> If you depend in the network device order in any way, and you used 
>> names like the ones the kernel uses, you *have* to do something
>> about the network device naming.
>>
>> For example, if you have eth0 and eth1 and you rely on eth0 being A 
>> and eth1 B, you can't  do that anymore with plain udev, even if the 
>> rules are still in place. eth0 may become B and eth1 A.
> 
> No order needed as there is only one adapter in there:
> 
> # lspci  | grep net
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 01)
> 
> # cat /etc/udev/rules.d/70-persistent-net.rules
> # PCI device 0x10ec:0x8168 (r8169)
> SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:21:85:62:4f:0b",
> KERNEL=="eth*", NAME="eth0"

successful reboot done already:

 # cat /proc/version
Linux version 3.6.11-gentoo
# zgrep -i devtm /proc/config.gz
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

# mount | grep tmpfs
udev on /dev type devtmpfs
(rw,nosuid,relatime,size=10240k,nr_inodes=493463,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
cgroup_root on /sys/fs/cgroup type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)

I should edit /etc/fstab, I assume:

# grep tmpfs /etc/fstab
# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
shm	/dev/shm	tmpfs		nodev,nosuid,noexec	0 0

Same "mistake" as I mentioned a few days before ... the syntax seems to
have changed to:

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

Right?

---

So I might be ready to upgrade udev, correct?

*sigh*

;-)

Stefan

Re: [gentoo-user] Re: udev-197: what to do -- S0LVED

[Alex Schuster]

Stefan G. Weichinger writes:

>  # cat /proc/version
> Linux version 3.6.11-gentoo
> # zgrep -i devtm /proc/config.gz
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> 
> # mount | grep tmpfs
> udev on /dev type devtmpfs
> (rw,nosuid,relatime,size=10240k,nr_inodes=493463,mode=755)
> tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
> shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
> cgroup_root on /sys/fs/cgroup type tmpfs
> (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)
> 
> I should edit /etc/fstab, I assume:
> 
> # grep tmpfs /etc/fstab
> # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
> # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
> shm	/dev/shm	tmpfs nodev,nosuid,noexec	0 0

I still have this line in my fstab on one host...

> Same "mistake" as I mentioned a few days before ... the syntax seems to
> have changed to:
> 
> tmpfs     /dev/shm        tmpfs 	nodev,nosuid,noexec     0 0
> 
> Right?

... but I don't have it at all on another. /dev/shm is mounted just fine
though.
CONFIG_DEVTMPFS_MOUNT seems to be responsible for that, although the help
text says that it does not work when using an initramfs, which I do:

CONFIG_DEVTMPFS_MOUNT:

This will instruct the kernel to automatically mount the devtmpfs
filesystem at /dev, directly after the kernel has mounted the root
filesystem. The behavior can be overridden with the commandline parameter:
devtmpfs.mount=0|1.
This option does not affect initramfs based booting, here the devtmpfs
filesystem always needs to be mounted manually after the roots is mounted.
With this option enabled, it allows to bring up a system in rescue mode
with init=/bin/sh, even when the /dev directory on the rootfs is
completely empty.

	Alex

Re: [gentoo-user] Re: udev-197: what to do -- S0LVED

[Stefan G. Weichinger]

Am 15.02.2013 20:07, schrieb Alex Schuster:
> Stefan G. Weichinger writes:
> 
>>  # cat /proc/version
>> Linux version 3.6.11-gentoo
>> # zgrep -i devtm /proc/config.gz
>> CONFIG_DEVTMPFS=y
>> CONFIG_DEVTMPFS_MOUNT=y
>>
>> # mount | grep tmpfs
>> udev on /dev type devtmpfs
>> (rw,nosuid,relatime,size=10240k,nr_inodes=493463,mode=755)
>> tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
>> shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
>> cgroup_root on /sys/fs/cgroup type tmpfs
>> (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)
>>
>> I should edit /etc/fstab, I assume:
>>
>> # grep tmpfs /etc/fstab
>> # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
>> # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
>> shm	/dev/shm	tmpfs nodev,nosuid,noexec	0 0
> 
> I still have this line in my fstab on one host...
> 
>> Same "mistake" as I mentioned a few days before ... the syntax seems to
>> have changed to:
>>
>> tmpfs     /dev/shm        tmpfs 	nodev,nosuid,noexec     0 0
>>
>> Right?
> 
> ... but I don't have it at all on another. /dev/shm is mounted just fine
> though.
> CONFIG_DEVTMPFS_MOUNT seems to be responsible for that, although the help
> text says that it does not work when using an initramfs, which I do:
> 
> CONFIG_DEVTMPFS_MOUNT:
> 
> This will instruct the kernel to automatically mount the devtmpfs
> filesystem at /dev, directly after the kernel has mounted the root
> filesystem. The behavior can be overridden with the commandline parameter:
> devtmpfs.mount=0|1.
> This option does not affect initramfs based booting, here the devtmpfs
> filesystem always needs to be mounted manually after the roots is mounted.
> With this option enabled, it allows to bring up a system in rescue mode
> with init=/bin/sh, even when the /dev directory on the rootfs is
> completely empty.

I just keep that fstab-line for now ... thanks for your explanation!

Right now I already upgraded udev and I am currently rebuilding lvm2 and
libvirt (first one needed, 2nd one not important anymore on that box).

Should I restart udev before I reboot? For a test ... ?

# dmesg  | grep udevd

only shows version 171 right now ...

-

I was already able to test for the shiny new network name for the NIC:

# cat /root/bin/udev_testing.sh
#!/bin/bash
#network name testing

for i in /sys/class/net/*; do
  echo "==$i"
  udevadm test-builtin net_id "$i";
  echo
done 2>/dev/null

---->  enp2s0 instead of eth0

I don't really care about using that new naming ... doesn't matter to me
right now.

AFAI understand things won't change if I don't touch the udev-rules?

-

revdep-rebuild is through now ... no more /lib64/libudev.so.0 needed ...

Thanks, Stefan

Re: [gentoo-user] Re: udev-197: what to do -- S0LVED for ME as well ;-)

[Stefan G. Weichinger]

Am 15.02.2013 20:20, schrieb Stefan G. Weichinger:

> ---->  enp2s0 instead of eth0
> 
> I don't really care about using that new naming ... doesn't matter to me
> right now.
> 
> AFAI understand things won't change if I don't touch the udev-rules?

Bit the bullet and rebooted after checking and reading everything twice
at least.

Server came up fine again, udev-197-r4 running fine ... still with good
old eth0.

For me that is enough upgrading for today, especially on a remote box
like this ... new kernel, pam, lvm2, openrc, openssl, postfix etc etc
.... phew ...

Thanks for the help, I took lots of bits and bytes regarding this
upgrade from the various threads in this mailing list.

Regards, Stefan