Created attachment 910858 [details] Kickstart file Description of problem: Trying to install Fedora 20 via kickstart on a x86_64 server. This has worked previously on several other identical servers using the identical kickstart file. On this one, installation stops at the first screen with the error, "no disks selected". Watching more carefully, the message is first, "failed to save storage configuration", changing to "no disks selected" after a moment or two. Examining the anaconda logs (via the alternate consoles) did not reveal any smoking gun (or I don't know what to look for). Manually selecting the disk item from the menu, choosing the /only/ disk on the machine, and selecting "continue" just repeats the error. Doing that again, this time choosing to manually partition the disk but accepting all the defaults anyway, the kickstart continues and appears to finish successfully. However, the installed system is missing something, or several somethings. The network does not start. Several other start-up steps fail. Manually starting the network makes it appear that the machine is mostly normal. Repeating the kickstart after the "successful" result yields the same error. Version-Release number of selected component (if applicable): Dell R510 server, two quad-core Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 16 GB RAM, 1 TB disk. How reproducible: So far, every time on this one server. Never on other servers. Steps to Reproduce: 1. Start PXE boot pointing to attached kickstart file. 2. 3. Actual results: Installation hangs. Expected results: Installation completes. Additional info: Kickstart file points to local clones of the latest Fedora and RPMFusion repos. Clones created using reposync and updated hourly.
Created attachment 910859 [details] Anaconda ifcfg log
Created attachment 910861 [details] Anaconda journal log
Created attachment 910862 [details] Anaconda log
Created attachment 910863 [details] Anaconda packaging log
Created attachment 910864 [details] Anaconda program log
Created attachment 910865 [details] Anaconda storage log
Created attachment 910866 [details] Anaconda xlog
(In reply to Dave Close from comment #0) > Description of problem: > > Trying to install Fedora 20 via kickstart on a x86_64 server. This has > worked previously on several other identical servers using the identical > kickstart file. On this one, installation stops at the first screen with the > error, "no disks selected". Watching more carefully, the message is first, > "failed to save storage configuration", changing to "no disks selected" > after a moment or two. Examining the anaconda logs (via the alternate > consoles) did not reveal any smoking gun (or I don't know what to look for). You specify to use only sda, but sda has no media present (sda is an iDRAC LCDRIVE, sdb is an iDRAC virtual floppy) . The only usable drive is sdc. If you change that part of your ks.cfg (clearpart and bootloader lines) your installation might finish. > > Manually selecting the disk item from the menu, choosing the /only/ disk on > the machine, and selecting "continue" just repeats the error. Doing that > again, this time choosing to manually partition the disk but accepting all > the defaults anyway, the kickstart continues and appears to finish > successfully. > > However, the installed system is missing something, or several somethings. > The network does not start. Several other start-up steps fail. Manually > starting the network makes it appear that the machine is mostly normal. This is a separate issue that you should pursue in a separate bug report if you wish to do so.
Thank you, David. Making those two changes seems to have allowed the installation to proceed correctly. But I'm confused as to how it was possible for several other identical servers to be successfully installed using this kickstart through the identical interface. The "separate issue" really isn't, at least for me. I included that information only to help diagnose this issue since it seemed to be a consequence of the problem. If you suspect the result is an unintended result of my workaround, then I'd be glad to open a report. While I understand the drive mapping using iDRAC, documentation led me to believe that the clearpart and bootloader lines referenced the installed system, not the iDRAC environment. Maybe some documentation improvement would be justified.
(In reply to Dave Close from comment #9) > While I understand the drive mapping using iDRAC, documentation led me to > believe that the clearpart and bootloader lines referenced the installed > system, not the iDRAC environment. Maybe some documentation improvement > would be justified. The device names used for the clearpart and bootloader lines have to match what the kernel uses during installation. Since this is known to be less than completely predictable it is possible to refer to disks using less volatile specifications. Anywhere you can put "sda" you can also put a symlink from /dev/disk/by-id, which should not change under any circumstances (aside from replacing a drive). Shell-style globs are supported here as well.
I have now tried the revised kickstart, using sdc in place of sda, on five additional servers. All failed, reporting that sdc was a non-existent disk. Changing the kickstart back to sda is allowing those servers to be installed. So as of now, I have one server that requires me to use sdc and a dozen that require sda. All the iDRAC cards were ordered at the same time but I'll be checking for any unexpected differences. At least I have a solution for any other servers that don't like using sda. Using /dev/disk/by-id would be a wonderful solution if it didn't require that I somehow determine the disk UUID before generating the kickstart file. This information is not on the outside of the server chassis nor is it part of the shipping documents.
Clearly there is some difference in the configuration of the servers. If there is only one drive in each system you could omit the boot-drive option to the bootloader command and the drives option to the clearpart command. The installer should do the obvious thing and handle it for you.
I found that the iDRAC on the machine which needs to use sdc has firmware version 1.95. All the others have firmware version 1.85. Logic says that a minor number change shouldn't have this sort of effect, but clearly Dell doesn't follow that rule. I'll try leaving out the drive on my next servers. For now, I think we can consider this ticket resolved. Thanks.
(In reply to Dave Close from comment #11) > Using /dev/disk/by-id would be a wonderful solution if it didn't require > that I somehow determine the disk UUID before generating the kickstart file. > This information is not on the outside of the server chassis nor is it part > of the shipping documents. You could use %pre to generate the correct entries in a temporary file and then %include that file.
Closing per comment 13.