|
Bugzilla – Full Text Bug Listing |
| Summary: | mkinitrd regression - during and after installation | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Per Jessen <per> |
| Component: | Basesystem | Assignee: | Olaf Hering <ohering> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | crrodriguez, j.reitsma, mmarek |
| Version: | 13.1 Beta 1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | output from "bash -x mkinitrd" | ||
|
Description
Per Jessen
2013-10-02 09:48:12 UTC
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 *** |