Bug 611002 - anaconda kickstart file causes strange results/ boot failures
anaconda kickstart file causes strange results/ boot failures
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
13
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-02 23:10 EDT by Bill Gradwohl
Modified: 2011-06-27 15:22 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 15:22:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Gradwohl 2010-07-02 23:10:42 EDT
Description of problem:
Using a kickstart file (with minor mods) from a successful install doesn't work.

Background – F13 x86_64 install for two identical 500G sata drives. The intent is to put boot (200), swap (4096) and / (remainder) on sda and /snapshot (all 500G) on sdb.

Using the following in a ks.cfg produces some interesting results.

clearpart --all --drives=sda,sdb
ignoredisk --only-use=sda,sdb

part /boot --fstype=ext4 --size=200 --ondisk=sda

part pv.multimedia --grow --size=1 --ondisk=sda
volgroup vg_multimedia --pesize=32768 pv.multimedia
logvol swap --name=lv_swap --vgname=vg_multimedia --size=4096
logvol / --fstype=ext4 --name=lv_root --vgname=vg_multimedia --size=1 --grow

part pv.snapshot --grow --size=1 --ondisk=sdb
volgroup vg_snapshot --pesize=32768 pv.snapshot
logvol /snapshot --fstype=ext4 --name=lv_snapshot --vgname=vg_snapshot --size=1 --grow

bootloader --location=mbr --driveorder=sda,sdb --append="quiet"


Picking custom set up reveals:
LVM Volume Groups
	vg_multimedia	0
		lv_swap	4096				swap
		lv_root		1		/		ext4
	vg_snapshot		0
		lv_snapshot	1		/snapshot	ext4
Hard Drives
	sda
		free		476937
	sdb
		free 		476937

This completely ignores the part settings, and vg sizes are trashed.

For grins I hit Next to see what would happen. 
Sure enough a failure – unhandled exception – blah blah – file a bug report.
Hit Debug to go to the debugger.
Hit Alt-F6 to return to the “Please Select a Device” screen.
Hit Back.
Hit Next to return to the “Please Select a Device” screen.
LVM Volume Groups
	vg_multimedia	476416
		lv_root		470656			ext4
		lv_swap	5760				swap
	vg_snapshot		476928
		lv_snapshot	476928			ext4
Hard Drives
	sda
		sda1		500				ext4
		sda2		476439	vg_multimedia physical volume LVM
	sdb
		sdb1 		476939	vg_snapshot physical volume LVM

Note mount points are missing, but the vg_names are known. Why swap went to 5760 from 4096 is a mystery, as is boot going to 500 from 200. Further note that free space above was 476937, so how can the partition space now be greater at 476939 ?

It also changed the sort order of lv_root and lv_swap. I purposely put swap first in the cfg file so I could use –grow on the root spec. I didn't know if it was smart enough to allow me to put –grow one line ahead of something with just a size spec.

There is no boot partition.

Hit Next to get error messages about no / and /boot partitions.


BTW – I originally tried to do this without LVM as follows:

A normal install of F13 via DVD with no ks file, that is customized during the install by manually destroying the LVM options and partitioning manually without LVM, produces a ks file that when reused includes LVM. It also puts mount points at the wrong place. The original install is fine – only a new install attempting to use the ks file is trashed.

I installed and manually partitioned so that /snapshot would occupy all of sdb. The following is missing that granularity.

Here is a portion of the ks file that was produced by a standard install that nuked the LVM stuff and partitioned manually placing /snapshot on sdb with everything else on sda. This install worked, but the ks file it produced is bogus.

#clearpart --none --drives=sda,sdb
#ignoredisk --only-use=sda,sdb

#part /boot --fstype=ext4 --size=200
#part swap --size=4096
#part / --fstype=ext4 --grow --size=500

#part /snapshot --fstype=ext4 --grow --size=500

That ks when reused (by uncommenting) creates LVM partitions and /snapshot is NOT on a separate drive.

How do you tell ks to not create LVM partitions?



Using the following in a kickstart file to attempt to force /snapshot on to sdb:
clearpart --all --drives=sda,sdb
ignoredisk --only-use=sda,sdb

part /boot --fstype=ext4 --size=200 --ondisk=sda
part swap --size=4096 --ondisk=sda
part / --fstype=ext4 --grow --size=500 --ondisk=sda

part /snapshot --fstype=ext4 --grow --size=500 --ondisk=sdb

allows the install to proceed normally, but the first boot after the install fails on:
mount: /dev/mapper/VolGroup-lv_root already mounted or /sysroot busy
mount: according to mtab, /dev/mapper/VolGroup-lv_root is already mounted on /sysroot
(above repeated numerous times)

Can't mount root file system
Boot has failed, sleeping forever.

The intent was to NOT use LVM, but I got LVM anyway.

To summarize, nuking LVM options during a typical install and using old fashioned partitions creates a ks file that when uncommented and reused creates LVM partitions, and ignores specific positioning of a mount point on a particular device. Therefore the ks file as written is missing something to tell the reinstall to not use LVM partitions. This is also counter to the documentation supplied at http://fedoraproject.org/wiki/Anaconda/Kickstart which indicates that to use LVM partitions, the partition name has to include an appropriate prefix (pv.) that then gets referenced by the volgroup options.

Adding drive options to those partition lines allows the install to finish, but causes a boot failure. 

Converting to LVM enabled options also doesn't work.

Either the software, docs or I'm missing something. 

I have spare boxes to experiment on if necessary.
Comment 1 Chris Lumens 2010-07-06 13:08:21 EDT
Please try again and once you hit the initial problem of no /boot, sizes all weird, etc. switch over to tty2, grab /tmp/storage.log, and attach it to this bug.  Note that --size=1 --grow isn't really a wise thing to do.  You should at least be providing a size that is minimally useful.
Comment 2 Bill Gradwohl 2010-07-06 14:37:20 EDT
(In reply to comment #1)
> Please try again and once you hit the initial problem of no /boot, sizes all
> weird, etc. switch over to tty2, grab /tmp/storage.log, and attach it to this
> bug.  Note that --size=1 --grow isn't really a wise thing to do.  You should at
> least be providing a size that is minimally useful.    

It will take me a day or two to do the testing as you requested, but if the box won't boot, how am I supposed to get something off of tty2?  

Are you suggesting I do something at install time with tty2, or after its messed up and I have a box that won't boot? Either way, I don't see how I'm supposed to get anything off the box. As I recall, the screens on the tty's are just logs of what's going on, and don't offer a command prompt.

Am I missing something?
Comment 3 Chris Lumens 2010-08-17 09:48:13 EDT
> Are you suggesting I do something at install time with tty2, or after its
> messed up and I have a box that won't boot? Either way, I don't see how I'm
> supposed to get anything off the box. As I recall, the screens on the tty's are
> just logs of what's going on, and don't offer a command prompt.
> 
> Am I missing something?

During install, at any time after making partitions but before rebooting, press ctrl-alt-f2.  That'll take you to the one console we have with a shell on it.  From there, you can scp files to other machines or mount a USB device and copy them to that.  Along with /tmp/storage.log, /tmp/syslog and /tmp/anaconda.log would be useful too.
Comment 4 Bug Zapper 2011-06-01 10:52:40 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Bug Zapper 2011-06-27 15:22:00 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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