Created attachment 1156634 [details] kickstart file Description of problem: Kickstart install NGN on UEFI machine enter dracut emergency shell. Version-Release number of selected component (if applicable): ovirt-node-ng-installer-ovirt-3.6-2016051108.iso How reproducible: 100% Steps to Reproduce: 1. Machine is set to UEFI boot mode 2. Install the NGN with kickstart file as attachment show. Actual results: Kickstart install NGN on UEFI machine enter dracut emergency shell. Expected results: Install successfully via UEFI boot. Additional info: Due to the UEFI machine located in Lab, so I can't obtain the log info, I will send ticket to lab admin to get log file tomorrow.
Created attachment 1156635 [details] picture
Is dracut dropping into rescue mode before stating the installer? Or is it dropping into rescue mode after the reboot after installation? Please provide the complete rdsosreport
(In reply to Fabian Deutsch from comment #2) > Is dracut dropping into rescue mode before stating the installer? Yes. > Or is it dropping into rescue mode after the reboot after installation? > > Please provide the complete rdsosreport Lab admin is off duty today, weiwang will send ticket to admin to get log file tomorrow.
Hi Fabian, Ticket has been sent to admin, I will attach the rdsosreport as soon as possible.
Created attachment 1157804 [details] rdsosreport Got log file, and attached into attachment.
I cannot reproduce this. The kickstart given doesn't look right, though. I'll attach a kickstart which works with inst.ks=... (note that an appropriate stage2 needs to be given also). Are you PXE booting this machine? Can you provide the configuration? I can also PXE install without problems, but I may be able to spot the error in your config.
Created attachment 1158387 [details] Working EFI kickstart
Created attachment 1158388 [details] Working EFI kickstart
Lowering priority according to comment 6: The kickstart looks wrong, key: It has no LVM in it. And: It is tried to create partitions on a DVD-ROM
Hi Ryan, I used virtual CD booting for this issue, since we have no PXE server supporting UEFI boot.
Set bug severity to low due to our UEFI mahcine doesn't support boot from PXE server.
(In reply to weiwang from comment #10) > Hi Ryan, > I used virtual CD booting for this issue, since we have no PXE server > supporting UEFI boot. Ok, that's much easier, since the stage2 is already present. Can you please host the kickstart I attached somewhere, and try booting from EFI with that kickstart? I also tested installation from CDROM (in an EFI virtual machine) with the provided kickstart and it worked...
hi Ryan, I have tried what you said(only changing the liveimg url for myself url), but it is failed booting from EFI. There are two confusing problems here: 1. Using virtual CD booting, the nic does not boot any more, so the url in kickstart file for getting installation tree is unreachable, maybe this is the reason for the booting failure. 2. From https://github.com/rhinstaller/pykickstart/blob/master/docs/kickstart-docs.rst for EFI booting, we need to add commands in kickstart file as blow: part biosboot --size=1 --fstype=biosboot part /boot/efi --fstype=efi --size=.... is it right? or there is another comprehension for EFI booting commands in kickstart file.
Have you tried with ip=dhcp? Anaconda should do this automatically if a remote URI is specified, but worth a try. If you tell me which system it is, I can connect and try. Also, autopart is fine. Anaconda will automatically detect that it's EFI and set up the appropriate partitions. No biosboot partition is necessary for GPT partitioned disks using EFI (which should be all of them)
hi Ryan, Yes, I have tried with dhcp. And I will send you email about the system, you can try to connect. Test steps: 1. Modify the liveimg url of "Working EFI kickstart" in comments 8, and using it as kickstart file 2. Download ovirt-node-ng iso to be boot iso for installation 3. Find a physical machine which support UEFI, then configure UEFI in boot settings. 4. Boot machine, entry into grub menu, select Centos 7, and then press "e" to add inst.ks parameter for boot kernel argument. Then press ctrl+x to start install 5. Check the process of installation Result: Installation failed, and kernel panic occur. (Take snapshot in attachment) More info: UEFI test must use physical machine, since vm is not so accuracy for UEFI testing. Are these test steps right? Are these same with yours?
(In reply to weiwang from comment #15) > hi Ryan, > Yes, I have tried with dhcp. And I will send you email about the system, you > can try to connect. > > Test steps: > 1. Modify the liveimg url of "Working EFI kickstart" in comments 8, and > using it as kickstart file > 2. Download ovirt-node-ng iso to be boot iso for installation > 3. Find a physical machine which support UEFI, then configure UEFI in boot > settings. > 4. Boot machine, entry into grub menu, select Centos 7, and then press "e" > to add inst.ks parameter for boot kernel argument. Then press ctrl+x to > start install > 5. Check the process of installation > > Result: > Installation failed, and kernel panic occur. (Take snapshot in attachment) > > More info: > UEFI test must use physical machine, since vm is not so accuracy for UEFI > testing. > > Are these test steps right? Are these same with yours? These are the same as mine, yes. No screenshot is attached, but I'll try the system...
Created attachment 1162325 [details] screenshot_uefi
Thanks -- I'll use IPMI tomorrow to test this
(In reply to weiwang from comment #17) > Created attachment 1162325 [details] > screenshot_uefi I cannot reproduce this on the given test machine. I used inst.ks=http://209.132.178.115/uefi.ks. No other parameters were added/changed. I also hosted the image installation at http://cloud.rbarry.org/uefi.iso, along with the squashfs used (the squashfs is just a build from the latest ovirt-node-ng master, the ISO is just ovirt-node-ng/scripts/derive-boot-iso using a RHEL 7.2 boot ISO and that squashfs). I had to install in text mode, but that may be due to some limitation in the connection (it wasn't very fast). I don't know if X normally worksion Anaconda in this system. I also had to manually trigger "dhclient em1" from one of the Anaconda shells (Ctrl+Alt+F2) to be able to retrieve the squashfs. I don't think this is an EFI problem, but rather a configuration problem in the lab somewhere, or the kickstart may need to specify --device=link or --device=... for the apprpriate external interface. Retrieving the kickstart was fine, but since all 6 NICs have valid addressing, the kickstart may need a tweak for this machine. Or the other interfaces should not assign default routes. I left the system installed.
hi Ryan, I have checked the system on the given test machine, and it is still in BIOS boot mode. Could you please check your steps and retry it on UEFI mode? The system info will send to you by email. And I use the ks file which you've given, still can reproduce this bug. But the iso you've given can be installed on UEFI mode correctly, it is interactive installation. So for automatic installation with kickstart file, the bug still occur.
(In reply to weiwang from comment #20) > hi Ryan, > I have checked the system on the given test machine, and it is still in BIOS > boot mode. Could you please check your steps and retry it on UEFI mode? The > system info will send to you by email. > > And I use the ks file which you've given, still can reproduce this bug. But > the iso you've given can be installed on UEFI mode correctly, it is > interactive installation. So for automatic installation with kickstart file, > the bug still occur. I'll reinstall this. My guess is that somebody else accessed the system. It was definitely in UEFI mode (this is easily checked by the way grub looks, but I also checked efibootmgr and efivars after install). I also automatically installed.
Rechecked the test steps with reporter together, incorrect setting on booting menu items. So closed this bug as not a bug.