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!
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
On Mon, 2017-07-03 at 09:57 +0300, Artem Bityutskiy wrote:
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!
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
+1 to this idea, would be great to be included by default, and to have with diagnostic tools
Thank you for sharing
Z
2017-07-04 8:24 GMT+02:00 jkonecny@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
On Mon, 2017-07-03 at 09:57 +0300, Artem Bityutskiy wrote:
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!
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
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
On 4.7.2017 08:24, jkonecny@redhat.com wrote:
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
On Mon, 2017-07-03 at 09:57 +0300, Artem Bityutskiy wrote:
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!
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Fri, 2017-07-14 at 11:29 +0200, Radek Vykydal wrote:
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.
On 18.8.2017 14:50, Artem Bityutskiy wrote:
On Fri, 2017-07-14 at 11:29 +0200, Radek Vykydal wrote:
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
anaconda-devel@lists.stg.fedoraproject.org