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 > Ubuntu > Ubuntu User

 
 
LinkBack Thread Tools
 
Old 07-25-2008, 10:34 AM
Joel Andres Granados
 
Default RFE: Support kickstart files in rescue mode

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

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


--
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
 
Old 07-25-2008, 10:34 AM
Joel Andres Granados
 
Default 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



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


--
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
 
Old 07-25-2008, 11:28 AM
Alexander Todorov
 
Default RFE: Support kickstart files in rescue mode

-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFIibjPhmd3WOiFct4RCu8OAKC6f94lEPFJyRKfVCPicO wWgn6fSgCgsmEe
gPSjs4kWDvmQoy0Q6zOGXU4=
=O5Ml
-----END PGP SIGNATURE-----

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-25-2008, 11:30 AM
Alexander Todorov
 
Default RFE: Support kickstart files in rescue mode

-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFIiblnhmd3WOiFct4RCgS7AJ4368dtc1n6cs9kHmcbjR DjJfM1PQCgoLyp
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
 
Old 07-25-2008, 11:36 AM
Joel Andres Granados
 
Default RFE: Support kickstart files in rescue mode

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

iD8DBQFIiblnhmd3WOiFct4RCgS7AJ4368dtc1n6cs9kHmcbjR DjJfM1PQCgoLyp
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


--
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
 
Old 07-25-2008, 11:41 AM
Joel Andres Granados
 
Default RFE: Support kickstart files in rescue mode

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


--
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
 
Old 07-25-2008, 11:44 AM
Joel Andres Granados
 
Default RFE: Support kickstart files in rescue mode

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


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


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

Thread Tools




All times are GMT. The time now is 07:45 AM.

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