Hide Forgot
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]#
Duplicate of bug 1357068 ?
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.
Could you try with the new image and see if any of the scenarios reproduce the issue?
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).
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
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.
Created attachment 1243653 [details] Anaconda.log attached
Created attachment 1243654 [details] Storage.log attached
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
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.
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.
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
*** This bug has been marked as a duplicate of bug 1357068 ***