Folks Is there a way to reboot and have a script run without intervention. During initial setup, I'd like to avoid the manual actions of logging on as root and executing a command, but instead have that command run without intervention. The output of the command would still show up on the terminal that initiated the reboot. Security is not a concern here. And I don't want to invoke high-powered functions like "jumpstart". David
On Wed, 28 Oct 2020 16:34:32 -0700 david wrote:> Is there a way to reboot and have a script run without > intervention.rc.local -- Can we uninstall 2020 and install it again? This one has a virus. MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
At 04:47 PM 10/28/2020, Frank Cox wrote:>On Wed, 28 Oct 2020 16:34:32 -0700 >david wrote: > > > Is there a way to reboot and have a script run without > > intervention. > >rc.local > >--Alas, I think rc.local has become irrelevant with systemd, which is most Linux distros is the way forward.
--On Wednesday, October 28, 2020 5:34 PM -0700 david <david at daku.org> wrote:> During initial setup, I'd like to avoid the manual actions of logging on > as root and executing a command, but instead have that command run > without intervention."During initial setup" is vague. Lots of stuff happens during startup. With systemd, you can control what triggers your script to run. Does it need the filesystems up? Does it need networking? This will be a part of your systemd unit file.> The output of the command would still show up on the terminal that > initiated the reboot.This one might be hard. Is there a way to know where a reboot command came from? Does the kernel or systemd save this somewhere?
At 07:10 PM 10/28/2020, Kenneth Porter wrote:>--On Wednesday, October 28, 2020 5:34 PM -0700 david <david at daku.org> wrote: > >>During initial setup, I'd like to avoid the manual actions of logging on >>as root and executing a command, but instead have that command run >>without intervention. > >"During initial setup" is vague. Lots of stuff happens during >startup. With systemd, you can control what triggers your script to >run. Does it need the filesystems up? Does it need networking? This >will be a part of your systemd unit file. > >>The output of the command would still show up on the terminal that >>initiated the reboot. > >This one might be hard. Is there a way to know where a reboot >command came from? Does the kernel or systemd save this somewhere?By "initial setup", I meant during the initial install of the operating system, starting from "net-install". Maybe one user is defined. The reboot command is issued from a script that was initiated by hand.
On 10/28/20 4:34 PM, david wrote:> During initial setup, I'd like to avoid the manual actions of logging > on as root and executing a command, but instead have that command run > without intervention.? The output of the command would still show up > on the terminal that initiated the reboot.Having read this thread, I still can't tell *when* you want a script to run.? If you want it to run during the initial install, then I can't make any sense of how that relates to a reboot. If you want to run a command during the setup, then provide a kickstart file with a %post section: https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#chapter-6-post-installation-script If you want to run a command after rebooting and display the command output on the console, then use the openvt command, possibly with the -w flag: https://linux.die.net/man/1/openvt> Security is not a concern here.? And I don't want to invoke > high-powered functions like "jumpstart".If you mean kickstart: I'm pretty sure that's your only option for running commands during the installation.
On Wed, Oct 28, 2020 at 04:34:32PM -0700, david wrote:> During initial setup, I'd like to avoid the manual actions of[...]> Security is not a concern here. And I don't want to invoke > high-powered functions like "jumpstart".Can you explain the use case a little more here? It may actually _really_ be worth your time to learn about kickstart -- it's highly powerful, but not really "high-powered" in a difficultly sense. -- Matthew Miller <mattdm at fedoraproject.org> Fedora Project Leader