Auto OS Install Process

[bruce]

Hi,

In order to do an OS install, you need to have an external media to
start the install process. This media provides a "base"/small system
that you can then use to do a larger netinstall, or a larger update
process to get the drive/system setup the way you want. All of the
larger system install data/packages/etc can come from the http/net
install process.

In most (all) cases I've seen, the process is then to take/remove the
CD from the system, followed by a restart, where the system OS on the
drive then gets invoked.

So this process requires some manual interaction.

Here's my question:

Is there a way to do the same basic process, except to always leave
the CD in, and to then be able to "switch" the system, so it "knows"
which media to install from.

If this can be done, one can setup a system with a basic cd that will,
when run, create/start the basic OS install, but then not be used any
other time... This could allow for an auto/programatic approach to be
able to do a remote/auto OS install.

Is there any other way that this might be accomplished?

Thoughts/Comments?

thanks

[Suvayu Ali]

On Thu, Dec 26, 2013 at 09:01:46AM -0500, bruce wrote:
> Here's my question:
>
> Is there a way to do the same basic process, except to always leave
> the CD in, and to then be able to "switch" the system, so it "knows"
> which media to install from.
>
> If this can be done, one can setup a system with a basic cd that will,
> when run, create/start the basic OS install, but then not be used any
> other time... This could allow for an auto/programatic approach to be
> able to do a remote/auto OS install.

https://fedoraproject.org/wiki/Anaconda/Kickstart

[bruce]

Hey Suvayu,

Thanks, but in looking at kickstarter, it doesn't allow as to how
you'd be able to set the system to boot into one or the other OS
partitions.

What I'd really like is the ability to set two partitions

PartitionA - base/minimal OS
  -used to just do a netinstall to setup partitionB with the real OS, and
   the actual system that's going to contain the VM
 -when this partition is invoked, it automatically does a netinstall to
  set up partitionB
 -after doing the netinstall, the process then resets whatever is needed
  to then boot into partitionB

PartitionB - complete/full OS, along with all the rest of the system/env files
  -created by the netinstall process from Partition A, the minimal install/OS
  -has the ability to also do a "netinstall" to reinstall the OS for the
   partition A OS
 -has the ability to set the system, so the next reboot, it goes into
Partition A

This kind of approach would allow me to have full/complete control, to
be able to do remote installs of the OS on the different partitions,
as well as control which partition gets booted on reboot.

And of course,  a given OS could be updated using the normal yum processes.

does this make sense.

Thoughts/Comments ??

Thanks

On Thu, Dec 26, 2013 at 10:04 AM, Suvayu Ali
 wrote:
> On Thu, Dec 26, 2013 at 09:01:46AM -0500, bruce wrote:
> > Here's my question:
> >
> > Is there a way to do the same basic process, except to always leave
> > the CD in, and to then be able to "switch" the system, so it "knows"
> > which media to install from.
> >
> > If this can be done, one can setup a system with a basic cd that will,
> > when run, create/start the basic OS install, but then not be used any
> > other time... This could allow for an auto/programatic approach to be
> > able to do a remote/auto OS install.
>
> https://fedoraproject.org/wiki/Anaconda/Kickstart
>
> --
> Suvayu
> Open source is the future. It sets us free.
>
> users mailing list
> [e-mail]
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org

[Suvayu Ali]

Hi Bruce,

Please read the mailing list guidelines (linked from the list
signature); top-posting is frowned up on on this list.

Now some comments...

On Thu, Dec 26, 2013 at 10:14:52AM -0500, bruce wrote:
> What I'd really like is the ability to set two partitions
>
> PartitionA - base/minimal OS
>   -used to just do a netinstall to setup partitionB with the real OS, and
>    the actual system that's going to contain the VM
>  -when this partition is invoked, it automatically does a netinstall to
>   set up partitionB
>  -after doing the netinstall, the process then resets whatever is needed
>   to then boot into partitionB
>
> PartitionB - complete/full OS, along with all the rest of the system/env files
>   -created by the netinstall process from Partition A, the minimal install/OS
>   -has the ability to also do a "netinstall" to reinstall the OS for the
>    partition A OS
>  -has the ability to set the system, so the next reboot, it goes into
> Partition A
> From what I understand you expect on partitition dedicated for

installation of other partitions.  I do not understand why you need
that.  Kickstart files offers you a completely automated way to install
from disk images on local disks, over the network, and repositories.
You can put your image on a partition, and treat that as your
PartitionA.  You could then use different kickstart files to setup
systems with different customisations.  Doesn't that work?

I maybe missing something, maybe you want to do this remotely.  In that
case it should still be possible, but you would need a separate "command
& control" machine for that.  I believe many vendors like Dell, IBM
offer such solutions.  I have personally seen a Dell system with 10 real
servers being installed & setup this way.  If your setup is at home, you
could repurpose a old machine for this purpose.

Hope this helps,

[bruce]

Hey Suvayu,

Not to be insensitive.. but I've had left-post/right-post/top-post
args etc for damn near 30 years...

My motto - if I create the post, I'll post/add to it as i see fit.
Everyon else is welcome to reply, or not!!

Now that that's out of the way...

My need is in the case a system gets hacked/corrupted. If the system
is remote, I want a method of being able to get into the hacked
system, and to have it then restore the running/corrupted partition
from the "clean" partition.

This means I need to be able to install dual OS, as well as have a
method of being able to switch the boot process as required.

No, this isn't foolproof to eleminate hacking, but it does allow me to
then be able to more easlity/quickly recover in the event the process
detects the master partition as being hacked.

So, in my mind, I'll have dual OS/partitions
paritionA
  -minimal OS
  -used to do a netinstall/reinstall of a clean OS into partitionB
  -so when the system boots up into this partition, it will auto
   perform the netinstall process into the partitionB for the
   reinstall

partitionB
  -the master partition/OS
  -contains the working/real OS/env of the system
  -also able to invoke a netinstall process to reinstall partitionA as
   required
  -has the ability to toggle between the partitions
  -has the ability to set itself as the default OS/partition

So in my mind, this really should be a matter of doing a dual
install/boot process, and then determining how one can
programatically/automatically set whatever function/switch has to be
set to switch between the partitions/OS on reboot of the system.

Keep in mind, once the system is created/provisioned, all of this is
being handled remotely, via ssh.

thanks

On Thu, Dec 26, 2013 at 12:21 PM, Suvayu Ali
 wrote:
> Hi Bruce,
>
> Please read the mailing list guidelines (linked from the list
> signature); top-posting is frowned up on on this list.
>
> Now some comments...
>
> On Thu, Dec 26, 2013 at 10:14:52AM -0500, bruce wrote:
> > What I'd really like is the ability to set two partitions
> >
> > PartitionA - base/minimal OS
> >   -used to just do a netinstall to setup partitionB with the real OS, and
> >    the actual system that's going to contain the VM
> >  -when this partition is invoked, it automatically does a netinstall to
> >   set up partitionB
> >  -after doing the netinstall, the process then resets whatever is needed
> >   to then boot into partitionB
> >
> > PartitionB - complete/full OS, along with all the rest of the system/env files
> >   -created by the netinstall process from Partition A, the minimal install/OS
> >   -has the ability to also do a "netinstall" to reinstall the OS for the
> >    partition A OS
> >  -has the ability to set the system, so the next reboot, it goes into
> > Partition A
>
> From what I understand you expect on partitition dedicated for
> installation of other partitions.  I do not understand why you need
> that.  Kickstart files offers you a completely automated way to install
> from disk images on local disks, over the network, and repositories.
> You can put your image on a partition, and treat that as your
> PartitionA.  You could then use different kickstart files to setup
> systems with different customisations.  Doesn't that work?
>
> I maybe missing something, maybe you want to do this remotely.  In that
> case it should still be possible, but you would need a separate "command
> & control" machine for that.  I believe many vendors like Dell, IBM
> offer such solutions.  I have personally seen a Dell system with 10 real
> servers being installed & setup this way.  If your setup is at home, you
> could repurpose a old machine for this purpose.
>
> Hope this helps,
>
> --
> Suvayu
> Open source is the future. It sets us free.
>
> users mailing list
> [e-mail]
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org

[Pete Travis]

On Dec 26, 2013 10:52 AM, "bruce"  wrote:
> Hey Suvayu,
>
> Not to be insensitive.. but I've had left-post/right-post/top-post
> args etc for damn near 30 years...
>
> My motto - if I create the post, I'll post/add to it as i see fit.
> Everyon else is welcome to reply, or not!!
>
> Now that that's out of the way...
>
> My need is in the case a system gets hacked/corrupted. If the system
> is remote, I want a method of being able to get into the hacked
> system, and to have it then restore the running/corrupted partition
> from the "clean" partition.
>
> This means I need to be able to install dual OS, as well as have a
> method of being able to switch the boot process as required.
>
> No, this isn't foolproof to eleminate hacking, but it does allow me to
> then be able to more easlity/quickly recover in the event the process
> detects the master partition as being hacked.
>
> So, in my mind, I'll have dual OS/partitions
> paritionA
>   -minimal OS
>   -used to do a netinstall/reinstall of a clean OS into partitionB
>   -so when the system boots up into this partition, it will auto
>    perform the netinstall process into the partitionB for the
>    reinstall
>
> partitionB
>   -the master partition/OS
>   -contains the working/real OS/env of the system
>   -also able to invoke a netinstall process to reinstall partitionA as
>    required
>   -has the ability to toggle between the partitions
>   -has the ability to set itself as the default OS/partition
>
> So in my mind, this really should be a matter of doing a dual
> install/boot process, and then determining how one can
> programatically/automatically set whatever function/switch has to be
> set to switch between the partitions/OS on reboot of the system.
>
> Keep in mind, once the system is created/provisioned, all of this is
> being handled remotely, via ssh.
>
> thanks

If we assume that you have functioning ssh access to the machine, you can
change the default boot option for grub in /etc/default/grub (and run
grub2-mkconfig -o /boot/path/to/grub.cfg)

With ssh access and a UEFI system, you can use `efibootmgr` to set the
firmware boot order or next boot.

If you don't have functioning ssh access, you'll need hardware with remote
access firmware ie. IPMI. Alternatively, you can get a KVM with remote
access features - usually vnc, look for KVM over IP - or some remote hands
to operate a keyboard for you.

If the goal is to reinstall from the alternative environment, you want the
installer , not a minimal install.  You should read about medialess
installs or pxe installation in the Fedora Installation Guide. These can
also be used in rescue mode. Either way, kickstart sounds like a good idea
for you.

BTW, mailing list guidelines have existed as long as mailing lists.  You
are more likely to get good help if you follow those guidelines that make
it easier for your helpers to follow the discussion, but the choice between
your convenience and clarity for your readers is your own choice.

--Pete

[bruce]

Hi Pete.

Thanks for the reply. If I understand your following statement::
> If we assume that you have functioning ssh access to the machine, you can
> change the default boot option for grub in /etc/default/grub (and run
> grub2-mkconfig -o /boot/path/to/grub.cfg)

this implies that for each installed OS, there will be a separate
"/boot" in the OS tree, but if I'm in partitionA, how do I set the dir
for the boot path for the partitionB, which wouldn't be mounted at
that time... Or would it be?

I've been looking for a sample/turotial that lays this out that I can
examine, and haven't found one yet.

Thanks Much!!!

On Thu, Dec 26, 2013 at 1:32 PM, Pete Travis  wrote:
> On Dec 26, 2013 10:52 AM, "bruce"  wrote:
> > Hey Suvayu,
> >
> > Not to be insensitive.. but I've had left-post/right-post/top-post
> > args etc for damn near 30 years...
> >
> > My motto - if I create the post, I'll post/add to it as i see fit.
> > Everyon else is welcome to reply, or not!!
> >
> > Now that that's out of the way...
> >
> > My need is in the case a system gets hacked/corrupted. If the system
> > is remote, I want a method of being able to get into the hacked
> > system, and to have it then restore the running/corrupted partition
> > from the "clean" partition.
> >
> > This means I need to be able to install dual OS, as well as have a
> > method of being able to switch the boot process as required.
> >
> > No, this isn't foolproof to eleminate hacking, but it does allow me to
> > then be able to more easlity/quickly recover in the event the process
> > detects the master partition as being hacked.
> >
> > So, in my mind, I'll have dual OS/partitions
> > paritionA
> >   -minimal OS
> >   -used to do a netinstall/reinstall of a clean OS into partitionB
> >   -so when the system boots up into this partition, it will auto
> >    perform the netinstall process into the partitionB for the
> >    reinstall
> >
> > partitionB
> >   -the master partition/OS
> >   -contains the working/real OS/env of the system
> >   -also able to invoke a netinstall process to reinstall partitionA as
> >    required
> >   -has the ability to toggle between the partitions
> >   -has the ability to set itself as the default OS/partition
> >
> > So in my mind, this really should be a matter of doing a dual
> > install/boot process, and then determining how one can
> > programatically/automatically set whatever function/switch has to be
> > set to switch between the partitions/OS on reboot of the system.
> >
> > Keep in mind, once the system is created/provisioned, all of this is
> > being handled remotely, via ssh.
> >
> > thanks
>
> If we assume that you have functioning ssh access to the machine, you can
> change the default boot option for grub in /etc/default/grub (and run
> grub2-mkconfig -o /boot/path/to/grub.cfg)
>
> With ssh access and a UEFI system, you can use `efibootmgr` to set the
> firmware boot order or next boot.
>
> If you don't have functioning ssh access, you'll need hardware with remote
> access firmware ie. IPMI. Alternatively, you can get a KVM with remote
> access features - usually vnc, look for KVM over IP - or some remote hands
> to operate a keyboard for you.
>
> If the goal is to reinstall from the alternative environment, you want the
> installer , not a minimal install.  You should read about medialess installs
> or pxe installation in the Fedora Installation Guide. These can also be used
> in rescue mode. Either way, kickstart sounds like a good idea for you.
>
> BTW, mailing list guidelines have existed as long as mailing lists.  You are
> more likely to get good help if you follow those guidelines that make it
> easier for your helpers to follow the discussion, but the choice between
> your convenience and clarity for your readers is your own choice.
>
> --Pete
>
> --
> users mailing list
> [e-mail]
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org

[Pete Travis]

> On Thu, Dec 26, 2013 at 1:32 PM, Pete Travis  wrote:
> > On Dec 26, 2013 10:52 AM, "bruce"  wrote:
> > > Hey Suvayu,
> > >
> > > Not to be insensitive.. but I've had left-post/right-post/top-post
> > > args etc for damn near 30 years...
> > >
> > > My motto - if I create the post, I'll post/add to it as i see fit.
> > > Everyon else is welcome to reply, or not!!
> > >
> > > Now that that's out of the way...
> > >
> > > My need is in the case a system gets hacked/corrupted. If the system
> > > is remote, I want a method of being able to get into the hacked
> > > system, and to have it then restore the running/corrupted partition
> > > from the "clean" partition.
> > >
> > > This means I need to be able to install dual OS, as well as have a
> > > method of being able to switch the boot process as required.
> > >
> > > No, this isn't foolproof to eleminate hacking, but it does allow me to
> > > then be able to more easlity/quickly recover in the event the process
> > > detects the master partition as being hacked.
> > >
> > > So, in my mind, I'll have dual OS/partitions
> > > paritionA
> > >   -minimal OS
> > >   -used to do a netinstall/reinstall of a clean OS into partitionB
> > >   -so when the system boots up into this partition, it will auto
> > >    perform the netinstall process into the partitionB for the
> > >    reinstall
> > >
> > > partitionB
> > >   -the master partition/OS
> > >   -contains the working/real OS/env of the system
> > >   -also able to invoke a netinstall process to reinstall partitionA as
> > >    required
> > >   -has the ability to toggle between the partitions
> > >   -has the ability to set itself as the default OS/partition
> > >
> > > So in my mind, this really should be a matter of doing a dual
> > > install/boot process, and then determining how one can
> > > programatically/automatically set whatever function/switch has to be
> > > set to switch between the partitions/OS on reboot of the system.
> > >
> > > Keep in mind, once the system is created/provisioned, all of this is
> > > being handled remotely, via ssh.
> > >
> > > thanks
> >
> > If we assume that you have functioning ssh access to the machine, you

can
> > change the default boot option for grub in /etc/default/grub (and run
> > grub2-mkconfig -o /boot/path/to/grub.cfg)
> >
> > With ssh access and a UEFI system, you can use `efibootmgr` to set the
> > firmware boot order or next boot.
> >
> > If you don't have functioning ssh access, you'll need hardware with

remote
> > access firmware ie. IPMI. Alternatively, you can get a KVM with remote
> > access features - usually vnc, look for KVM over IP - or some remote

hands
> > to operate a keyboard for you.
> >
> > If the goal is to reinstall from the alternative environment, you want

the
> > installer , not a minimal install.  You should read about medialess

installs
> > or pxe installation in the Fedora Installation Guide. These can also be

used
> > in rescue mode. Either way, kickstart sounds like a good idea for you.
> >
> > BTW, mailing list guidelines have existed as long as mailing lists.

You are
> > more likely to get good help if you follow those guidelines that make it
> > easier for your helpers to follow the discussion, but the choice between
> > your convenience and clarity for your readers is your own choice.
> >
> > --Pete

On Dec 26, 2013 11:56 AM, "bruce"  wrote:
> Hi Pete.
>
> Thanks for the reply. If I understand your following statement::
> > If we assume that you have functioning ssh access to the machine, you

can
> > change the default boot option for grub in /etc/default/grub (and run
> > grub2-mkconfig -o /boot/path/to/grub.cfg)
>
> this implies that for each installed OS, there will be a separate
> "/boot" in the OS tree, but if I'm in partitionA, how do I set the dir
> for the boot path for the partitionB, which wouldn't be mounted at
> that time... Or would it be?
>
> I've been looking for a sample/turotial that lays this out that I can
> examine, and haven't found one yet.
>
> Thanks Much!!!

Let us move away from the term "partition", please. A typical installation
has multiple partitions, and even if yours do not, you are describing an
*installation *, not a storage volume.

If you have a second installation, grub2-mkconfig will find it and create
the menu entries for you.

As I noted, a second minimal installation does not do what you describe you
want to accomplish, reinstallation. The installer handles installation, so
you want to boot that. If you want to be able to reinstall *or* access the
main installation's data from a clean environment, you can use the
installer's rescue mode.

--Pete

[bruce]

Pete,

umm - regarding partition, i was under the impression that an OS
install can have multiple "partitions"

In my case though, I want to have the ability to set/invoke whatever
process needs to occur so I can programatically set the boot OS. All
of this will occur via ssh, so the process won't be accessing the gui,
to select the menus.

so for :
> As I noted, a second minimal installation does not do what you describe you
> want to accomplish, reinstallation. The installer handles installation, so
> you want to boot that. If you want to be able to reinstall *or* access the
> main installation's data from a clean environment, you can use the
> installer's rescue mode.

I'd want the 2nd installation to be able to immeadiately, upon boot
up, to then go do a netinstall, where it then reinstalls the 1st OS,
and I need to do this in a auto/programatic process. I'm not seeing
where the rescue mode process applies here.

On Thu, Dec 26, 2013 at 2:13 PM, Pete Travis  wrote:
> > On Thu, Dec 26, 2013 at 1:32 PM, Pete Travis  wrote:
> > > On Dec 26, 2013 10:52 AM, "bruce"  wrote:
> > > > Hey Suvayu,
> > > >
> > > > Not to be insensitive.. but I've had left-post/right-post/top-post
> > > > args etc for damn near 30 years...
> > > >
> > > > My motto - if I create the post, I'll post/add to it as i see fit.
> > > > Everyon else is welcome to reply, or not!!
> > > >
> > > > Now that that's out of the way...
> > > >
> > > > My need is in the case a system gets hacked/corrupted. If the system
> > > > is remote, I want a method of being able to get into the hacked
> > > > system, and to have it then restore the running/corrupted partition
> > > > from the "clean" partition.
> > > >
> > > > This means I need to be able to install dual OS, as well as have a
> > > > method of being able to switch the boot process as required.
> > > >
> > > > No, this isn't foolproof to eleminate hacking, but it does allow me to
> > > > then be able to more easlity/quickly recover in the event the process
> > > > detects the master partition as being hacked.
> > > >
> > > > So, in my mind, I'll have dual OS/partitions
> > > > paritionA
> > > >   -minimal OS
> > > >   -used to do a netinstall/reinstall of a clean OS into partitionB
> > > >   -so when the system boots up into this partition, it will auto
> > > >    perform the netinstall process into the partitionB for the
> > > >    reinstall
> > > >
> > > > partitionB
> > > >   -the master partition/OS
> > > >   -contains the working/real OS/env of the system
> > > >   -also able to invoke a netinstall process to reinstall partitionA as
> > > >    required
> > > >   -has the ability to toggle between the partitions
> > > >   -has the ability to set itself as the default OS/partition
> > > >
> > > > So in my mind, this really should be a matter of doing a dual
> > > > install/boot process, and then determining how one can
> > > > programatically/automatically set whatever function/switch has to be
> > > > set to switch between the partitions/OS on reboot of the system.
> > > >
> > > > Keep in mind, once the system is created/provisioned, all of this is
> > > > being handled remotely, via ssh.
> > > >
> > > > thanks
> > >
> > > If we assume that you have functioning ssh access to the machine, you
> > > can
> > > change the default boot option for grub in /etc/default/grub (and run
> > > grub2-mkconfig -o /boot/path/to/grub.cfg)
> > >
> > > With ssh access and a UEFI system, you can use `efibootmgr` to set the
> > > firmware boot order or next boot.
> > >
> > > If you don't have functioning ssh access, you'll need hardware with
> > > remote
> > > access firmware ie. IPMI. Alternatively, you can get a KVM with remote
> > > access features - usually vnc, look for KVM over IP - or some remote
> > > hands
> > > to operate a keyboard for you.
> > >
> > > If the goal is to reinstall from the alternative environment, you want
> > > the
> > > installer , not a minimal install.  You should read about medialess
> > > installs
> > > or pxe installation in the Fedora Installation Guide. These can also be
> > > used
> > > in rescue mode. Either way, kickstart sounds like a good idea for you.
> > >
> > > BTW, mailing list guidelines have existed as long as mailing lists.  You
> > > are
> > > more likely to get good help if you follow those guidelines that make it
> > > easier for your helpers to follow the discussion, but the choice between
> > > your convenience and clarity for your readers is your own choice.
> > >
> > > --Pete
>
> On Dec 26, 2013 11:56 AM, "bruce"  wrote:
> > Hi Pete.
> >
> > Thanks for the reply. If I understand your following statement::
> > > If we assume that you have functioning ssh access to the machine, you
> > > can
> > > change the default boot option for grub in /etc/default/grub (and run
> > > grub2-mkconfig -o /boot/path/to/grub.cfg)
> >
> > this implies that for each installed OS, there will be a separate
> > "/boot" in the OS tree, but if I'm in partitionA, how do I set the dir
> > for the boot path for the partitionB, which wouldn't be mounted at
> > that time... Or would it be?
> >
> > I've been looking for a sample/turotial that lays this out that I can
> > examine, and haven't found one yet.
> >
> > Thanks Much!!!
>
> Let us move away from the term "partition", please. A typical installation
> has multiple partitions, and even if yours do not, you are describing an
> *installation *, not a storage volume.
>
> If you have a second installation, grub2-mkconfig will find it and create
> the menu entries for you.
>
> As I noted, a second minimal installation does not do what you describe you
> want to accomplish, reinstallation. The installer handles installation, so
> you want to boot that. If you want to be able to reinstall *or* access the
> main installation's data from a clean environment, you can use the
> installer's rescue mode.
>
> --Pete
>
> --
> users mailing list
> [e-mail]
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org

[Pete Travis]

On Dec 26, 2013 12:33 PM, "bruce"  wrote:
> Pete,
>
> umm - regarding partition, i was under the impression that an OS
> install can have multiple "partitions"

Yes, this is part of why I suggested not using the term "partition" to
describe an installation.
> In my case though, I want to have the ability to set/invoke whatever
> process needs to occur so I can programatically set the boot OS. All
> of this will occur via ssh, so the process won't be accessing the gui,
> to select the menus.

Yes, this is where you ssh in and set the default grub entry to boot.
> so for :
> > As I noted, a second minimal installation does not do what you describe

you
> > want to accomplish, reinstallation. The installer handles installation,

so
> > you want to boot that. If you want to be able to reinstall *or* access

the
> > main installation's data from a clean environment, you can use the
> > installer's rescue mode.
>
> I'd want the 2nd installation to be able to immeadiately, upon boot
> up, to then go do a netinstall, where it then reinstalls the 1st OS,
> and I need to do this in a auto/programatic process. I'm not seeing
> where the rescue mode process applies here.

The only reason I could conceive of you wanting to boot a minimal
installation instead of the actual installer was for non-installing
activity. If you want to do a netinstall, boot the installer.  If you want
to do a netinstall *without* the installer, I won't be able to help.

I've tried to give you at least an overview of how you might accomplish
what you want.  If you need further guidance, please read over my responses
again, consider them, and ask specific questions where you need more help.
It isn't productive to repeat myself in a text conversation, especially
where previous responses are preserved above the current one.

--Pete
> On Thu, Dec 26, 2013 at 2:13 PM, Pete Travis  wrote:
> > > On Thu, Dec 26, 2013 at 1:32 PM, Pete Travis

wrote:
> > > > On Dec 26, 2013 10:52 AM, "bruce"  wrote:
> > > > > Hey Suvayu,
> > > > >
> > > > > Not to be insensitive.. but I've had left-post/right-post/top-post
> > > > > args etc for damn near 30 years...
> > > > >
> > > > > My motto - if I create the post, I'll post/add to it as i see fit.
> > > > > Everyon else is welcome to reply, or not!!
> > > > >
> > > > > Now that that's out of the way...
> > > > >
> > > > > My need is in the case a system gets hacked/corrupted. If the system
> > > > > is remote, I want a method of being able to get into the hacked
> > > > > system, and to have it then restore the running/corrupted partition
> > > > > from the "clean" partition.
> > > > >
> > > > > This means I need to be able to install dual OS, as well as have a
> > > > > method of being able to switch the boot process as required.
> > > > >
> > > > > No, this isn't foolproof to eleminate hacking, but it does allow me

to
> > > > > then be able to more easlity/quickly recover in the event the

process
> > > > > detects the master partition as being hacked.
> > > > >
> > > > > So, in my mind, I'll have dual OS/partitions
> > > > > paritionA
> > > > >   -minimal OS
> > > > >   -used to do a netinstall/reinstall of a clean OS into partitionB
> > > > >   -so when the system boots up into this partition, it will auto
> > > > >    perform the netinstall process into the partitionB for the
> > > > >    reinstall
> > > > >
> > > > > partitionB
> > > > >   -the master partition/OS
> > > > >   -contains the working/real OS/env of the system
> > > > >   -also able to invoke a netinstall process to reinstall partitionA

as
> > > > > required
> > > > >   -has the ability to toggle between the partitions
> > > > >   -has the ability to set itself as the default OS/partition
> > > > >
> > > > > So in my mind, this really should be a matter of doing a dual
> > > > > install/boot process, and then determining how one can
> > > > > programatically/automatically set whatever function/switch has to be
> > > > > set to switch between the partitions/OS on reboot of the system.
> > > > >
> > > > > Keep in mind, once the system is created/provisioned, all of this is
> > > > > being handled remotely, via ssh.
> > > > >
> > > > > thanks
> > > >
> > > > If we assume that you have functioning ssh access to the machine, you
> > > > can
> > > > change the default boot option for grub in /etc/default/grub (and run
> > > > grub2-mkconfig -o /boot/path/to/grub.cfg)
> > > >
> > > > With ssh access and a UEFI system, you can use `efibootmgr` to set

the
> > > > firmware boot order or next boot.
> > > >
> > > > If you don't have functioning ssh access, you'll need hardware with
> > > > remote
> > > > access firmware ie. IPMI. Alternatively, you can get a KVM with

remote
> > > > access features - usually vnc, look for KVM over IP - or some remote
> > > > hands
> > > > to operate a keyboard for you.
> > > >
> > > > If the goal is to reinstall from the alternative environment, you

want
> > > > the
> > > > installer , not a minimal install.  You should read about medialess
> > > > installs
> > > > or pxe installation in the Fedora Installation Guide. These can also

be
> > > > used
> > > > in rescue mode. Either way, kickstart sounds like a good idea for

you.
> > > > BTW, mailing list guidelines have existed as long as mailing lists.

You
> > > > are
> > > > more likely to get good help if you follow those guidelines that

make it
> > > > easier for your helpers to follow the discussion, but the choice

between
> > > > your convenience and clarity for your readers is your own choice.
> > > >
> > > > --Pete
> >
> > On Dec 26, 2013 11:56 AM, "bruce"  wrote:
> > > Hi Pete.
> > >
> > > Thanks for the reply. If I understand your following statement::
> > > > If we assume that you have functioning ssh access to the machine, you
> > > > can
> > > > change the default boot option for grub in /etc/default/grub (and run
> > > > grub2-mkconfig -o /boot/path/to/grub.cfg)
> > >
> > > this implies that for each installed OS, there will be a separate
> > > "/boot" in the OS tree, but if I'm in partitionA, how do I set the dir
> > > for the boot path for the partitionB, which wouldn't be mounted at
> > > that time... Or would it be?
> > >
> > > I've been looking for a sample/turotial that lays this out that I can
> > > examine, and haven't found one yet.
> > >
> > > Thanks Much!!!
> >
> > Let us move away from the term "partition", please. A typical

installation
> > has multiple partitions, and even if yours do not, you are describing an
> > *installation *, not a storage volume.
> >
> > If you have a second installation, grub2-mkconfig will find it and

create
> > the menu entries for you.
> >
> > As I noted, a second minimal installation does not do what you describe

you
> > want to accomplish, reinstallation. The installer handles installation,

so
> > you want to boot that. If you want to be able to reinstall *or* access

the
> > main installation's data from a clean environment, you can use the
> > installer's rescue mode.
> >
> > --Pete
> >
> > --
> > users mailing list
> > [e-mail]
> > To unsubscribe or change subscription options:
> > https://admin.fedoraproject.org/mailman/listinfo/users
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> > Have a question? Ask away: http://ask.fedoraproject.org
>
> --
> users mailing list
> [e-mail]
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org