Re: Proposal for --noformat handling

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

 



> 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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux