[BlueOnyx:07717] Re: BlueOnyx 5107R Beta available

[Michael Stauber]

Hi Chuck,

Many thanks for your input. 

> So I'm wondering if LVM is really needed, and worth the additional
> complexity of accessing that data "off-box"??

You see, in all the time that I've been working with LVM'ed systems, I think I 
only was forced to manually mount LVM formatted drives half a dozen times. 
Even if I had to rip a drive out of a dead box, I'd put it as only drive in 
another box where all usually present drives were disconnected. And if that 
then didn't boot (which it usually did), then I could at least let the CD 
mount the drives automatically in rescue mode.  And like said: There were 
maybe 5-6 cases in the last ten years where that didn't work for me and I had 
to perform the LVM mount manually. So for data rescue I think LVM doesn't make 
that much of a difference.

> What would you say to someone who wants to avoid
> LVM using the tarball installation?  

Let me put it this way: The CD is and always will be the preferred method of 
installation. The TAR-ball is just the unwanted step-child that's there for 
the oddball installs where the CD isn't an option.

With the 5107R tarball we even went a step further and streamlined the install 
a bit further, as you can now use "yum groupinstall BlueOnyx", which will 
bring in everything you need. And of course the TAR-ball works with the 
partitioning scheme that's already present, provided you have at least a 
separate /home partition, which is a "must have".
 
> And how do you think it would effect
> the BX installation/operation by not using LVM??
> And finally - do you think we'll ever get the option to opt out of LVM in
> the ISO installation?

The 5106R CD already had three options for partitioning:

"Standard": This kicks in if you hit return and would format with LVM.

"Small": This kicks in if you typed "linux small" or "small" and would set up 
the disks with a partitioning scheme suitable for HDs smaller 20GB.

"Self": This kicks in if you typed "linux self" or "self" at the boot prompt 
of the CD. It fired up disk druid and allowed you to choose your own 
partitioning scheme.

However: The 5107R CD uses a much newer version of the Anaconda installer. 

Unfortunately Anaconda is always "work in progress" and they always change 
some things around. Stuff that used to work flawlessly and without hitch 
before, suddenly behaves entirely different, or doesn't work anymore. 

Our kickstart scripts aren't that complicated, but still: I noticed four 
fundamental problems where Anaconda had changed behaviour on us and what we 
had working fine before suddenly no longer worked, or behaved differently.

The most problems were revolving around the detection of connected HDs and 
partitioning them. I could overcome these. What I yet couldn't fix was the old 
"Self" partitioning option.

In the past when you didn't tell Anaconda how to partition the disks, it would 
simply fire up Disk Druid and would let you do it yourself. These days it 
simply complains that it doesn't know where to install to. Which is a real 
bummer. I have some hopes of being able to provide a self partitioning option 
in the future again, but right now I've given the work on that a low priority.

As for not using LVM at all:

The typical BX CD install creates these partitions:

/boot 	(500MB)
/		(6144MB)
/var		(4096MB)
/tmp	(2048MB)
Swap	(4096MB)
/home	(rest of available space)

That's six partitions.

A separate /boot is a must have for a couple of reasons, some of which deal 
with RAID, some of which deal with potential disk sizes and drawbacks of the 
boot-loader. 

We also need a separate /home so that we can enable disk quota there. Swap 
naturally needs it's own partition as well. And we need place for "/", which 
adds another partition. That's four already.

Must /var and /tmp have their own partitions? The benefit of giving /tmp its 
own partition is that we can mount it "noexec,nosuid", which prevents some 
malice. And having the logfiles and mailqueue in a separate /var partition 
helps to some degree (but not entirely) to prevent that the system partition 
fills up to a point where damage to critical files prevents booting.

There can be only four primary partitions, so if we want to use six 
partitions, some of them must reside either in an LVM, or in an extended 
partition. As /boot cannot be in an extended partition and Swap shouldn't be 
in an extended partition, this limits our options a bit about what can be 
extended and what not.

The typical kickstart examples that you see floating around either use four 
partitions at the most (without LVM), or use LVM and have more partitions.

LVM seems to be the preferred method. Why is that the case? On one hand it 
allows more flexibility, as you can "grow" or "shrink" LVM partitions at 
leizure. AND you can span LVMs over multiple drives, which is great if you 
want to set up a RAID0+1 for example.

Using LVM also allows us to get around the limit of having only a maximum of 
four primary partitions, as using an extended partition adds a single point of 
failure where we risk that damage to the extended partition wrecks every 
"sub"-partition that's within.

Anaconda can be used to create an extended partitions and to create partitions 
within that. The drawback there isn't that obvious, but it's present:

To do so, one would let the kickstart script create the usual primary 
partions:

/boot
/
Swap

The we create an "extended partion" using the remaining available diskspace. 
BUT: Anaconda then doesn't know how big the remaining space is, as we're 
forced to use the "--size=1 --grow" switch to create that partition.

In the next step we then *try* to create /home, /var and /tmp in the extended 
partition. For /var we set our usual 4096MB of size, for /tmp the usual 2048MB 
and for /home we then try to use the remaining space.

However: It could already be that we run out of space, because we have no way 
of checking how big the extended partition was to begin with. And we don't 
know offhand how big our /home will get in the end. Depending on the disk size 
at the beginning, it may be too small to allow the install to complete. So 
from that point in the install onwards we'd simply work on assumptions and 
would fly blind.

To counter that we'd have to code the size checks outside of Anaconda, which 
complicates things quite a bit.

So after this detour into the innards of Anaconda and Kickstart scripting it 
may be necessary to summarize things a bit:

Would it be nice to have a self partitioning option again?

Absolutely. If possible, it will be added again.

Will we include an optional  "no LVM" kickstart?

Maybe.

All in all I don't see LVM as problematic. To the contrary: It offers more 
benefits than drawbacks. We can bypass the four primary partition limit, we 
can shrink and grow partitions w/o reformatting, it allows us to use RAID0+1 
and makes kickstart scripting a hell of a lot easier.

Like said: I'm not against *not* using LVM. But I don't really see any 
benefits in dropping LVM. 

Here is my offer, though: Someone send me a working kickstart script that 
works with the CD and installs w/o LVM and I'll include it as boot option in 
the CDs.

-- 
With best regards

Michael Stauber