cannot create /etc/udev/rules.d/70-persistent-net.rules: Read-only file system

[whitewater]

Hello,
i made a fresh install of proxmox 4.2 ISO on a supermicro server, motherboard X9DR7-TF+.

Here is, in /var/log/syslog :

May 16 10:52:12 prox03 udev-finish[1374]: /lib/udev/udev-finish: 6: /lib/udev/udev-finish: cannot create /etc/udev/rules.d/70-persistent-net.rules: Read-only file system
May 16 10:52:12 prox03 systemd[1]: udev-finish.service: main process exited, code=exited, status=2/INVALIDARGUMENT
May 16 10:52:12 prox03 systemd[1]: Failed to start Copy rules generated while the root was ro.
May 16 10:52:12 prox03 systemd[1]: Unit udev-finish.service entered failed state.
May 16 10:52:12 prox03 lvm[1372]: 3 logical volume(s) in volume group "pve" now active
May 16 10:52:12 prox03 lvm[1423]: 3 logical volume(s) in volume group "pve" now active

No success, no file at /etc/udev/rules.d/rules.d/70-persistent-net.rules

So, like root filesystem is ro, udev create this file :
/run/udev/tmp-rules--70-persistent-net.rules, and networking respond some times after proxmox finish to boot.

i had made google research, without success. I have test this,
http://askubuntu.com/questions/614479/udev-cant-create-persistent-rules-read-only-file-system

i have done apt-get update && apt-get dist-upgrade.

root@prox03:~# pveversion -V
proxmox-ve: 4.2-49 (running kernel: 4.4.8-1-pve)
pve-manager: 4.2-4 (running version: 4.2-4/2660193c)
pve-kernel-4.4.6-1-pve: 4.4.6-48
pve-kernel-4.4.8-1-pve: 4.4.8-49
lvm2: 2.02.116-pve2
corosync-pve: 2.3.5-2
libqb0: 1.0-1
pve-cluster: 4.0-39
qemu-server: 4.0-74
pve-firmware: 1.1-8
libpve-common-perl: 4.0-60
libpve-access-control: 4.0-16
libpve-storage-perl: 4.0-50
pve-libspice-server1: 0.12.5-2
vncterm: 1.2-1
pve-qemu-kvm: 2.5-16
pve-container: 1.0-63
pve-firewall: 2.0-26
pve-ha-manager: 1.0-31
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u1
lxc-pve: 1.1.5-7
lxcfs: 2.0.0-pve2
cgmanager: 0.39-pve1
criu: 1.6.0-1
zfsutils: 0.6.5-pve9~jessie

So, what can i do to have a rw file system at boot for udev ?
thank you

 

[CTCcloud]

If you are simply trying to re-order the names of your Network Interface Cards, you can use SystemD directly to do this by using .link files

It's under /etc/systemd/network folder you'd create these

These files would be named something like 10-eth0.link and would contain something like the following:

[Match]
MACAddress=fe:54:cd:32:67:21

[Link]
Name=eth0

Alternatively, you could reinstall using Proxmox 4.1 ISO and then upgrade to 4.2 via APT which will bring along with it the working UDEV and that rules file you were mentioning.

I'm not sure if either of these methods would be the preferred choice by the Proxmox developer team but they both would work.

Hope this helps

 

[whitewater]

Hello, thanks ctcknows.
i have done the second solution, maybie more clean.
Install Promox 4.1 iso and apt-get update && apt-get distupgrade.

udev is ok now.

I have a another little problem.
I have this message at boot prompt :

a start job is running for lsb raise network interfaces

when proxmox finished to start and i login in, i haven't got network.
i must wait some second before.

and /var/log/dmesg is empty.

How i can correc this ?
thank you.

 

[CTCcloud]

Did you modify your 70-persistent-net.rules file?

If you modify that file it needs to stay in the same format that it was originally otherwise the OS has a hard time parsing the file and networking can be slow to come up or not come up at all.

 

[whitewater]

I only change the eth number to assign eth at the right card that i wanted, but that was before my changes also. No double eth<x> number in my file.

 

[CTCcloud]

Can you post the 70-persistent-net.rules file? You may find this all to be much cleaner if you use the SystemD method for changing NIC names as I mentioned earlier. I'm sure there is a reason the 70-persistent-net.rules file is gone in Proxmox 4.2 with a fresh install. The SystemD method is clean and also is latest technology whereas configuring via udev may be considered deprecated.

 

[whitewater]

Here is

# PCI device 0x8086:0x1521 (igb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="0c:c4:7a:51:91:97", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"

# PCI device 0x8086:0x1528 (ixgbe)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:90:82:bf:fd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x8086:0x1521 (igb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="0c:c4:7a:51:91:94", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

# PCI device 0x8086:0x1528 (ixgbe)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:90:82:bf:fc", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x1521 (igb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="0c:c4:7a:51:91:95", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x1521 (igb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="0c:c4:7a:51:91:96", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"

I did not know that systemd take over

 

[CTCcloud]

Looks perfect .... so at this point, you've upgraded to 4.2 and changed this file to re-order your NIC names? Nothing else changed?

I've noticed myself when re-ordering the NIC names using the udev method that there are delays in bringing up the interfaces during boot but once the system was up all was well and stayed fine ... the only issue was the delays in bringing up the NICs ... is that all your issue is? If that's your only issue, you may want to either just put up with it or use the SystemD method by putting the .link files in place under /etc/systemd/network which I've found doesn't cause any delays on boot on fresh 4.2 installs with no 70-persistent-net.rules file.

 

[whitewater]

Yes, Nothing else changed.
ok, i will test now systemD method.

Another issue, on every boot /var/log/dmesg is empty. Only this line in its content :

(Nothing has been logged yet.)

 

[CTCcloud]

I would post a bug report to bugzilla.proxmox.com about the /var/log/dmesg issue ... it may not be a bug but you'd find out fairly quick and they'd likely make comments about whether or not it has to do with SystemD and updated methods of logging or not

 

[whitewater]

as I don't know systemd files, i have created 6 files in /etc/systemd/network :
10-eth0.link, 11-eth1.link, 12-eth2.link, ..., like this for 10-eth0.link. No possibility to have 1 file for all eth ?

[Match]
MACAddress=00:25:90:82:bf:fc

[Link]
Name=eth0

of course, i had change Name=eth0 to Name=eth1 for 11-eth1.link, ... and same result :
"a start job is running for lsb raise network interfaces" message at boot and network not bringing up when i login in :-(
it is bringing up after around 30 sec

 

[CTCcloud]

I was having 5 to 10 minute delays with the 70-persistent-net.rules file so I consider 30 seconds to bring up the network reasonable (it's a server after all and once it's up stays up in production for very long periods of time). I read up on the .link files and didn't see a means of doing the renaming of all adapters in a single file ... I had thought the same thing, ...would be nice. Did you move the 70-persistent-net.rules file out of /etc/udev/rules.d ? If it's still there then it might be slowing down how fast your interfaces come up. If you still find it's taking too long to come up, then you will likely have to wait for one of the Proxmox staff to chime in on this thread to weigh in on the issue or submit a bug report on this as well.

 

[whitewater]

5 to 10 minutes is very long
i didn't move the 70-persistent-net.rules.
and, if i unplug an plug again a cable, it takes around 30 sec again to bringup.
I write it if it ever can help

Thank you very much for your help.
If maybie one of Proxmox team would like some tests, no problem.

 

[whitewater]

if interfaces aren't up when proxmox finish to boot, this will not prevent sending or receiving a quorum in a cluster to start the vm ?

 

[Manta]

I have the same issue here with a Supermicro Mainboard.
I burned down my Proxmox 3 Cluster to reinstall it with Version 4. I made a backup of the 70-persistent-net.rules file so I don't have to rewrite it for all six NIC's. But after reinstall the server with the 4.2 ISO I also got this:
"Failed to start Copy rules generated while the root was ro." in the log file.

I tried some to write the rules for systemd as ctcknows described but it didn't work. I was wondering why it worked in my lab envoirement.
I remember I installed with the 4.0 ISO so I reinstalled again with 4.0 ISO and then it worked like a charme. The 70-persistent-net.rules files is read and the interfaces are all up in the right order. And it's still working even after upgrading to 4.2!
Something has changed between the 4.0 ISO and the 4.2 ISO installer but what? Maybe somebody from the Proxmox Team knows something...???

 

[jdl]

Same here. Fresh/stock install of PVE 4.3.
Followed this link : http://askubuntu.com/questions/614479/udev-cant-create-persistent-rules-read-only-file-system, as said in the beginning of the thread , added basic.target before systemd-udevd.service systemd-udev-settle.service, it did the trick for me.