Description of problem: In RH3 using Kick start ks.cfg you were able to use the clearpart --all -- initlabel command to silently clear,clean, delete ALL existing partitions from the server without user intervention. This allowed us to boot to a CD then walk away until the Kickstart process was over and the server rebooted. When we started to develop RH4 using Update 3 also Kickstart and the clearpart - -all --initlabel, we noticed that the first time the server built all the partitions were deleted and it worked fine, however, the second time we built the same server we received Python - anaconda errors at kickstart time saying the install could not create a LVM PV because there was no space. Upon rebooting we continued to get the same error. We then recreated the ks.cfg file and removed the --initlabel option from the clearpart statement. After rebooting and each additional time we re-built the server, instead of getting the Python error we received a nice GUI interface asking us if we would like to clear all the partitions off the server. When we answered yes the installation continued without incident. Again, each subsequent time we rebuild the same server the nice GUI interface came up and asked us if we wanted to delete all the partitions. Again, answering yes allowed the installation to proceed without problems. The issue is we can NO LONGER build these servers silently. A user must stay at the server side until they can answer yes to the delete all partitions GUI question. Is this a bug or are we missing some option to the clearpart command to allow us silent installs (user free) like we did in RH3? Thanks Version-Release number of selected component (if applicable): RH 4 Update 3 - This is the first version of RH 4 we used. We have no knowledge if the clearpart command acted any different in RH4 Update 1 or 2 How reproducible: Each subsequent time we rebuild the same server we get the error Steps to Reproduce: 1. Use clearpart --all --initlabel in the ks.cfg (This produces the Python cannot create LVM error on all rebuilds,re-installs of RH4 U3 of the same server AFTER the initial build) 2. Replace with clearpart --all in the ks.cfg (This produces the delete partitions GUI on all rebuilds,re-installs of RH4 U3 of the same server AFTER the initial build) 3. Actual results: Python error in anaconda Expected results: Allow silent user free installation with ks.cfg Additional info:
*** Bug 188580 has been marked as a duplicate of this bug. ***
I've been seeing a related behavior on our kickstart installs. We don't use the default LVM layouts, rather we choose to specify the partition scheme ourselves. What happens during the install (on some of our machines which are all HP DL360/DL380's) is the label applied to the filesystems gets a "1" appended to it. The /etc/fstab is correctly contructed though. The workaround is to fix the labels manually, but that is clearly not acceptable long term. Sounds like this could be related to the above problem.
I can't reproduce this with RHEL4u4. Perhaps there's something specific to your kickstart file that's causing the problem. Assuming you are still seeing this problem on RHEL4u4, can you please attach the partitioning-specific portion of your kickstart file to this bug report?
clearpart --all --initlabel
Please test against the next update release of RHEL4 and let me know if this is still broken for you. If so, please attach your complete kickstart file and a screenshot or the exact text of the error message you're seeing. Also, /tmp/anaconda.log from the installation would be helpful. Thanks.
*** Bug 443372 has been marked as a duplicate of this bug. ***
Entire text screen: Red Hat Enterprise Linux AS (C) 2004 Red Hat, Inc. +--------------------+ Warning +--------------------+ | | | /dev/sda contains GPT signatures, indicating | | that it has a GPT table. However, it does not | | have a valid fake msdos partition table, as it | | should. Perhaps it was corrupted - possibly by | | a program that doesn't understand GPT partition | | tables. Or perhaps you deleted the GPT table, | | and are now using an msdos partition table. Is | | this a GPT partition table? | | | | +-----+ +----+ | | | Yes | | No | | | +-----+ +----+ | | | | | +---------------------------------------------------+ <Tab>/<Alt-Tab> between elements | <Space> selects | <F12> next screen
From the docs: --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. I can see the bug only when clearpart --all --initlabel is specified. If --initlabel is omitted then I can't see the bug.
Alexander - if you could grab http://people.redhat.com/clumens/188579.img, test it out, and post the log files to that bug it would be helpful. Note that updates= is not supported in RHEL4.
Chris, with your updates.img everything seems fine. I can proceed further and then I hit bug #443373 so I can't complete the install.
Alexander - this tells me that your GPT issue is being caused by the dispatch traceback you can see in your log files that Martin committed a fix for. I included that in the updates image just to make sure you didn't hit another issue at the same time. So your problem there should be solved already. We just need to do a new build.