Hide Forgot
Created attachment 839484 [details] Attaching screenshot Description of problem: Booting via PXELinux with standard RHEL6 options, PXELinux: default linux label linux kernel boot/RedHat-7.0-x86_64-vmlinuz append initrd=boot/RedHat-7.0-x86_64-initrd.img ks=http://foreman.virtual.lan/unattended/provision ks.device=bootif network ks.sendmac Kickstart: install url --url http://192.168.XXXXX/repos/rhel-everything-7.0-beta-1-x86_64-dvd/ lang en_US.UTF-8 selinux --permissive keyboard us skipx network --bootproto dhcp --hostname eln.virtual.lan rootpw --iscrypted $1$redhat$9yxjZIXXXXXXXhasqW/ firewall --service=ssh authconfig --useshadow --passalgo=sha256 --kickstart timezone UTC services --disabled autofs,gpm,sendmail,cups,iptables,ip6tables,auditd,arptables_jf,xfs,pcmcia,isdn,rawdevices,hpoj,bluetooth,openibd,avahi-daemon,avahi-dnsconfd,hidd,hplip,pcscd,restorecond,mcstrans,rhnsd,yum-updatesd repo --name="Extra Packages for Enterprise Linux" --mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64 bootloader --location=mbr --append="nofb quiet splash=quiet" zerombr clearpart --all --initlabel part / --fstype=ext4 --size=1024 --grow part swap --recommended text reboot The error message is: UnknownDeviceError: UnknownDeviceError('bootif', GError('GDBus.Error:org.freedesktop.NetworkManager.UnknownDevice: No device found for the requested iface.',)) I have seen other reports here, but it looks in this case I am not providing --device option in the network kickstart statement, therefore I'd expect this to work. I am using bootif, which is documented as a valid option of the ks.device (formerly ksdevice prior Fedora 17). Attaching screenshot, if needed I can upload ticket via customer portal.
Now this is interesting, I am booting via PXE without any special options and Anaconda does not start with the very same error. PXE Linux script: kernel boot/RedHat-7.0-x86_64-vmlinuz append initrd=boot/RedHat-7.0-x86_64-initrd.img ks=http://foreman.virtual.lan/unattended/provision Note there are NO special options there. Relevant part from my kickstart: network --bootproto dhcp --hostname eln.virtual.lan The same error message.
Seems to be an issue similar to bug #1023829. The behaviour in cases when --device specified in kickstart does not exist (ie using old eth0 instead of new systemd naming), or is not specified as in your case doesn't work as in rhel 6 currently. I'll investigate if we are able to use ks.device option in case of --device not specified in rhel7 flow (dracut + anaconda vs. loader + anaconda in rhel6), and if bootif value of ks.device works. When reporting a bug please attach the traceback log file (/tmp/anaconda-tb-*) or use bug reporting to bugzilla that should be offered by installer.
I wonder where the "network" option is targeted, it is not an anaconda boot option.
Okay, I was passing kernel parameters incorrectly, when I do not provide ksdevice=bootif, it works fine. It looks like we just need to properly document that this option value (bootif) is not supported now.
Reassigning so the docs team can update the install guide with regards to the information in comment #7.
Actually the whole ksdevice boot option is deprecated now. The entire chapter on boot options has been rewritten for RHEL 7 (see BZ#831512, and more importantly, see the attachment describing the options available). We'll add a section into the Installation Guide covering deprecated and removed options for RHEL7. Later this section might be moved into the Migration Planning Guide, but we'll keep it in the IG for now.
Hi Petr, Table 20.7. Automatic Interface Configuration Methods says: ksdevice=link Ignored (this is the same as the default behavior) This is not true, it is not ignored. If the "ksdevice=link" parameter is present, anaconda tries to find a network device with a link and activates this device.
(In reply to Jan Stodola from comment #16) > Hi Petr, > Table 20.7. Automatic Interface Configuration Methods says: > > ksdevice=link Ignored (this is the same as the default behavior) > > This is not true, it is not ignored. If the "ksdevice=link" parameter is > present, anaconda tries to find a network device with a link and activates > this device. Jan are you sure? I thought that ksdevice=link wrt choosing a device to be activated in initramfs is actually ignored (ie not a network device with link is activated but all network devices with link are activated). Another thing is using the ksdevice value for missing kickstart network --device option, where the first device with link found is actually used.
Radek, I tested this way: 1. create a kickstart on /boot partition: install cdrom lang en_US.UTF-8 keyboard us reboot text rootpw redhat timezone --utc America/New_York bootloader --location=mbr zerombr clearpart --all --initlabel autopart %packages @base %end 2. download installation kernel and initramdisk to /boot, modify grub.cfg, use following kernel boot parameters to start the installation: "ks=hd:sda1:/ks.cfg" 3. make sure that _no_ DVD is present in the drive (just to make sure the installation fails in initramfs) 4. restart the system and start the installation The installation fails as expected and networking is not running. Now restart the installation again and add the "ksdevice=link" boot parameter - the installation fails too, but the network device is configured with an IP address. Both installations fail in initramfs and the "ksdevice=link" parameter is obviously not ignored. Is my testing incorrect?
Hm, so currently adding ksdevice=link seems to be equivalent to rd.neednet, ie saying "activate network in initramfs", which without further network configuration (ip= argument) means activating of all devices (The same happens when the ksdevice is not present and network is needed in initramfs ... first row of the table). So I wonder what should we write in the doc then... not trivial to find something sensible and not misleading.
(In reply to Radek Vykydal from comment #19) > Hm, so currently adding ksdevice=link seems to be equivalent to rd.neednet, > ie saying "activate network in initramfs", which without further network > configuration (ip= argument) means activating of all devices (The same > happens when the ksdevice is not present and network is needed in initramfs > ... first row of the table). > > So I wonder what should we write in the doc then... not trivial to find > something sensible and not misleading. Well, ksdevice=link is the same thing as no ksdevice= at all, we could just say that, right? 'ksdevice=link: same as "not present"'
Not exactly. If the installation doesn't require network in initramfs, eg DVD install, with ksdevice=link network would be activated in initramfs while without ksdevice=link it would be not. So maybe let's say something along: same as "not present" but network will be activated in initramfs no matter it is actually needed (but this can be achieved by supported rd.neednet option).
Looks good to me, thanks.