FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 11-18-2010, 07:06 PM
Chris Lumens
 
Default 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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 11-18-2010, 08:00 PM
Bill Nottingham
 
Default Proposal for --noformat handling

David Cantrell (dcantrell@redhat.com) said:
> 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.
>
> 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.
>
> Obviously, this doesn't prevent people from creating '%pre
> --mountpoint=/' scripts that just have "exit 0" as the only line,
> but that's NOTABUG.

I'm not clear here how you need this level of complexity just to
get --noformat volumes mounted. I feel like I'm missing some critical
underlying information.

Bill

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 11-18-2010, 08:09 PM
Chris Lumens
 
Default Proposal for --noformat handling

> I'm not clear here how you need this level of complexity just to
> get --noformat volumes mounted. I feel like I'm missing some critical
> underlying information.

For a long time now, we've been telling people that anaconda/kickstart's
not going to grow an option for every single mkfs feature there is.
They need to use %pre to create the filesystems and then specify them in
kickstart with --noformat. People seem to be happy with that as it lets
them do whatever they want.

On the other hand, sometimes we get bug reports from people who have
chosen to reuse their existing installation's / in a new installation,
but do not format it. This is either through --noformat or through the
UI. dlehman has a patch to make sure / is formatted, but that will kill
the advantages of the above paragraph.

So, we need a way to have --noformat work for the first group while
still failing for the second group.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 11-19-2010, 03:02 PM
David Lehman
 
Default Proposal for --noformat handling

On Thu, 2010-11-18 at 15:06 -0500, Chris Lumens wrote:
> > 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 problem, I think, is that these guys are leaving their volume groups
and logical volumes active after creating them in %pre and we don't
handle that very well since we usually start with an disassembled
storage stack.

Dave

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 11-22-2010, 02:02 AM
Bill Nottingham
 
Default Proposal for --noformat handling

Chris Lumens (clumens@redhat.com) said:
> For a long time now, we've been telling people that anaconda/kickstart's
> not going to grow an option for every single mkfs feature there is.
> They need to use %pre to create the filesystems and then specify them in
> kickstart with --noformat. People seem to be happy with that as it lets
> them do whatever they want.

That I understand.

> On the other hand, sometimes we get bug reports from people who have
> chosen to reuse their existing installation's / in a new installation,
> but do not format it. This is either through --noformat or through the
> UI. dlehman has a patch to make sure / is formatted, but that will kill
> the advantages of the above paragraph.

This I don't - isn't this best treated as just user error?

Bill

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 11-22-2010, 12:41 PM
Chris Lumens
 
Default Proposal for --noformat handling

> The problem, I think, is that these guys are leaving their volume groups
> and logical volumes active after creating them in %pre and we don't
> handle that very well since we usually start with an disassembled
> storage stack.

Oh, good call. I asked for the kickstart file on the Fedora bug about
this so we can make sure that's the problem there too.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 11-22-2010, 04:04 PM
David Lehman
 
Default Proposal for --noformat handling

On Mon, 2010-11-22 at 08:41 -0500, Chris Lumens wrote:
> > The problem, I think, is that these guys are leaving their volume groups
> > and logical volumes active after creating them in %pre and we don't
> > handle that very well since we usually start with an disassembled
> > storage stack.
>
> Oh, good call. I asked for the kickstart file on the Fedora bug about
> this so we can make sure that's the problem there too.

In the process of this image install stuff I've had to improve
DeviceTree's ability to detect already-active lvm, so this will be a
non-issue in rawhide pretty soon.

Dave


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 11-23-2010, 06:38 PM
David Cantrell
 
Default Proposal for --noformat handling

On 11/21/2010 05:02 PM, Bill Nottingham wrote:

Chris Lumens (clumens@redhat.com) said:

For a long time now, we've been telling people that anaconda/kickstart's
not going to grow an option for every single mkfs feature there is.
They need to use %pre to create the filesystems and then specify them in
kickstart with --noformat. People seem to be happy with that as it lets
them do whatever they want.


That I understand.


On the other hand, sometimes we get bug reports from people who have
chosen to reuse their existing installation's / in a new installation,
but do not format it. This is either through --noformat or through the
UI. dlehman has a patch to make sure / is formatted, but that will kill
the advantages of the above paragraph.


This I don't - isn't this best treated as just user error?


The way we currently do things, yes. I think what clumens and I were
discussing was shifting the --noformat option from "do not format this
volume" to "do not format this volume, but if I also provide specific
instructions on how that volume is to be formatted, you can run those".
So we still get the traditional handling of --noformat, but also add
in this capability for users to override anaconda's formatting code.


It help us with the bug reports we get from users who need bizarre
format requirements or who want to specify other options to mke2fs and
so on, but it also gives us a permanent workaround for letting users
experiment with new filesystem types for / before we have formatting
code in anaconda.


--
David Cantrell <dcantrell@redhat.com>
Red Hat / Honolulu, HI

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

Thread Tools




All times are GMT. The time now is 10:14 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org