>>>>> "CL" == Chris Lumens <clumens@xxxxxxxxxx> writes:
CL> What could we add that would allow you to ditch your %pre-based disk
CL> partitioning?
At this point, I don't know. Basically I switched because the Anaconda
folks told me that I had to use %pre instead of relying on some RAID
behavior which worked for many releases but caused an error after a
particular point. (I know that's not useful, but there's a bugzilla
ticket about it I could dig up.)
And once you're free of the constraints of static config, it's easy to
go wild.
Right now, here's the kind of thing I do:
For a desktop:
Set the swap VG size to to 4GB <= RAM <= 16GB.
Only set up an EFI system partition if the machine was booted via UEFI.
Set the size of /scratch to leave me no less than 20GB of unallocated
space in the main VG.
For a server, which often has a number of SSDs and a number of disks:
Find the set of smallest, identically sized non-removable disks (the
SSDs). Set up EFI system partitions on each under different
mountpoints, then RAID1 the remainder of the space for a VG holding the
OS.
On the other disks in the machine, RAID them with parameters given when
the kickstart file was generated.
CL> I'm wondering if higher level commands (like you mention later)
CL> would help, or perhaps some tools in either blivet or kickstart that
CL> could query the system and generate kickstart commands for you?
I'm thinking that at this time, there's not much of a chance that
anything can help the server case as its just become too complex. The
magic is in dynamically finding the "OS disks" and setting them up
separately. Doing anything with the "data disks" is just convenience
that could be done after boot. Doing it statically (i.e. generating
this stuff ahead of time) isn't really possible because I have no idea
which device names the kernel will assign for all of the disks;
sometimes hey aren't even stable.
The desktop case, where things are sized based on disk and RAM size and
conditionally on EFI, might be doable with the addition of a few extra
bits of kickstart syntax.
CL> What are you doing here that can't be done with a combination of the
CL> repo command and more stuff in the %packages section?
Well, basically I have to install so much crap that I'd prefer to do it
while the system is actually up and running. That's not really in the
realm of something you'd want to do in kickstart, though. Basically,
things like Matlab and Mathematica are huge.
CL> Or alternately, more information being supplied to the server when
CL> the kickstart file is fetched? That would also be doable.
Yes, that's what I'm talking about. I know I can hack the dracut
component of anaconda to pass more HTTP headers, but I really wish it
could just POST some JSON or something with as much info as possible.
Detected devices, DMI information, that kind of thing.
CL> It sounds like you want a kickstart version of what we've got in
CL> custom partitioning right now.
Pretty much. The installer already has code for making things "easy"
for people actually clicking on buttons in the interface, but none of
those bits are exposed to people doing kickstart installs.
There are a couple of other things I'd like to throw out there, which
are more anaconda things but which would really only be relevant
First, let me specify what happens on the machine while its installing.
I do almost all of my installs to user desktops remotely. If they walk
into their office at the wrong time, they see the generic anaconda
instructions and can get a passwordless shell. I'd really like to be
able to specify what they can see ("Touch this machine and I break your
hands" | cowsay), and at least protect that shell somehow.
Secondly, I really wish we had some sort of installation console. Currently,
dracut boots, DHCPs and tries to fetch a kickstart file once. There's
no way that I know of to have it wait there until a kickstart file is
ready. If there were, an application could show an admin information
about the machines waiting to be installed and allow parameters to be
set and such. If you've ever seen how the old school Scyld Beowulf
cluster stuff worked, you'd see what I'm talking about.
And going along with that, having some specified way to get progress
information out of the installing system would allow a pretty complete
system for doing a whole pile of installations (which is something I do
twice a year).
- J<
_______________________________________________
Kickstart-list mailing list
Kickstart-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/kickstart-list
