Bug 1415225 - RHVH 4.0 Anaconda installation blows up during post processing
Summary: RHVH 4.0 Anaconda installation blows up during post processing
Keywords:
Status: CLOSED DUPLICATE of bug 1357068
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: rhev-hypervisor-ng
Version: 4.0.6
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: Ryan Barry
QA Contact: Qin Yuan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-20 15:33 UTC by Greg Scott
Modified: 2017-02-07 09:14 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-07 09:14:51 UTC
oVirt Team: Node
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Anaconda.log attached (28.99 KB, text/plain)
2017-01-23 16:18 UTC, Greg Scott
no flags Details
Storage.log attached (255.33 KB, text/plain)
2017-01-23 16:18 UTC, Greg Scott
no flags Details

Description Greg Scott 2017-01-20 15:33:21 UTC
Description of problem:
When installing a new RHVH hypervisor, Anaconda blows up with, "There was an error running the kickstart script at line 9. This is a fatal error and installation will be aborted."  And then it presents a screen full of details, pasted in below.

Version-Release number of selected component (if applicable):
RHVH-4.0-20170104.0-RHVH-x86_64

How reproducible:
At will

Steps to Reproduce:
1. Boot the installation media from USB
2. Go through the Anaconda dialog as normal.
3. During the installation, set the root password.


Actual results:
The installation proceeds, it runs mkinitrd, then blows up with the kickstart error above.  See additional notes for details

Expected results:
The installation should run to completion without error.

Additional info:

I found a workaround - do not set the root password during installation.  Instead, let the initial installation portion finish.  Anaconda then pauses and prompts to set the root password.  Do it then, while Anaconda is paused.  Click the button to continue and it runs to completion.

I saved everything the system left in /tmp when it blew up.  Pasting in the log file with error message details below.

[root@storage2015 rhva2017]# more ks-script-O2QbVG.log
[INFO] Trying to create a manageable base from '/'
Traceback (most recent call last):
  File "/usr/lib64/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/usr/lib/python2.7/site-packages/imgbased/__main__.py", line 51, in <module>
    CliApplication()
  File "/usr/lib/python2.7/site-packages/imgbased/__init__.py", line 82, in CliApplication
    app.hooks.emit("post-arg-parse", args)
  File "/usr/lib/python2.7/site-packages/imgbased/hooks.py", line 120, in emit
    cb(self.context, *args)
  File "/usr/lib/python2.7/site-packages/imgbased/plugins/core.py", line 163, in post_argparse
    layout.initialize(args.source, args.init_nvr)
  File "/usr/lib/python2.7/site-packages/imgbased/plugins/core.py", line 211, in initialize
    self.app.imgbase.init_layout_from(source, init_nvr)
  File "/usr/lib/python2.7/site-packages/imgbased/imgbase.py", line 230, in init_layout_from
    self.init_tags_on(existing_lv)
  File "/usr/lib/python2.7/site-packages/imgbased/imgbase.py", line 217, in init_tags_on
    pool.addtag(self.thinpool_tag)
AttributeError: 'NoneType' object has no attribute 'addtag'
[root@storage2015 rhva2017]#

Comment 1 Yaniv Kaul 2017-01-22 09:52:00 UTC
Duplicate of bug 1357068 ?

Comment 2 Greg Scott 2017-01-23 06:08:48 UTC
Looks like similar errors, but a different path to get there.  And the other bug was with an older RHV-H version.

I did do my first run with this one with custom partitioning and then told the partitioning screen to just create its default partitions.  I wanted to see what they look like. That blew up with the error.

I tried a second time with defaults.  But this time, the disk was already partitioned from the first time, so I told Anaconda to get rid of the old partitions.  And it blew up.

Third time, I set the root password during installation, but did not create a user gregs.  It blew up.

Forth time, I did not set any root password during installation. It paused and prompted me to set the root password. I did, and then it ran to completion.

Comment 3 Yaniv Kaul 2017-01-23 06:34:06 UTC
Could you try with the new image and see if any of the scenarios reproduce the issue?

Comment 4 Ryan Barry 2017-01-23 14:30:15 UTC
It's hard to diagnose this without any logs.

In general, we know that custom partitioning has a couple of limitations in Anaconda. See:

https://bugzilla.redhat.com/show_bug.cgi?id=1412151
https://bugzilla.redhat.com/show_bug.cgi?id=1380767

We strongly recommend just using autopartitioning (not entering the custom partitioning menu at all, other than to clear the spoke), because Anaconda doesn't currently provide a way for installclasses to ensure that LVM thin provisioning is used as the default.

I set the root password during installation every time I install, though. We're using platform Anaconda -- RHV-H doesn't do anything different here. If it blows up setting the root password, I'll file a bug against Anaconda if I can get exact steps to reproduce, since I already know that I can't reproduce what's provided for your third test (use autopartitioning, set a root password during install).

Comment 5 Greg Scott 2017-01-23 14:50:56 UTC
About logs - I pasted in the ks-script log in the the original post.

I have everything it left in /tmp right here.  It's around 500 MB, but it looks like nearly all of it is squashfs, which must be that initial bootstrap image.  The limit on what I can post to a bz is something like 50 MB and what's left after getting rid of squashfs should be small enough.  Do you want me to tar up the rest and attach it here?

It is possible that when I ran across the problem, it was still a legacy from doing a non-default partition scheme.  I tried changing only one thing at a time, but it was random trial and error trying to isolate what was going on.

Yaniv - the image I used was from Jan. 4, 2017.  If there's a newer one than that, I'll try it out.  Now that I have a better idea what to look for, I'll see if I can make it break.

- Greg

Comment 6 Ryan Barry 2017-01-23 15:03:33 UTC
Unfortunately, all the ks-script.log output tells me is that the partitioning was probably not set up correctly.

We don't need the entire /tmp -- just the anaconda logs should be enough (anaconda.log and storage.log in particular).

In general, I'd suggest entering the storage spoke and immediately clicking "Done".

It's possible to manually partition, as long as the following requirements are met:

LVM pool -- no bare partitions other than /boot (and /boot/efi)
The LVM pool must be a thinpool.
/var must be a thin volume of at least 15GB
/ must be a thin volume of at least 6GB.

Comment 7 Greg Scott 2017-01-23 16:18:09 UTC
Created attachment 1243653 [details]
Anaconda.log attached

Comment 8 Greg Scott 2017-01-23 16:18:44 UTC
Created attachment 1243654 [details]
Storage.log attached

Comment 9 Greg Scott 2017-01-23 16:28:16 UTC
If that's the reason why the kickstart script blows up at the end - because the partitions are wrong - would it be possible to put some documentation in the script that shows up on the screen that says so?

I know in at least one instance, the host had old partitions from an earlier failed install.  I did take the default from the storage spoke, but there wasn't enough room because of the earlier partitions.  I had to go through a dialog to get rid of the old partitions so there would be room for the correct ones.  Something in there may have triggered the error.

- Greg

Comment 10 Sandro Bonazzola 2017-01-24 09:21:13 UTC
We need to approach the issue of pre-existing partitions on the host, especially with regards to the Hyper Converged case.
We need good documentation on this.

Comment 11 Ryan Barry 2017-01-24 13:23:48 UTC
We have a couple of bugs about this, Greg (to provide more meaningful output):

https://bugzilla.redhat.com/show_bug.cgi?id=1357068
https://bugzilla.redhat.com/show_bug.cgi?id=1412056
https://bugzilla.redhat.com/show_bug.cgi?id=1412094

Regarding pre-existing partitions on the host, we are using Anaconda from platform. I'd expect this to be handled in Anaconda, since we don't make any changes here, other than the addition of an installclass (which is quite limited, and only provides guidance for autopartitioning defaults).

If you can provide steps to reproduce a scenario where removing partitions and using autopartitioning does not work, I'll file a bug against Anaconda, since I cannot reproduce this.

Comment 12 Greg Scott 2017-01-31 14:22:35 UTC
Oh! Thanks for the reminder.  I did install RHV-H 4.0.6 on a host over the weekend that had pre-existing partitions.  I took all defaults and reclaimed space to wipe and redo the HDD. During the installation, I changed the root password but did not create another user.  All worked as expected.  The problem must be that I did not use the default partition layout earlier.

I'm Ok with closing this bz since the issue is being addressed elsewhere and I misread the symptoms.

- Greg

Comment 13 Sandro Bonazzola 2017-02-07 09:14:51 UTC

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


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