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

Re: Proposal for --noformat handling

> clumens and I were discussing the --noformat option in kickstart
> files today (sort of came out of bug #652417, but this is a larger
> proposal) and how we should have a policy in place for people who
> want to prepare their own filesystems.

Right - there's still the question of why volumes marked with --noformat
aren't getting mounted in the first place.  So this discussion doesn't
solve the bug so much as fix anaconda when we have the check to make
sure / is formatted.

> The primary use of --noformat is for people using a %pre script to
> set up complex mount points and then direct anaconda to use then
> as-is.  A common pitfall is people passing --noformat for the /
> volume definition, which can result in an unusable system.

Another major use is for /home or data partitions.  That way, they end
up in your /etc/fstab after installation saving you a step later on.

> After discussing the issues for a while, we came up with:
> (1) Add a new option to the %pre script definition called
> --mountpoint=PATH.  A pre script defined this way would be treated
> as a volume preparation script and would executed after other %pre
> scripts lacking the --mountpoint parameter.
> (2) Volume preparation scripts must prepare only a single mount
> point. On success, they should exit with a status of 0.
> (3) Any storage command used for / with the --noformat option would
> require a '%pre --mountpoint=/' script.  If the script is missing or
> the exit code is non-zero, installation would stop.

More generally, any mount point given with --noformat would first be
checked against the list of mountpoints that must be formatted (I think
that's just / for now).  If found in that list, anaconda would then
check to see if a %pre --mountpoint= script existed and if it returned
0.  Only after that would it continue with the kickstart installation.

I had also been thinking about making these scripts execute-on-demand.
That is, they wouldn't run until anaconda found a kickstart command
referencing the mount point.  However, that seems likely to lead to
errors for reasons I can't quite put my finger on.

This is the best idea I've heard so far for how to fix this problem.  My
one concern is that it's too complicated of a fix, but again I can't put
my finger on why.

- Chris

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