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

[Landreth, Kevin]

After sfdisk, do blockdev --rereadpt <dev> or partprobe <dev>  to force
the kernel to understand that the disk layout has changed.  Once for
each disk.

Let us know if that helps :)

--
Thanks,
Kevin Landreth, RHCE
Technology Architect 


-----Original Message-----
From: kickstart-list-bounces at redhat.com
[mailto:kickstart-list-bounces at redhat.com] On Behalf Of dwight at
supercomputer.org
Sent: Wednesday, February 06, 2008 11:15 AM
To: kickstart-list at redhat.com
Cc: Cris Rhea
Subject: Re: Old style fixed partitions in KS-- Anaconda bug??

On Tuesday 05 February 2008 04:02:52 am Cris Rhea wrote:

> I've tried with and without zeroing the first block (did this to 
> nuke some systems that came from Sun with ZFS/GPT).   No change...
>
> The sfdisk IS SUCCESSFUL (looking at the disk with the <CTL><ALT>
> <F2> shell).

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.

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.

And this is, in fact, what anaconda/parted appear to be running into:

> 15:27:41 CRITICAL: parted exception: Error: Error informing the
> kernel about modifications to partition /dev/sda5 -- Device or
> resource busy. This means Linux won't know about any changes you
> made to /dev/sda5 until you reboot -- so you shouldn't mount it or
> use it in any way before rebooting.

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.

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.

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.

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.

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

   -dwight-

_______________________________________________
Kickstart-list mailing list
Kickstart-list at redhat.com
https://www.redhat.com/mailman/listinfo/kickstart-list