RFE: Support kickstart files in rescue mode
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Good morning folks,
the requested feature will be useful for automation. I'm targeting rescue mode
test automation but it can be used for automating common tasks in rescue mode if
one is administering pool of machines. The minimal ks.cfg file is:
- ---
lang en_US
keyboard us
network --device eth0 --bootproto dhcp --onboot yes
cdrom
#url --url http://path/to/stage2.img

%post --nochroot
mkdir -p /mnt/sysimage
mount -t ext3 /dev/sda1 /mnt/sysimage
echo "system is mounted" >> /mnt/sysimage/root/rescue.log
%end

%post
cat /etc/fedora-release >> /root/rescue.log
uname -a >> /root/rescue.log
%end

%post --nochroot
echo "system will be unmounted" >> /mnt/sysimage/root/rescue.log
umount /mnt/sysimage
%end


Everything before %post is currently parsed and understood by the loader.
Currently kickstart is supported only when booting in rescue mode with the
"nomount" option because the changes are smaller and easier to review. Patches
are coming shortly. Please review them.

Thanks,
Alexander.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFIhtouhmd3WOiFct4RCkR4AJ4xjiaqU3xXvKWo926h7i mt08SjKgCdHk0N
VeNCqaqqftkdoDltYdkfA1o=
=fMwO
-----END PGP SIGNATURE-----

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

RFE: Support kickstart files in rescue mode
 

On Wed, 2008-07-23 at 10:13 +0300, Alexander Todorov wrote:
> Everything before %post is currently parsed and understood by the loader.
> Currently kickstart is supported only when booting in rescue mode with the
> "nomount" option because the changes are smaller and easier to review. Patches
> are coming shortly. Please review them.

I'm not entirely convinced on this front -- this then requires a lot of
manual work to find and mount the rootfs and thus avoids testing one of
the biggest parts of rescue mode (finding and mounting the root). We're
probably better off doing the mount through the normal paths if you're
doing kickstart rescue mode

Jeremy

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

RFE: Support kickstart files in rescue mode
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jeremy Katz wrote:
|
| I'm not entirely convinced on this front -- this then requires a lot of
| manual work to find and mount the rootfs and thus avoids testing one of
| the biggest parts of rescue mode (finding and mounting the root). We're
| probably better off doing the mount through the normal paths if you're
| doing kickstart rescue mode
|

Leaving aside the mount of the root fs we can test other stuff: FirstAidKit
(although you can test it by other means also), if the rescue environment is
sane (e.g. bash is there), if we can chroot into the system (given we've mounted
that by hand), network setup, anything else people will do if they boot with
nomount and start poking around in the shell.

I agree with doing the mount through the current code but how do we cleanly
avoid the places where the user is asked to make a decision:
Mount: Read/Write, Read only, Skip ?
What partition contains the root fs?

Any assumption to answers of these questions will be generally wrong and will
break on different systems. The only possible way I see is to add additional
command{s} to kickstart which answer them. E.g.

In the case of a single command:
parttomount --dev /dev/sda1 --mode r --fstype ext3 --path /mnt/sysimage

I'm OK with adding this to kickstart but wanted to see what others think.

Thanks,
Alexander.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFIhzJfhmd3WOiFct4RCk7yAJ9CM9RbPlvTk8dSlCPALF cDcMZeNgCfT6TM
pwbH+SWiwiewaAmXAl0BfHk=
=6Ggg
-----END PGP SIGNATURE-----

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

RFE: Support kickstart files in rescue mode
 

On Wed, 2008-07-23 at 16:30 +0300, Alexander Todorov wrote:
> Jeremy Katz wrote:
> | I'm not entirely convinced on this front -- this then requires a lot of
> | manual work to find and mount the rootfs and thus avoids testing one of
> | the biggest parts of rescue mode (finding and mounting the root). We're
> | probably better off doing the mount through the normal paths if you're
> | doing kickstart rescue mode
>
> Leaving aside the mount of the root fs we can test other stuff: FirstAidKit
> (although you can test it by other means also), if the rescue environment is
> sane (e.g. bash is there), if we can chroot into the system (given we've mounted
> that by hand), network setup, anything else people will do if they boot with
> nomount and start poking around in the shell.
>
> I agree with doing the mount through the current code but how do we cleanly
> avoid the places where the user is asked to make a decision:
> Mount: Read/Write, Read only, Skip ?

Either a new directive or just doing the sane default (r/w) if we're in
kickstart mode. Arguably, we should have a 'rescue' directive that acts
like upgrade and others and kicks us into rescue mode so that you can
have everything for rescue mode specified in the ks.cfg. Then you'd
have
rescue
rescue --nomount
rescue --romount

> What partition contains the root fs?

The easy answer is that we just do the first. And then if we think that
caring about multiple roots[1] is important, then we should do it in a
way that generalizes and also helps the upgrade case

Jeremy

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

RFE: Support kickstart files in rescue mode
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jeremy Katz wrote:
|
| Either a new directive or just doing the sane default (r/w) if we're in
| kickstart mode. Arguably, we should have a 'rescue' directive that acts
| like upgrade and others and kicks us into rescue mode so that you can
| have everything for rescue mode specified in the ks.cfg. Then you'd
| have
| rescue
| rescue --nomount
| rescue --romount
|
|> What partition contains the root fs?
|
| The easy answer is that we just do the first. And then if we think that
| caring about multiple roots[1] is important, then we should do it in a
| way that generalizes and also helps the upgrade case
|

What I lean towards is the following:
1) Add a 'rescue' directive in kickstart for the sake of completeness (see
above), but without any options.

2) Add a new directive in kickstart so it describes what partitions and where to
mount them (as described in previous e-mail).

3) In rescue mode based on 2) try to mount the partitions.

4) If 2) is not present in kickstart then try some defaults if they fail, don't
try anything else.

5) Execute the %post scripts after everything is done.

Upgrade mode can also be modified to use 2) if present.

It's a bigger change than the proposed one but I'd prefer adding all the bits
now instead of doing the defaults (or --nomount, --romount) for rescue mode and
later (not known when) adding the support for multiple roots.

Thanks,
Alexander.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFIiC/ehmd3WOiFct4RCgajAJ9WHuXO01T6R04LiflZQoUNdbpKdwCfd pyI
xwgEInIyLlhTFxoW+4heSfI=
=+vF+
-----END PGP SIGNATURE-----

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

RFE: Support kickstart files in rescue mode
 

Jeremy Katz wrote:

On Wed, 2008-07-23 at 16:30 +0300, Alexander Todorov wrote:

Jeremy Katz wrote:
| I'm not entirely convinced on this front -- this then requires a lot of
| manual work to find and mount the rootfs and thus avoids testing one of
| the biggest parts of rescue mode (finding and mounting the root). We're
| probably better off doing the mount through the normal paths if you're
| doing kickstart rescue mode

Leaving aside the mount of the root fs we can test other stuff: FirstAidKit
(although you can test it by other means also), if the rescue environment is
sane (e.g. bash is there), if we can chroot into the system (given we've mounted
that by hand), network setup, anything else people will do if they boot with
nomount and start poking around in the shell.

I agree with doing the mount through the current code but how do we cleanly
avoid the places where the user is asked to make a decision:
Mount: Read/Write, Read only, Skip ?


Either a new directive or just doing the sane default (r/w) if we're in
kickstart mode. Arguably, we should have a 'rescue' directive that acts
like upgrade and others and kicks us into rescue mode so that you can
have everything for rescue mode specified in the ks.cfg. Then you'd
have
rescue
rescue --nomount
rescue --romount


In the syslinux/isolinux/pxelinux/grub menu?




What partition contains the root fs?


The easy answer is that we just do the first. And then if we think that
caring about multiple roots[1] is important, then we should do it in a
way that generalizes and also helps the upgrade case


/mnt/target{1,,,n} for as many as there are. Hopefully, /etc/fstab is
useful for matching bits?


Probably, a system I had containing something like six installs of
Nahant/FedoraCore/OpenSUSE/SLES is about as extreme as it gets.


Presumably, a user could be given the opportunity at boot time to say
"rescue=<some_identifier>" in which case the question is simplified.


I think mounts should be ro unless the user says otherwise. I was
distressed and/or annoyed a while ago to find Linux mounting my Windows
partition rw. "Allow me to write to it if say I I want to, but not
otherwise."






Jeremy

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




--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

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

RFE: Support kickstart files in rescue mode
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

John Summerfield wrote:
|> Either a new directive or just doing the sane default (r/w) if we're in
|> kickstart mode. Arguably, we should have a 'rescue' directive that acts
|> like upgrade and others and kicks us into rescue mode so that you can
|> have everything for rescue mode specified in the ks.cfg. Then you'd
|> have
|> rescue
|> rescue --nomount
|> rescue --romount
|
| In the syslinux/isolinux/pxelinux/grub menu?
|

In kickstart (ks.cfg)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFIiI/yhmd3WOiFct4RComRAJ9iHjlyKWmNNNCCiQ/yk7HefohMvgCfdh9l
ePoO2CxojNANnBKZ0wk/JvI=
=83v0
-----END PGP SIGNATURE-----

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

RFE: Support kickstart files in rescue mode
 

On Thu, 2008-07-24 at 10:31 +0300, Alexander Todorov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> Jeremy Katz wrote:
> | Either a new directive or just doing the sane default (r/w) if we're in
> | kickstart mode. Arguably, we should have a 'rescue' directive that acts
> | like upgrade and others and kicks us into rescue mode so that you can
> | have everything for rescue mode specified in the ks.cfg. Then you'd
> | have
> | rescue
> | rescue --nomount
> | rescue --romount
> |
> |> What partition contains the root fs?
> |
> | The easy answer is that we just do the first. And then if we think that
> | caring about multiple roots[1] is important, then we should do it in a
> | way that generalizes and also helps the upgrade case
> |
>
> What I lean towards is the following:
> 1) Add a 'rescue' directive in kickstart for the sake of completeness (see
> above), but without any options.

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.

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

Jeremy

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

RFE: Support kickstart files in rescue mode
 

-----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.

| 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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

RFE: Support kickstart files in rescue mode
 

Alexander Todorov wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jeremy Katz wrote:
|
| I'm not entirely convinced on this front -- this then requires a lot of
| manual work to find and mount the rootfs and thus avoids testing one of
| the biggest parts of rescue mode (finding and mounting the root). We're
| probably better off doing the mount through the normal paths if you're
| doing kickstart rescue mode
|

Leaving aside the mount of the root fs we can test other stuff: FirstAidKit


Firstaidkit needs the installed system. If it does not have it, it will act differently. It actually looks for the system in /mnt/sysimage and goes from there. The reason for this is that it is rescuing the system that is mounted in /mnt/sysimage and actually needs it to do so. In this same train of though I can think of various important things to test with respect to finding the installed system.

1. To actually recognize an installed system when important stuff is missing.
2. To recognize the prefered installed system (default behavior) when the user has more than one system installed.
those are the two I can think of off the top of my head.


(although you can test it by other means also), if the rescue
environment is
sane (e.g. bash is there), if we can chroot into the system (given we've
mounted
that by hand), network setup, anything else people will do if they boot
with

nomount and start poking around in the shell.


What bothers me here is that (mounted by hand). Instead of going around the fact that anaconda askes question I would devise a way of automating answering the questions. This will provide a way to get to the rescue env, while testing whatever the questions do (like find the installed system).



I agree with doing the mount through the current code but how do we cleanly
avoid the places where the user is asked to make a decision:
Mount: Read/Write, Read only, Skip ?


Just put an:
if inRescueMode:
if noUserInput
answer = "Default"
else
answer = UserInput



What partition contains the root fs?


As a test mechanism, you should know the right answer for this. This could be handled in the same way as the question answering.



Any assumption to answers of these questions will be generally wrong and


Ok, I totally missed something here. If you are testing you should know the answers for this. no? If you don't how would you be sure that a given behavior is correct or incorrect. like when I anser yes and it mounts the wrong disk?


will
break on different systems. The only possible way I see is to add
additional

command{s} to kickstart which answer them. E.g.

In the case of a single command:
parttomount --dev /dev/sda1 --mode r --fstype ext3 --path /mnt/sysimage


Yep, but this is just going around the autodetecting functionality. This could be easily done by answering "no" in the "do you want to mount previous system" question. And them mounting everything in the post section. Additionally it avoids adding more stuff to pykickstart. (less is more)



I'm OK with adding this to kickstart but wanted to see what others think.


Im not saying don't add to kickstart. Im just don't add too much. And I think adding a line where you specify partition stuff is not good. I would much rather add a `mount /dev/sda1 /mnt/sysimage` in the post section.



Thanks,
Alexander.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFIhzJfhmd3WOiFct4RCk7yAJ9CM9RbPlvTk8dSlCPALF cDcMZeNgCfT6TM
pwbH+SWiwiewaAmXAl0BfHk=
=6Ggg
-----END PGP SIGNATURE-----

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list