Bugzilla – Bug 843665
mkinitrd regression - during and after installation
Last modified: 2013-10-15 08:34:55 UTC
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 I noticed some odd behaviour with mkinitrd, so I took a closer look. During installation I always get an error from mkinitrd, most likely because I use lilo as a bootloader. I therefore switch to another console to run mkinitrd manually, just in case. So this is just before the completion of phase 1: taggart7:/ # mkinitrd Kernel image: /boot/vmlinuz-3.11.1-1.g1383321-pae Initrd image: /boot/initrd-3.11.1-1.g1383321-pae KMS drivers: xgifb Root device: /dev/disk/by-id/scsi-1494554000000000074616767617274370000000000000000-part1 (/dev/sda1) (mounted on / as ext4) Kernel Modules: thermal_sys thermal processor fan ata_piix ata_generic scsi_dh scsi_dh_alua scsi_dh_hp_sw scsi_dh_emc scsi_dh_rdac xgifb scsi_transport_iscsi libiscsi libiscsi_tcp iscsi_tcp usb-common usbcore ohci-hcd uhci-hcd ehci-hcd xhci-hcd usbhid hid-logitech-dj hid-generic hid-holtek-kbd hid-lenovo-tpkbd hid-ortek hid-roccat hid-roccat-common hid-roccat-arvo hid-roccat-isku hid-samsung af_packet pps_core ptp e1000e crc32c-intel uio cnic bnx2i cp: cannot stat ‘/sbin/iscsiuio’: No such file or directory Features: acpi kms block usb network iscsi After the system has completed phase 2 and is running normally, I did another mkinitrd: taggart7:/boot # mkinitrd Kernel image: /boot/vmlinuz-3.11.1-1.g1383321-pae Initrd image: /boot/initrd-3.11.1-1.g1383321-pae KMS drivers: xgifb Root device: /dev/disk/by-id/scsi-1494554000000000074616767617274370000000000000000-part1 (/dev/sda1) (mounted on / as ext4) Kernel Modules: thermal_sys thermal processor fan ata_piix ata_generic scsi_dh scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh_rdac xgifb scsi_transport_iscsi libiscsi libiscsi_tcp iscsi_tcp usb-common usbcore ohci-hcd uhci-hcd ehci-hcd xhci-hcd usbhid hid-logitech-dj hid-generic hid-holtek-kbd hid-lenovo-tpkbd hid-ortek hid-roccat hid-roccat-common hid-roccat-arvo hid-roccat-isku hid-samsung crc32c-intel uio cnic bnx2i cp: cannot stat ‘/sbin/iscsiuio’: No such file or directory Features: acpi kms block usb iscsi The difference seems to be that feature "network" isn't automatically selected in the 2nd example? Specifically, module 'e1000e', my network interface driver, isn't included. I also tried "mkinitrd -f network", which still does not include 'e1000e': # mkinitrd -f network Kernel image: /boot/vmlinuz-3.11.1-1.g1383321-pae Initrd image: /boot/initrd-3.11.1-1.g1383321-pae KMS drivers: xgifb Root device: /dev/disk/by-id/scsi-1494554000000000074616767617274370000000000000000-part1 (/dev/sda1) (mounted on / as ext4) Kernel Modules: thermal_sys thermal processor fan ata_piix ata_generic scsi_dh scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh_rdac xgifb scsi_transport_iscsi libiscsi libiscsi_tcp iscsi_tcp usb-common usbcore ohci-hcd uhci-hcd ehci-hcd xhci-hcd usbhid hid-logitech-dj hid-generic hid-holtek-kbd hid-lenovo-tpkbd hid-ortek hid-roccat hid-roccat-common hid-roccat-arvo hid-roccat-isku hid-samsung af_packet crc32c-intel uio cnic bnx2i cp: cannot stat ‘/sbin/iscsiuio’: No such file or directory Features: acpi kms block usb network iscsi Because module 'e1000e' is missing, this initrd won't work. For comparison, I checked a 12.3 system where mkinitrd behaves correctly: # mkinitrd Kernel image: /boot/vmlinuz-3.7.10-1.16-default Initrd image: /boot/initrd-3.7.10-1.16-default KMS drivers: xgifb Root device: /dev/disk/by-id/scsi-1494554000000000074616767617274340000000000000000-part1 (/dev/sda1) (mounted on / as jfs) Kernel Modules: thermal_sys thermal processor fan ata_piix pata_acpi ata_generic scsi_dh scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac jfs xgifb scsi_transport_iscsi libiscsi libiscsi_tcp iscsi_tcp usb-common usbcore ohci-hcd uhci-hcd ehci-hcd xhci-hcd usbhid hid-logitech-dj hid-generic af_packet e1000e crc32c-intel uio cnic bnx2i cp: cannot stat ‘/sbin/iscsiuio’: No such file or directory Features: acpi kms block usb network iscsi It automatically enables feature "network" and includes "e1000e". Reproducible: Always
Please attach the "bash -x mkinitrd &> mkinitrd.log.txt" output.
Created attachment 561209 [details] output from "bash -x mkinitrd"
I think the issue is here: ++ use_script /lib/mkinitrd/boot/12-network.sh This returns 1 because the variables are empty. So you need iscsi because the rootfilesystem is there.
Same issue here. Would copiing - on the same machine that is - the /lib/mkinitrd/boot/12-network.sh script from the 12.3 OS to the 13.1B1 solve the issue as a work around?
(In reply to comment #4) > Same issue here. Is it also "root on iscsi"? > Would copiing - on the same machine that is - the > /lib/mkinitrd/boot/12-network.sh script from the 12.3 OS to the 13.1B1 solve > the issue as a work around? Unlikely, network.sh has just the %if: condition which other scripts are supposed to fill if they require network.sh.
(in reply to comment #5) No, it has it has a /boot, / and /home partition on the same disk. So in that respect it's not the same setup as the OP. But I also have a mkinitrd which does not create a network interface (except for the lo-interface). This situation was created after downloading 13.1B1 (previous versions of 13.1 or factory on the same system did have a functional network). Is there anything - besides downloading and deploying a whole new install) that can be done to let mkinird create a functional network?
(In reply to comment #6) > Is there anything - besides downloading and deploying a whole new install) that > can be done to let mkinird create a functional network? mkinitrd does not create a network unless the root filesystem is on network. Appearently the network interfaces in the running system are not created properly. Please open a separate bug if thats indeed the case.
(In reply to comment #2) > Created an attachment (id=561209) [details] > output from "bash -x mkinitrd" I see one suspicous line in the log, which seem to prevent network from getting included: ++ '[' -d /sys/class/net/enp14s0/device ']' This is in /lib/mkinitrd/scripts/setup-network.sh around line 237. So what is enp14s0 anyway? Is it some broken driver? From the initial comment it seems e1000e has to be used.
(In reply to comment #8) > (In reply to comment #2) > > Created an attachment (id=561209) [details] [details] > > output from "bash -x mkinitrd" > > I see one suspicous line in the log, which seem to prevent network from getting > included: > > ++ '[' -d /sys/class/net/enp14s0/device ']' > > This is in /lib/mkinitrd/scripts/setup-network.sh around line 237. > > So what is enp14s0 anyway? Is it some broken driver? From the initial comment > it seems e1000e has to be used. enp13s0 and enp14s0 are the new names for eth0 and eth1, respectively. There is an issue (bug#820407) with the renaming due to an active interface, but I think that is independent of this.
(In reply to comment #9) > enp13s0 and enp14s0 are the new names for eth0 and eth1, respectively. There is > an issue (bug#820407) with the renaming due to an active interface, but I think > that is independent of this. Is the device symlink really not there? Was it there in 12.3?
(In reply to comment #10) > (In reply to comment #9) > > enp13s0 and enp14s0 are the new names for eth0 and eth1, respectively. There is > > an issue (bug#820407) with the renaming due to an active interface, but I think > > that is independent of this. > > Is the device symlink really not there? Was it there in 12.3? I found one system with e1000e, and /sys/class/net/*/device exits. So why is it missing on your system?
(In reply to comment #10) > (In reply to comment #9) > > enp13s0 and enp14s0 are the new names for eth0 and eth1, respectively. There is > > an issue (bug#820407) with the renaming due to an active interface, but I think > > that is independent of this. > > Is the device symlink really not there? Was it there in 12.3? On a freshly installed 13.1b1 system: # l /sys/class/net/enp14s0/device ls: cannot access /sys/class/net/enp14s0/device: No such file or directory # l /sys/class/net/*/device lrwxrwxrwx 1 root root 0 Oct 4 20:14 /sys/class/net/enp13s0/device -> ../../../0000:0d:00.0/ lrwxrwxrwx 1 root root 0 Oct 4 20:14 /sys/class/net/eth1/device -> ../../../0000:0e:00.0/ I guess bug#820407 is interfering after all - enp14s0 doesn't get properly renamed during startup. Still, shouldn't mkinitrd work with whatever devices the system has? Ah no, I guess mkinitrd takes the information from /etc/sysconfig/network/ which does list ifcfg-enp14s0.
(In reply to comment #7) Indeed is there no network device after upgrading to 13.1B1 and rebooting. ifconfig only gives the lo interface. I'll file a new bug.
(In reply to comment #8) > (In reply to comment #2) > So what is enp14s0 anyway? Is it some broken driver? From the initial comment > it seems e1000e has to be used. Olaf, there is nothing broken, this is the new network interface naming produced by udev.
(In reply to comment #12) > (In reply to comment #10) > > (In reply to comment #9) > > > enp13s0 and enp14s0 are the new names for eth0 and eth1, respectively. There is > > > an issue (bug#820407) with the renaming due to an active interface, but I think > > > that is independent of this. > > > > Is the device symlink really not there? Was it there in 12.3? > > On a freshly installed 13.1b1 system: > > # l /sys/class/net/enp14s0/device > ls: cannot access /sys/class/net/enp14s0/device: No such file or directory > > # l /sys/class/net/*/device > lrwxrwxrwx 1 root root 0 Oct 4 20:14 /sys/class/net/enp13s0/device -> > ../../../0000:0d:00.0/ > lrwxrwxrwx 1 root root 0 Oct 4 20:14 /sys/class/net/eth1/device -> > ../../../0000:0e:00.0/ > > I guess bug#820407 is interfering after all - enp14s0 doesn't get properly > renamed during startup. Still, shouldn't mkinitrd work with whatever devices > the system has? Ah no, I guess mkinitrd takes the information from > /etc/sysconfig/network/ which does list ifcfg-enp14s0. Maybe thats the case. In the end mkinitrd has to translate the entries in /sys/class/net/ to something in /etc/sysconfig/network/ifcfg-*.
this is another fallout from a new unfinished systemd feature. *** This bug has been marked as a duplicate of bug 820407 ***