Hide Forgot
Description of problem: virt-install on new, clean sparse image blocks. Original ks contained: clearpart --initlabel --drives=vda Does not work with: clearpart --initlabel --all Unblocks only after adding `zerombr` Version-Release number of selected component (if applicable): - anaconda-13.21.152 - blocks - the host is updated RHEL6.2.Z as of 2012-02-23 - python-virtinst-0.600.0-5.el6.noarch - worked well on anaconda-13.21.151 - no *virt* component was updated recently How reproducible: 100% Steps to Reproduce: 1. run the `virt-install` command below Actual results: - installation stuck Expected results: - installation pass Additional info: virt-install was run like this: /usr/sbin/virt-install --name node01 --ram=1024 --vcpus=1 --disk path=/var/lib/libvirt/images/node01.img,size=5,sparse=true,cache=writeback --hvm --debug --nographics --accelerate --os-variant=virtio26 --noreboot --location /net/nfs.englab.brq.redhat.com//pub/rhel/nightly/latest-RHEL-6/6/Server/x86_64/os -x console=ttyS0,115200 ks=http://192.168.122.1/clusternode.ks^M The `/var/lib/libvirt/images/node01.img` file does not exist before running virt-install.
And the ks goes like this: nfs ... repo ... install cmdline lang en_US.UTF-8 keyboard us network --device eth0 --bootproto dhcp rootpw --iscrypted $1$8Yt2YooQ$gOyjppb0cwRJLxBAUq/SM/ reboot firewall --disabled authconfig --enableshadow --enablemd5 selinux --permissive timezone --utc America/Chicago # the console will be appended automagically by anaconda, adding it here would double the entry thus making it unusable in virsh bootloader --location=mbr --append="crashkernel=256M@256M" clearpart --initlabel --drives=vda autopart %packages ... %post ...
Discussed with vpodzime on IRC who suggested it may be the desired behavior.
what's clearpart --initlabel good for then? quote: --initlabel Initializes the disk label to the default for your architecture (for example msdos for x86 and gpt for Itanium). It is useful so that the installation program does not ask if it should initialize the disk label if installing to a brand new hard drive.
clearpart --all --initlabel creates a fresh disklabel on disks that already contain a disklabel, after removing the partitions. The --initlabel option is only meaningful when combined with the --all option. The clearpart command without either --linux or --all means to not remove any partitions. This is probably not what you intended. The zerombr command skips prompting the user when anaconda encounters an uninitialized disk or a disk formatted in a way that anaconda does not understand. If you do not wish to be prompted, include zerombr.
(In reply to comment #4) > what's clearpart --initlabel good for then? > > quote: > --initlabel > > Initializes the disk label to the default for your architecture (for > example msdos for x86 and gpt for Itanium). It is useful so that the > installation program does not ask if it should initialize the disk label if > installing to a brand new hard drive. Where is this quoted from? What is the corresponding text for the zerombr command?
quote from http://fedoraproject.org/wiki/Anaconda/Kickstart#clearpart Strange thing is that this worked quite well with 6.2 and it's predecessors without any need of zerombr and now that has changed.
Then consider at least if this as incompatibility deserves a release note, please.
adding zerombr does not fix this problem on bare-metal (it did help in virts). The problem is that now there is no automatic way in installing the machine. It does not prompt, but it says there is no space for partitions. Starting setup is like this (created by anaconda 13.21.152): [root@marathon-01 ~]# parted /dev/sda print Model: FUJITSU MBD2300RC (scsi) Disk /dev/sda: 300GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 525MB 524MB primary ext4 boot 2 525MB 300GB 299GB primary lvm Kickstart fails with options: ignoredisk --only-use=sda zerombr clearpart --initlabel --drives=sda autopart saying: │ Could not find enough free space for │ │ automatic partitioning. Press 'OK' │ │ to exit the installer. │ The very same kickstart with the above options commented (together with cmdline) stops at: ┌─────────────────────┤ Partitioning Type ├─────────────────────┐ │ │ │ Installation requires partitioning of your hard drive. The │ │ default layout is suitable for most users. Select what space │ │ to use and which drives to use as the install target. │ │ │ │ Use entire drive │ │ Replace existing Linux system │ │ Use free space │ │ │ │ Which drive(s) do you want to use for this installation? │ │ [*] sda 286102 MB (FUJITSU MBD2300RC) ↑ │ │ ▮ │ │ │ │ ┌────┐ ┌──────┐ │ │ │ OK │ │ Back │ │ │ └────┘ └──────┘ │ │ │ │ │ └───────────────────────────────────────────────────────────────┘ If you confirm with Use entire drive it will create the partition table printed at the beginning. So the disk is there, is visible and should be auto-partitioned as it was before (6.2 and earlier). This is not the case, therefore I'll mark it as regression.
(In reply to comment #9) > Kickstart fails with options: > ignoredisk --only-use=sda > zerombr > clearpart --initlabel --drives=sda > autopart You must pass --all to clearpart (clearpart --all --initlabel) if you want it to clear any partitions. The default is --none. You will find that with 'clearpart --all --initlabel' and 'zerombr' the behavior is as expected. *** This bug has been marked as a duplicate of bug 796590 ***