-----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.
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
-----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.
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
-----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.
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:
- 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
-----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.
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@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Jeremy Katz wrote:
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:
- 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
I'd still like to avoid this. the multiple root thing can be worked around with stuff that is put in the post section anyway.
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
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
-----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)
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
This seems to go hand in hand with my "less is more" idea :)
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
Which would mean changing the findExistingRoots thing we have in there.
Jeremy
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Joel Andres Granados wrote: | Which would mean changing the findExistingRoots thing we have in there. |
disks = upgrade.findExistingRoots(anaconda, upgradeany = 1)
if not disks: ~ root = None elif (len(disks) == 1): <-- ADD HERE or anaconda.isKickstart ~ root = disks[0] else: ~ <... skip ...> ~ root = disks[choice]
Isn't that enough? I think it is.
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
iD8DBQFIhzJfhmd3WOiFct4RCk7yAJ9CM9RbPlvTk8dSlCPALFcDcMZeNgCfT6TM 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
To begin. Some thought on the whole kickstart rescue: I think all this is relevant for testing only. As a user I cannot imagine of a use case were I would automate the rescue environment. First of all, going to the trouble of making a ks file and pointing the boot to the file just seems way too much work, specially having firstaidkit. Second, most of the time I don't really know whats wrong and I would like to go in an poke around. And even when I know exactly what is wrong, I feel more comfortable editing the files in the rescue mode, then telling anaconda what to do through a ks file. I think the sane way of doing a rescue mode is putting the user in shell, providing firstaidkit and letting the user interact with a very friendly, easy to use rescue app. kickstarting the rescue mode will just increase the possibility of the user shooting himself in the foot.
Testing is different. You would want to poke at the rescue environment automatically to see what wrong. For this reason, I think its a good idea. ... ok enough :)
Alexander Todorov wrote:
-----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
It might be easier but it does ignore an important part of the rescue mode, finding the installed system. This is an important part of rescue mode and can also be testable. And if you want to do any kind of automation must be considered (IMO).
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
iD8DBQFIhtouhmd3WOiFct4RCkR4AJ4xjiaqU3xXvKWo926h7imt08SjKgCdHk0N VeNCqaqqftkdoDltYdkfA1o= =fMwO -----END PGP SIGNATURE-----
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Joel Andres Granados wrote: | To begin. Some thought on the whole kickstart rescue: | I think all this is relevant for testing only. As a user I cannot | imagine of a use case were I would automate the rescue environment.
Maybe try imagine that as a sysadmin? I really don't know if it will be useful except for testing but probably nobody knows.
Alexander Todorov wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Joel Andres Granados wrote: | To begin. Some thought on the whole kickstart rescue: | I think all this is relevant for testing only. As a user I cannot | imagine of a use case were I would automate the rescue environment.
Maybe try imagine that as a sysadmin?
Thats what I'm getting at. If you want to make a ks file kind of solution you would: 1. prepare the ks file to fit what you think needs fixing 2. run automated rescue 3. reboot system to see if it worked. 4. repeat until satified.
It would be better if you could see what you are doing, you would still have to do iterations but you could react faster if there is a typo in a command (for example) or if the command you thought was going to fix the issue, didn't. Imagine having a typo in a ks file. You would have to do a lot more than just retyping the command. Also consider the fact that when you are in rescue mode something fishy is happening with the system and it might not respond as it normally does. That in itself increases the probability of something going wrong with the ks file approach.
I really don't know if it will be
useful except for testing but probably nobody knows. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org
iD8DBQFIiblnhmd3WOiFct4RCgS7AJ4368dtc1n6cs9kHmcbjRDjJfM1PQCgoLyp VIUzqOy2d4Za3Dh2w+nsdHc= =p8oV -----END PGP SIGNATURE-----
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
anaconda-devel@lists.stg.fedoraproject.org