Discussion:
Automated rescue mode
Artem Bityutskiy
2017-07-03 06:57:36 UTC
Permalink
Hi,

I am using the stock Fedora 25 OS installer as a "service OS", just
because it is convenient and I do not have to build my own. Should
something bad happen to a host in my automation system, I just boot the
host into the Fedora installer's kernel/initramfs over network and have
a decent rescue environment.

The Fedora OS installer is based on Anaconda. It can find and mount the
"sysroot" to "/mnt/sysimage", which is also very convenient.

Now, I wanted my "service OS" to automatically do this - find the
sysroot and properly mount it without any questions asked. I could not
find the "right" way of doing this, and ended up with a hacky trick.

I am sharing the trick in case someone else will be googling for it in
the future. And of course I'd appreciate better ideas.

First of all, boot anaconda into the rescue mode, by adding
'inst.rescue' to kernel boot parameters.

I also have a bunch of 'inst.ks' and 'inst.stage2' and dracut
networking parameters.

And yes, I have a very small minimal KS file too, which only configures
repositories and some network-related stuff. Does not do anything about
partitions or packages.

Then I put this to my %pre in order to make anaconda proceed with
mounting the sysroot:

tmux send-keys -t anaconda -- 1 C-m

It is hackish, but works. It basically sends key "1" to anaconda, so
anaconda selects the "Continue" choice, and proceeds with mounting
sysroot.

This is not the first time I use anaconda's tmux terminal to achieve my
goals with anaconda. E.g., I use it for capturing anaconda's VGA output
remotely.

So thanks for using tmux in anaconda - very handy!
j***@redhat.com
2017-07-04 06:24:15 UTC
Permalink
Hello,

First of all, nice solution for your issue and thank you for sharing it
here. IMHO it could be really valuable for others.

The "Automated rescue" looks to me like an interesting idea. It could
be enhancement of the existing "rescue" kickstart command.
Unfortunately, we are swamped with other work right now but we will
look on that in the future.

Please file an RFE bug to bugzilla and write there how do you think
this feature should work. It will be better for addressing future
questions and implementing the best solution.

Jirka
Post by Artem Bityutskiy
Hi,
I am using the stock Fedora 25 OS installer as a "service OS", just
because it is convenient and I do not have to build my own. Should
something bad happen to a host in my automation system, I just boot the
host into the Fedora installer's kernel/initramfs over network and have
a decent rescue environment.
The Fedora OS installer is based on Anaconda. It can find and mount the
"sysroot" to "/mnt/sysimage", which is also very convenient.
Now, I wanted my "service OS" to automatically do this - find the
sysroot and properly mount it without any questions asked. I could not
find the "right" way of doing this, and ended up with a hacky trick.
I am sharing the trick in case someone else will be googling for it in
the future. And of course I'd appreciate better ideas.
First of all, boot anaconda into the rescue mode, by adding
'inst.rescue' to kernel boot parameters.
I also have a bunch of 'inst.ks' and 'inst.stage2' and dracut
networking parameters.
And yes, I have a very small minimal KS file too, which only
configures
repositories and some network-related stuff. Does not do anything about
partitions or packages. 
Then I put this to my %pre in order to make anaconda proceed with
tmux send-keys -t anaconda -- 1 C-m
It is hackish, but works. It basically sends key "1" to anaconda, so
anaconda selects the "Continue" choice, and proceeds with mounting
sysroot.
This is not the first time I use anaconda's tmux terminal to achieve my
goals with anaconda. E.g., I use it for capturing anaconda's VGA output
remotely.
So thanks for using tmux in anaconda - very handy!
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Zoltan Hoppar
2017-07-04 11:10:01 UTC
Permalink
+1 to this idea, would be great to be included by default, and to have
with diagnostic tools

Thank you for sharing

Z
Post by j***@redhat.com
Hello,
First of all, nice solution for your issue and thank you for sharing it
here. IMHO it could be really valuable for others.
The "Automated rescue" looks to me like an interesting idea. It could
be enhancement of the existing "rescue" kickstart command.
Unfortunately, we are swamped with other work right now but we will
look on that in the future.
Please file an RFE bug to bugzilla and write there how do you think
this feature should work. It will be better for addressing future
questions and implementing the best solution.
Jirka
Post by Artem Bityutskiy
Hi,
I am using the stock Fedora 25 OS installer as a "service OS", just
because it is convenient and I do not have to build my own. Should
something bad happen to a host in my automation system, I just boot the
host into the Fedora installer's kernel/initramfs over network and have
a decent rescue environment.
The Fedora OS installer is based on Anaconda. It can find and mount the
"sysroot" to "/mnt/sysimage", which is also very convenient.
Now, I wanted my "service OS" to automatically do this - find the
sysroot and properly mount it without any questions asked. I could not
find the "right" way of doing this, and ended up with a hacky trick.
I am sharing the trick in case someone else will be googling for it in
the future. And of course I'd appreciate better ideas.
First of all, boot anaconda into the rescue mode, by adding
'inst.rescue' to kernel boot parameters.
I also have a bunch of 'inst.ks' and 'inst.stage2' and dracut
networking parameters.
And yes, I have a very small minimal KS file too, which only
configures
repositories and some network-related stuff. Does not do anything about
partitions or packages.
Then I put this to my %pre in order to make anaconda proceed with
tmux send-keys -t anaconda -- 1 C-m
It is hackish, but works. It basically sends key "1" to anaconda, so
anaconda selects the "Continue" choice, and proceeds with mounting
sysroot.
This is not the first time I use anaconda's tmux terminal to achieve my
goals with anaconda. E.g., I use it for capturing anaconda's VGA output
remotely.
So thanks for using tmux in anaconda - very handy!
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
--
PGP: 06853DF7
Radek Vykydal
2017-07-14 09:29:39 UTC
Permalink
Actually I found out that kickstart rescue command is intended to work
non-interactively (unless asking to choose from multiple roots found or
for encrypted device passphrase).

http://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#rescue

I filed a BZ with a patch attached to fix it for the expected behavior
https://bugzilla.redhat.com/show_bug.cgi?id=1470989

Radek
Post by j***@redhat.com
Hello,
First of all, nice solution for your issue and thank you for sharing it
here. IMHO it could be really valuable for others.
The "Automated rescue" looks to me like an interesting idea. It could
be enhancement of the existing "rescue" kickstart command.
Unfortunately, we are swamped with other work right now but we will
look on that in the future.
Please file an RFE bug to bugzilla and write there how do you think
this feature should work. It will be better for addressing future
questions and implementing the best solution.
Jirka
Post by Artem Bityutskiy
Hi,
I am using the stock Fedora 25 OS installer as a "service OS", just
because it is convenient and I do not have to build my own. Should
something bad happen to a host in my automation system, I just boot the
host into the Fedora installer's kernel/initramfs over network and have
a decent rescue environment.
The Fedora OS installer is based on Anaconda. It can find and mount the
"sysroot" to "/mnt/sysimage", which is also very convenient.
Now, I wanted my "service OS" to automatically do this - find the
sysroot and properly mount it without any questions asked. I could not
find the "right" way of doing this, and ended up with a hacky trick.
I am sharing the trick in case someone else will be googling for it in
the future. And of course I'd appreciate better ideas.
First of all, boot anaconda into the rescue mode, by adding
'inst.rescue' to kernel boot parameters.
I also have a bunch of 'inst.ks' and 'inst.stage2' and dracut
networking parameters.
And yes, I have a very small minimal KS file too, which only
configures
repositories and some network-related stuff. Does not do anything about
partitions or packages.
Then I put this to my %pre in order to make anaconda proceed with
tmux send-keys -t anaconda -- 1 C-m
It is hackish, but works. It basically sends key "1" to anaconda, so
anaconda selects the "Continue" choice, and proceeds with mounting
sysroot.
This is not the first time I use anaconda's tmux terminal to achieve my
goals with anaconda. E.g., I use it for capturing anaconda's VGA output
remotely.
So thanks for using tmux in anaconda - very handy!
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
_______________________________________________
Anaconda-devel-list mailing list
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Artem Bityutskiy
2017-08-18 12:50:13 UTC
Permalink
Post by Radek Vykydal
Actually I found out that kickstart rescue command is intended to work
non-interactively (unless asking to choose from multiple roots found or
for encrypted device passphrase).
http://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#rescu
e
I filed a BZ with a patch attached to fix it for the expected
behavior
https://bugzilla.redhat.com/show_bug.cgi?id=1470989
Sorry for late reply, but thanks for these changes.

Artem.
Radek Vykydal
2017-08-25 08:59:21 UTC
Permalink
Post by Artem Bityutskiy
Post by Radek Vykydal
Actually I found out that kickstart rescue command is intended to work
non-interactively (unless asking to choose from multiple roots found or
for encrypted device passphrase).
http://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#rescu
e
I filed a BZ with a patch attached to fix it for the expected
behavior
https://bugzilla.redhat.com/show_bug.cgi?id=1470989
Sorry for late reply, but thanks for these changes.
Artem.
Thank you for testing the fix!

Radek

Loading...