[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Old style fixed partitions in KS-- Anaconda bug??



On Wed, Feb 06, 2008 at 09:14:59AM -0800, dwight at supercomputer.org wrote:

> One has to be careful. There's an in-core copy of the partition table
> (used by the kernel) and an on-disk copy. The two are different, and 
> can be out of sync.  Looking at the changes by hand can give you the 
> in-core copy, when in fact it hasn't been written to disk.

I've verified that it was correctly written to disk-- both within the Kickstart
session (<CTL><ALT><F2> shell) and after the fact with a rescue disk.

I've used this method successfully since the RedHat 7 days... 

> This has been an annoying problem across all versions of UNIX and 
> Linux ever since UNIX was first put on the PC back in the mid 1980's.

sync; sync; sync  :)


> It would seem that anaconda is somehow leaving open /dev/sda, and 
> preventing the new table from being sync'd. But this only happens if 
> you do modifications in the %pre section.
> 
> Clearly this is a failure on anaconda's part. The options aren't 
> pleasant.

This appears to be exactly what is happening. Googling the error, there
are other postings suggesting an open file descriptor in Anaconda. 
I was fine and didn't trip over this until CentOS4.5 (RHEL4.5).

> One quick workaround might be to kickstart twice. The first time 
> through, do the partitioning as you have it, and then reboot. The 
> second time would do the rest of your kickstart file. This isn't 
> pleasant, but it might work.

I've tried that-- strangely, it fails the same way.

> Barring that, I think one would have to dig into anaconda, and 
> figureout who is keeping that device open between the %pre section,
> and when parted is run.

If I could figure out how to set up a dev/test environment for Anaconda, I
would have gladly fixed this by now... been battling his for 6+ months.
I just don't know enough (and can't find the info) on loading 
Anaconda/stage 2 boot, etc.

> I hope that doesn't sound discouraging, because what you are doing is
> pretty important. The lack of a reliable way to define partitions in 
> the %pre section is IMHO the greatest weakness of Kickstart. 
> Anaconda's preordained ability to overwrite what the user wants, 
> with no alternative, based upon arbitrary and undocumented defaults, 
> is very limiting in a production environment.

IMHO, the various distributions are fighting two battles- one camp wants to
make loading Linux so simple anybody can do it (the distributions where 
there's /boot and / as the only file systems). That versus the camps where 
they are trying to add every advanced feature from all the different 
versions of Unix (LVM, software RAID, journaling file systems, etc.). 
I've been doing Unix/Linux admin for 20+ years... I want to make the decisions
on how my systems are set up-- not some idiot-proof admin tool like Anaconda.
Even using Anaconda manually (no Kickstart), it's getting harder and harder to 
manually decide/partition disks as I wish -- rather than "just trusting Anaconda
and Disk Druid".  I much preferred the days where a radio button allowed users to
manually partition with fdisk...

> And your solution here is the best that I've seen. It should part 
> of a FAQ somewhere.

Thanks-- I've seen some really cool ideas presented in this forum.

> 
>    -dwight-

-- 
 Cristopher J. Rhea                     
 Mayo Clinic - Research Computing Facility
 200 First St SW, Rochester, MN 55905
 crhea Mayo EDU
 (507) 284-0587


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]