Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1416216 - virt-install with local kickstart fails on RHEL 7.3
Summary: virt-install with local kickstart fails on RHEL 7.3
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-manager
Version: 7.3
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: virt-mgr-maint
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-24 21:50 UTC by Dan Yasny
Modified: 2020-06-11 13:14 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-25 16:11:59 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Dan Yasny 2017-01-24 21:50:59 UTC
//setting component to libvirt, since virt-install isn't an option for some reason


Description of problem:
Installing RHEL7.3 with virt-install using a local kickstart file fails:


anaconda 21.48.22.93-1 for Red Hat Enterprise Linux 7.3 started.
 * installation log files are stored in /tmp during the installation
 * shell is available on TTY2
 * when reporting a bug add logs from /tmp as separate text/plain attachments
21:39:49 Kickstart file /run/install/ks.cfg is missing.
Exception AttributeError: "'NoneType' object has no attribute 'udev_unref'" in <bound method Context.__del__ of <pyudev.core.Context object at 0x7fcee36495d0>> ignored

virt-install commands attempted:

virt-install --name undercloud --ram 16384 --disk path=/var/lib/libvirt/images/undercloud.qcow2,size=60 --vcpus 4 --os-type linux --os-variant rhel7 --graphics none --console pty,target_type=serial --location "http://download.eng.rdu2.redhat.com/pub/released/RHEL-7/7.3/Server/x86_64/os/" --noreboot --noautoconsole --extra-args "ks=ks.cfg console=ttyS0,115200n8 serial" --network network=provision,model=virtio,mac=00:11:22:33:44:00 --network network=public,model=virtio,mac=00:11:22:33:45:00

alternatively, with the same result:
--extra-args "ks=file:/path/to/ks.cfg"
--extra-args "inst.ks=file:/path/to/ks,cfg"

When I switch to --extra-args "ks=http://server/path/ks.cfg" everything works, installation goes through.

Additional attempt to use --initrd-inject=/path/to/local.ks --extra-args="ks=file:/local.ks" results in the install hanging with the following:
g dracut initqueue hook...
[    7.713549]  vda: vda1 vda2
[    7.779823] 8021q: adding VLAN 0 to HW filter on device eth0
[    6.980422] dracut-initqueue[621]: RTNETLINK answers: Network is unreachable





Pane is dead
Pane is dead


Version-Release number of selected component (if applicable):
virt-install-1.4.0-2.el7.noarch
libvirt-client-2.0.0-10.el7_3.4.x86_64
libvirt-daemon-2.0.0-10.el7_3.4.x86_64
libvirt-daemon-driver-interface-2.0.0-10.el7_3.4.x86_64
libvirt-daemon-driver-network-2.0.0-10.el7_3.4.x86_64
libvirt-daemon-driver-nodedev-2.0.0-10.el7_3.4.x86_64
libvirt-daemon-driver-secret-2.0.0-10.el7_3.4.x86_64
libvirt-daemon-driver-storage-2.0.0-10.el7_3.4.x86_64
libvirt-daemon-kvm-2.0.0-10.el7_3.4.x86_64
libvirt-python-2.0.0-2.el7.x86_64
libvirt-daemon-driver-nwfilter-2.0.0-10.el7_3.4.x86_64
libvirt-daemon-driver-qemu-2.0.0-10.el7_3.4.x86_64
libguestfs-1.32.7-3.el7_3.2.x86_64
libguestfs-tools-1.32.7-3.el7_3.2.noarch
libguestfs-tools-c-1.32.7-3.el7_3.2.x86_64


How reproducible:
always

Steps to Reproduce:
1. install VM as described above on rhel7.3
2.
3.

Actual results:
install fails or hangs

Expected results:
install should go through and complete

Additional info:

Comment 1 Pavel Hrdina 2017-01-25 08:57:46 UTC
(In reply to Dan Yasny from comment #0)
> //setting component to libvirt, since virt-install isn't an option for some
> reason

No problem, virt-install is part of virt-manager component, I'll change it.

> Description of problem:
> Installing RHEL7.3 with virt-install using a local kickstart file fails:
> 
> 
> anaconda 21.48.22.93-1 for Red Hat Enterprise Linux 7.3 started.
>  * installation log files are stored in /tmp during the installation
>  * shell is available on TTY2
>  * when reporting a bug add logs from /tmp as separate text/plain attachments
> 21:39:49 Kickstart file /run/install/ks.cfg is missing.
> Exception AttributeError: "'NoneType' object has no attribute 'udev_unref'"
> in <bound method Context.__del__ of <pyudev.core.Context object at
> 0x7fcee36495d0>> ignored
> 
> virt-install commands attempted:
> 
> virt-install --name undercloud --ram 16384 --disk
> path=/var/lib/libvirt/images/undercloud.qcow2,size=60 --vcpus 4 --os-type
> linux --os-variant rhel7 --graphics none --console pty,target_type=serial
> --location
> "http://download.eng.rdu2.redhat.com/pub/released/RHEL-7/7.3/Server/x86_64/
> os/" --noreboot --noautoconsole --extra-args "ks=ks.cfg
> console=ttyS0,115200n8 serial" --network
> network=provision,model=virtio,mac=00:11:22:33:44:00 --network
> network=public,model=virtio,mac=00:11:22:33:45:00
> 
> alternatively, with the same result:
> --extra-args "ks=file:/path/to/ks.cfg"
> --extra-args "inst.ks=file:/path/to/ks,cfg"

If you want to use local file from your host you have to use --initrd-inject to provide the KS file to guest because guest is isolated from host.

> When I switch to --extra-args "ks=http://server/path/ks.cfg" everything
> works, installation goes through.
> 
> Additional attempt to use --initrd-inject=/path/to/local.ks
> --extra-args="ks=file:/local.ks" results in the install hanging with the
> following:

This is a correct way how to use local file as KS for guest and it works, I've just tested it.

> g dracut initqueue hook...
> [    7.713549]  vda: vda1 vda2
> [    7.779823] 8021q: adding VLAN 0 to HW filter on device eth0
> [    6.980422] dracut-initqueue[621]: RTNETLINK answers: Network is
> unreachable

This is most likely wrong configuration in the KS file or your networking, if the KS file is not properly injected into initrd you would see error like this:

"08:53:05 Kickstart file /run/install/ks.cfg is missing."

Please try this again with some simple KS and while adding more things into the KS try to figure out what breaks the network for you.  From the error message it seems that you are configuring VLAN so maybe try to focus on that.

This is probably just wrong configuration and not a bug, but I'll wait for your reply before closing it.

Comment 3 Dan Yasny 2017-01-25 14:27:44 UTC
Actually, I'm not configuring VLAN at all. I have two simple NAT networks defined and I am configuring the two NICs in kickstart, nothing else:
lang en_US
keyboard us
timezone America/New_York --isUtc
rootpw redhat
reboot
text
url --url http://download.eng.rdu2.redhat.com/pub/released/RHEL-7/7.3/Server/x86_64/os/
bootloader --location=mbr --append="rhgb quiet crashkernel=auto edd=off console=tty0 console=ttyS0,115200n8"
zerombr
clearpart --all --initlabel
autopart
network --device=eth0 --bootproto=static --ip=192.168.122.254 --netmask=255.255.255.0 --gateway=192.168.122.1 --nameserver=192.168.122.1
network --device=eth1 --bootproto=static --ip=192.168.123.254 --netmask=255.255.255.0 --gateway=192.168.123.1 --nameserver=192.168.122.1
auth --passalgo=sha512 --useshadow
selinux --enforcing
firewall --enabled --http --ftp --smtp --ssh
skipx
firstboot --disable
%packages
@base
acpid
prelink
libcgroup
ntp
x86info
libcgroup-tools
kernel-tools
-nano
%end
%post
cd /root
mkdir --mode=700 .ssh
cat >> .ssh/authorized_keys << "PUBLIC_KEY"
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC/s+V7X2JArsoK7cq5C7oigKRduOBHamC4ty9F7I7cyFXbNTlrH75hV13qsI346HVy6RsnIqvTdnwatq2yTtTxSC4mADDFQtk+42T6ok1Ty3MYHf9WQoLqAUdVaPbFo08sdMyNsezlD4INCPSAKDeDo27kIVxZsEB5xJ4p6ftDTz6DNuLan9KYdpPp3CS7XASVpxI/0JM6zDmrrs0+obfl1jqep95QoPONFAbnZ1RavZvwLQ7RpcMwfsHb6Ng1OSoakmsnyvSwmn774JLzmc6l8a8KRG73KGL8g0f60Z0G+qhIFUXGzHTGoMvJRwGrgX4E+vcXzD9XW/5utCrK2QKR root@sealusa5.mobius.lab.eng.rdu2.redhat.comPUBLIC_KEY
chmod 600 .ssh/authorized_keys
hostnamectl set-hostname undercloud.localdomain
useradd stack
echo stack|passwd stack --stdin
echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack
%end

Comment 4 Pavel Hrdina 2017-01-25 16:11:59 UTC
So this is the command line that should work (I've tested it and it works for me):

virt-install --name undercloud --ram 16384 --disk path=/var/lib/libvirt/images/undercloud.qcow2,size=60 --vcpus 4 --os-type linux --os-variant rhel7 --graphics none --console pty,target_type=serial --location "http://download.eng.rdu2.redhat.com/pub/released/RHEL-7/7.3/Server/x86_64/os/" --noreboot --noautoconsole --extra-args "ks=file:/ks.cfg console=ttyS0,115200n8 serial" --initrd-inject=/path/to/ks.cfg --network network=provision,model=virtio,mac=00:11:22:33:44:00 --network network=public,model=virtio,mac=00:11:22:33:45:00

the important part is to properly configure --extra-args "ks=file:/ks.cfg" and --initrd-inject=/path/to/ks.cfg.

If the installation hangs on network, make sure that the networking is properly configured in the KS file according to your needs <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/sect-kickstart-syntax.html>.

I'm closing this as NOTABUG because there is no issue in virt-install.

Comment 5 Dan Yasny 2017-01-25 16:14:56 UTC
Not reopening the BZ (yet) but how can you explain the fact that this very same kickstart works fine when provided from http and fails when used as a local file?

Comment 6 Pavel Hrdina 2017-01-25 17:39:59 UTC
Well, I'm not able to explain it, the only think that pops into my mind is that if you specify the kickstart file that it should be downloaded from HTTP the installer has to use some default network configuration to fetch the kickstart, but if the kickstart is provided as local file the network configuration is used directly from the kickstart (it doesn't have to use some default configuration to configure the network and download the kickstart file).

I don't know how dracut works and handles all those things so this is just an idea what you can look into.

One note: if the installation fails it should after some time falls to rescue terminal and you should be able to validate the network configuration and try whether the networking works.


Note You need to log in before you can comment on or make changes to this bug.