Bug 1474066 - Cannot deploy RHV ISO via PXE/kickstart
Summary: Cannot deploy RHV ISO via PXE/kickstart
Keywords:
Status: CLOSED DUPLICATE of bug 1435257
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: Documentation
Version: 4.1.4
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: rhev-docs@redhat.com
QA Contact: rhev-docs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-23 14:36 UTC by Rhys Oxenham
Modified: 2019-05-07 12:55 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-25 01:50:34 UTC
oVirt Team: Docs
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Rhys Oxenham 2017-07-23 14:36:34 UTC
Description of problem:

I currently cannot deploy RHV ISO via PXE/kickstart as per the documentation available here: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/installation_guide/advanced_rhvh_install

The main problem is that whilst the deployment appears to succeed, it doesn't install the bootloader. The anaconda text output suggests that it has installed it but the log files suggest otherwise.

Upon a reboot, the machine fails to boot up, claiming there's no operating system installed on the host. When investigating through rescue mode, the /boot partition (/dev/sda1) is created, but it has no contents.

Version-Release number of selected component (if applicable):

Tried with RHVH-4.1-20170616.0-RHVH-x86_64-dvd1.iso and RHVH-4.1-20170706.1-RHVH-x86_64-dvd1.iso, however only the former would actually boot to Anaconda. The latter would go into some form of ramdisk boot loop and would never get to Anaconda. So it's possible that this bug has already been fixed, but I can't verify with the latest code.

How reproducible:

Every time.


Steps to Reproduce:
1. Follow documentation to create PXE/kickstart server with RHV ISO

[root@pxe html]# cat rhv41.ks
liveimg --url=http://x.x.x.x/rhv41/LiveOS/squashfs.img
clearpart --all
autopart --type=thinp
timezone --utc America/New_York
rootpw --plaintext ovirt
zerombr
text

reboot

%post --erroronfail

nodectl init

%end

2. Leave it do its thing with kickstart, observing "successful" deployment
3. Watch it fail to boot into grub

Actual results:

grub2 is not installed onto the disk as it cannot find an available kernel. Therefore the system cannot, and doesn't, boot up into the RHV ISO environment.

/tmp/anaconda.log suggests this...

"WARN: anaconda: no kernel was installed -- boot loader config unchanged"

with /mnt/sysimage/boot being empty (with exception of "lost+found").


Expected results:

grub2 is installed correctly onto the root disk, with an appropriate kernel, ramdisk, and grub2 configuration built in to support boot up of RHV image.

Additional info:

Comment 1 Rhys Oxenham 2017-07-23 15:21:30 UTC
Made some progress with this, it appears that the docs are wrong - it points you towards using /path/to/LiveOS/squashfs.img as the image to be used for installation of the RHVH image, but in fact the actual squashfs is located in Packages...

Packages/redhat-virtualization-host-image-update-4.1-20170706.0.el7_3.noarch.rpm

As per the kickstart example in the root of the image, the squashfs can be extracted from this rpm:

rpm2cpio /run/install/repo/Packages/redhat-virtualization-host-image-update*|cpio -ivd

Then, when this file is used instead with "liveimg --url=http://..." installation works perfectly. This is therefore a documentation issue for when setting up a PXE/kickstart installation.

Comment 2 Lucy Bopf 2017-07-25 01:50:34 UTC
Thanks for reporting, Rhys. We're actually discussing the same thing in bug 1447713, so I'm going to close this one as a duplicate.

Feel free to leave any additional comments on the other bug.

*** This bug has been marked as a duplicate of bug 1447713 ***

Comment 3 Lucy Bopf 2017-07-25 01:51:54 UTC
(In reply to Lucy Bopf from comment #2)
> Thanks for reporting, Rhys. We're actually discussing the same thing in bug
> 1447713, so I'm going to close this one as a duplicate.
> 
> Feel free to leave any additional comments on the other bug.
> 
> *** This bug has been marked as a duplicate of bug 1447713 ***

Apologies, wrong bug. The correct ID is bug 1435257.

*** This bug has been marked as a duplicate of bug 1435257 ***


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