Alexander Todorov wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Jeremy Katz wrote:
|
| I really like my suggested way better -- it makes things a little bit
| more in line with other things we do in kickstart and also makes it so
| that the default (of booting with 'linux rescue' or having 'rescue' in
| your ks.cfg) matches the same thing you'd get just hitting enter in an
| interactive rescue mode.
|
Hmm, I really do not understand how is it different (adding back the
rescue options)
ks.cfg: rescue == try some sane defaults (as in the UI)
ks.cfg: rescue --nomount == linux rescue nomount
ks.cfg: rescue --romount == try the defaults but read only
The proposed 'mount' command just gives more flexibility. Instead of
mounting
read only under /mnt/sysimage the user can specify what device to be
mounted
where and how. It's extra functionality which does not conflict with the
current
one.
Which can also be done without the kickstart line. Just answer no to the "do you want to mount" question. and then do anything you want in the post.
Additionally ignoring most of the other ks options (if present) would be something I would be comfortable with.
| And then, if we really care about multiple roots (and I still don't
| think I do that much), something like 'rootpart sda3' so that you only
| have to specify the actual partition/LV/whatnot rather than anything
| more complicated
|
I don't think another line more in a kickstart file is more complicated.
It's
more flexible though. It's arguable if this is more useful as we don't
really
know what people do or expect from rescue mode.
As it seems that only the 'rescue [--nomount|--romount]' code will be
accepted
at this time I'll rework the patches and then come back later to the
'mount'
command.
Regards,
Alexander.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org
iD8DBQFIiZcVhmd3WOiFct4RCiZhAKCKO0YfsxW2ijxE4+0j5u/wcuvCQQCgoi7y
pkRhQp6IDTRVMEDZ7D25B9Y=
=Gwik
-----END PGP SIGNATURE-----
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
--
Joel Andres Granados
Red Hat / Brno, Czech Republic
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
