Bug 1310533 - [Hyper-V][RHEL7.2]Kickstart installation is unable to locate a disklabel. [NEEDINFO]
[Hyper-V][RHEL7.2]Kickstart installation is unable to locate a disklabel.
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda (Show other bugs)
7.2
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
:
Depends On:
Blocks: 1298243 1420851
  Show dependency treegraph
 
Reported: 2016-02-22 02:28 EST by jcastran
Modified: 2017-06-19 12:34 EDT (History)
23 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-19 12:34:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dlehman: needinfo? (jcastran)
dlehman: needinfo? (jcastran)


Attachments (Terms of Use)
Kickstart, with %pre script (2.60 KB, text/plain)
2016-02-22 02:28 EST, jcastran
no flags Details
Storage logs created when the %pre fix was included (9.10 KB, text/plain)
2016-02-22 02:29 EST, jcastran
no flags Details
Log files for customers initial install when error was first reported (130.00 KB, application/x-tar)
2016-02-22 02:30 EST, jcastran
no flags Details
Screenshot of error message (247.08 KB, image/jpeg)
2016-02-22 02:30 EST, jcastran
no flags Details
Customer reattempted installation. Tar of files provided (8.51 MB, application/x-xz)
2016-04-18 09:01 EDT, jcastran
no flags Details
Failed Install with 6.8 (86.99 KB, application/x-bzip)
2016-07-17 10:40 EDT, jcastran
no flags Details
try-2.tar (1.89 MB, application/x-tar)
2016-07-31 10:51 EDT, jcastran
no flags Details
try-3.tar (1.89 MB, application/x-tar)
2016-07-31 10:52 EDT, jcastran
no flags Details

  None (edit)
Description jcastran 2016-02-22 02:28:41 EST
Created attachment 1129169 [details]
Kickstart, with %pre script

Description of problem:
   During installation, Customer recieves:
   "For some reason we were unable to locate a disklabel on a disk that the kernel is reporting partitions on. It is unclear what the exact problem is. Please file a bug at bugzilla.redhat.com"

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

How reproducible:
So far, have not been able to reproduce this for myself. Customer always get's this message when installing 7.2 on HyperV


Actual results:
Error received, installer fails to identify disk with disklabel

Expected results:
Install completes successfully

Additional info:
   - "Our kickstart file works fine with RHEL 7.1 on HyperV"
   - "Our kickstart file works fine with RHEL 7.2 on bare metal"
   - "The problem seems to be RHEL 7.2 on HyperV"
   - "What is the difference between the 7.1 and 7.2 kickstart/anaconda process"

So far, we have attempted to correct this issue the with the following:
  %pre
   dd if=/dev/zero of=/dev/sda bs=1M count=100
   parted -s mklabel gpt /dev/sda 
   %end

But the installation still fails with the same error message.
Comment 1 jcastran 2016-02-22 02:29 EST
Created attachment 1129170 [details]
Storage logs created when the %pre fix was included
Comment 2 jcastran 2016-02-22 02:30 EST
Created attachment 1129171 [details]
Log files for customers initial install when error was first reported
Comment 3 jcastran 2016-02-22 02:30 EST
Created attachment 1129172 [details]
Screenshot of error message
Comment 5 David Lehman 2016-02-22 14:23:00 EST
According to blkid and udev there is no disklabel on sda. This indicates a serious problem given that sda1 is reported by the kernel. What happens if they reboot after manually trying to reinitialize the disk in %pre?
Comment 6 jcastran 2016-02-23 00:22:44 EST
David,

I may need some clarification on what you're asking.

With the %pre script:

  %pre
   dd if=/dev/zero of=/dev/sda bs=1M count=100
   parted -s mklabel gpt /dev/sda 
   %end

The installation still fails with the same error message. It fails on partitioning and gives you the choice to retry, or exit the installer. I will request the customer gather some storage command logs, manually label the disk, and then click "Retry" and let you know the results of that.

Please let me know if you need anything else.

Thanks,
John Castranio
Comment 16 vijaychsk 2016-04-10 22:28:23 EDT
I got the same error message. I was unable to continue installation.
Comment 17 jcastran 2016-04-18 09:01 EDT
Created attachment 1148205 [details]
Customer reattempted installation. Tar of files provided
Comment 24 David Lehman 2016-05-27 11:51:51 EDT
I have prepared an updates image providing improved handling for corrupt or otherwise unsupported disklabels. If you would like to test it (using RHEL-7.2), add the following to the kernel/boot command line:

  inst.updates=http://people.redhat.com/~dlehman/unsupported-disklabels.0.img


If you are doing a kickstart install it should now be possible to completely clear disks that contain unsupported partition tables. In the graphical installer you will see the disk with a format type of something like "Unsupported partition table". On the custom storage page you can just select the disk and hit the '-' (minus) button to schedule actions to clear and reinitialize the disk.


Please update the bug with the results of your testing. Thank you.
Comment 27 jcastran 2016-06-12 12:39:36 EDT
 === In Red Hat Customer Portal Case 01569488 ===
--- Created By: Kevin Esteb  (6/9/2016 6:27 PM) ---

This was working, after a half dozen times, reinstalling over the same VM and disk image, it has stopped working. 

The install crashes after the storage has been defined and package dependencies have been determined.

=================================================

 -John Castranio
 -Red Hat
Comment 28 David Lehman 2016-06-13 09:31:34 EDT
Please provide logs from the failed installation. Thanks.
Comment 36 HuijingHei 2016-06-30 08:13:13 EDT
Hi,

I have tried to reproduce the bug, create a new vm, install with ks.cfg add clearpart line, then reinstall with ks.cfg remove clearpart line, then the error dialog appears

clearpart --all --initlabel --drives=sda

Environment:
Host: hyperv 2012r2, gen1
Guest: rhel7.2

Steps:
1. Add ks.cfg with %pre script in attachment to ftp server (ftp://10.66.9.161/pub/ks)

2. Update rhel7.2.iso/isolinux/isolinux.cfg:

label linux
  menu label ^Install Red Hat Enterprise Linux 7.2
  menu default
  kernel vmlinuz
  append initrd=initrd.img inst.stage2=hd:LABEL=RHEL-7.2\x20Server.x86_64 quiet ks=ftp://10.66.9.161/pub/ks/ks.cfg inst.nokill

3. Make rhel7.2-ks.iso use command:

genisoimage -untranslated-filenames -volid "RHEL-7.2 Server.x86_64" -J -joliet-long -rational-rock -translation-table -input-charset utf-8 -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e images/efiboot.img -no-emul-boot -o /mnt/rhel7.2-ks.iso -T .

4. Create gen1 vm on hyperv, install the vm with rhel7.2-ks.iso

5. Update ks.cfg without clearpart line, other is the same
#clearpart --all --initlabel --drives=sda

6. Reinstall vm with rhel7.2-ks.iso


Additional info:

   - Install with ks.cfg add clearpart line, reinstall without clearpart line, reproduce the bug
   - Install with ks.cfg add clearpart line, reinstall with clearpart line, the system is automatically shutting down after the crash


Thanks
hhei
Comment 37 David Lehman 2016-06-30 10:32:04 EDT
Please take this out of the ks.cfg (%pre section) and see if you still get an error:

dd if=/dev/zero of=/dev/sda bs=1M count=100
parted -s mklabel gpt /dev/sda


The above is an ill-advised, poor substitute for a solution to a problem that is not well understood.
Comment 38 David Lehman 2016-06-30 10:44:05 EDT
You should never be trying to reinstall over a full disk without the clearpart line -- it doesn't make any sense. Please just remove the dd/parted lines from %pre, put the clearpart line in place, then try two consecutive installations. That's what the reporter says is triggering the failure.
Comment 39 HuijingHei 2016-07-01 06:28:18 EDT
(In reply to David Lehman from comment #38)
> You should never be trying to reinstall over a full disk without the
> clearpart line -- it doesn't make any sense. Please just remove the
> dd/parted lines from %pre, put the clearpart line in place, then try two
> consecutive installations. That's what the reporter says is triggering the
> failure.

Thanks for your reminder, I missed the pv with option "--grow", means the logical volume to grow to fill available space (if any), or up to the maximum size setting.

I have tested according to your comment, remove the dd/parted lines from %pre, put the clearpart line as attachment.


The result is:

   - Test vm with virtual scsi disk, first install successfully, reinstall more than 20 times, not always successfully, 3 times appears "anaconda halting due to nokill flag", but not the same result as bug description
   - Test vm with virtual ide disk, first install successfully, reinstall successfully

I have not tested it on SAN, if needed, I will test it when FC is OK.

Thanks
hhei
Comment 42 jcastran 2016-07-17 10:40 EDT
Created attachment 1180779 [details]
Failed Install with 6.8

Attempting to upgrade a HyperV VM that was RHEL 6.8. Using the following kickstart file. This attempt failed, I have included the files from /tmp.

#version=DEVEL

%include /tmp/network.ks

install
cdrom
#
graphical
keyboard --vckeymap=us --xlayouts='us'
lang en_US.UTF-8
timezone America/Los_Angeles --isUtc --nontp
#
eula --agreed
xconfig  --startxonboot
#
# security
#
auth --enableshadow --passalgo=sha512
rootpw --iscrypted xxxxx
#
firewall --enabled --service=ssh,samba,samba-client --port=5900:tcp --port=9501:tcp --port=9502:tcp --port=9503:tcp --port=9503:udp --port=9504:tcp --port=9505:tcp --port=512:tcp --port=513:tcp --port=514:tcp --port=5555:tcp
selinux --enforcing
#
# System services
#
services --disabled="chronyd"
#
# System bootloader configuration
#
bootloader --append=" crashkernel=auto" --location=mbr --boot-drive=sda
#
# Disk partitioning information
#
zerombr
ignoredisk --only-use=sda
clearpart --all --initlabel --drives=sda
#
part /boot --fstype=xfs   --size 500 --ondisk=sda
part pv.01 --fstype=lvmpv --size 500 --ondisk=sda --grow
#
volgroup root_vg --pesize=4096 pv.01
#
logvol swap  --fstype=swap --name=lv_swap    --vgname=root_vg --recommended
logvol /     --fstype=xfs  --name=lv_root    --vgname=root_vg --size=25000
logvol /var  --fstype=xfs  --name=lv_var     --vgname=root_vg --size=5000
logvol /home --fstype=xfs  --name=lv_home    --vgname=root_vg --size=10000
#
shutdown

%packages
@^graphical-server-environment
@base
@core
@compat-libraries
@desktop-debugging
@development
@fonts
@gnome-desktop
@guest-agents
@guest-desktop-agents
@internet-browser
@input-methods
@performance
@print-client
@file-server
@security-tools
@large-systems
@x11
kexec-tools
#
# remove the nag screens
#
-firstboot
-initial-setup
-gnome-initial-setup
#
%end

%addon com_redhat_kdump --enable --reserve-mb='auto'

%end

%pre
#
DOMAIN=wise.wa-k12.net
MASK=255.255.255.0
#
NIC=eth0
HOST=redhat-test-01
IP=10.1.252.41
GW=10.1.252.3
DNS=10.1.254.90,10.1.254.89
#
HOSTLINE="network --onboot=yes --device=$NIC --bootproto=static --gateway=$GW --ip=$IP --netmask=$MASK --nameserver=$DNS --hostname=$HOST.$DOMAIN"
#
echo $HOSTLINE > /tmp/network.ks
#
%end

%post
#
#
%end
Comment 44 David Lehman 2016-07-20 11:42:05 EDT
How did the installation from comment 42 fail? It did not fail to configure storage. It looks like software installation simply did not finish. We will need logs demonstrating the failure described by this bug report -- not just any failure of any kind.
Comment 45 jcastran 2016-07-31 10:51 EDT
Created attachment 1186080 [details]
try-2.tar

1) Installed over previous failure, this was successful. See try-2.tar
Comment 46 jcastran 2016-07-31 10:52 EDT
Created attachment 1186081 [details]
try-3.tar

2) Installed over previous success, this was successful. See try-3.tar
Comment 47 jcastran 2016-07-31 10:59:00 EDT
Hello,

I have 2 attachments added to the bugzilla.

The third is too large. Here is the link to fubar:

   https://fubar.gsslab.rdu2.redhat.com/01569488/140-try-4.tar/

It is try-4.tar 94 Mb

Please let me know if there is a better way to supply large attachments to you.

Thanks,
John Castranio
Red Hat
Comment 48 David Lehman 2016-08-01 12:05:16 EDT
(In reply to jcastran from comment #47)
> Hello,
> 
> I have 2 attachments added to the bugzilla.

We know the first two are successful installations, so why are they being shared? The third is a total mystery. Also, we still haven't seen any answers to your questions from comment 43.
Comment 51 David Lehman 2016-11-28 12:49:53 EST
As far as I can tell, try-4 was also successful as far as storage goes. If this problem persists with the updates image from comment 24, please provide a description and logs from the failing attempt. If I am missing something, please let me know.
Comment 52 David Lehman 2017-01-03 15:02:09 EST
Ping -- where do we stand on this bug report?

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