Re: [gentoo-user] Re: udev-197: what to do -- S0LVED for ME as well ;-)
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
Re: [gentoo-user] Re: udev-197: what to do -- S0LVED
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/shmtmpfs 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/shmtmpfs 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
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/shmtmpfs 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/shmtmpfs 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
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/shmtmpfs nodev,nosuid,noexec 0 0
Same "mistake" as I mentioned a few days before ... the syntax seems to
have changed to:
tmpfs /dev/shmtmpfs 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
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
[gentoo-user] Re: udev-197: what to do -- S0LVED
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/
