Chris.. >>>> I already gave you the proper grub.conf 2nd entry. That's what you got wrong and why it won't boot. It's pointing to the wrong root which is what I said from the beginning. <<<
Right, but I'm not sure what I need to correct in the Install GUI for the 2nd OS Install process in order to match what you posted. In particular, do I simply select the sda for the boot partition? On Fri, Dec 27, 2013 at 7:30 PM, Chris Murphy <li...@colorremedies.com> wrote: > > On Dec 27, 2013, at 4:40 PM, bruce <badoug...@gmail.com> wrote: > >> Hi Chris. >> >> Thanks fo.r the reply >> . >> The principle reason for doing/testing dual boot is to have the >> ability to be able to do a remote reinstall for a fresh OS on a remote >> box. If you know of a way to accomplish that, I'm more than willing to >> hear it!! > > USB key imaged with netinstl ISO is has a way to confirm it hasn't been > altered, and a VNC and kickstart capability for unattended installation over > a network. > > >> Everything I've seen regarding doing reinstalling of OS, requires >> having access to the box, with fresh media. > > Well it is easier to do it that way, completely remote setups have more fail > points. You ultimately need the ability to get physical access to it anyway - > hard drive dies, etc. > >> >> This is really intended to allow me to detect if the "base/master" >> system has been hacked, and then to immeadiately switch to the minimal >> OS/system, which would then invoke a netinstall for the hacked >> system/OS to have a clean system. > > I'm not a security expert or a lawyer, but this use case seems specious. > Firstly, in any business use case it seems to me the machine needs to be > preserved for forensic analysis. You shouldn't just obliterate it and > reinstall, that's destruction of evidence, it very well could be illegal. > > In any case, if the primary system is hacked, the minimal system is also > likely compromised. If it has write once media in it, like a CD/DVD, you can > create known reliable media that can boot a live environment from which you > can ATA Secure Erase the drives, and reinstall a system. But this isn't dual > boot in the sense that there are two OS's on one physical drive. > >> So, the test is to have a dual Centos process, which is what I'm >> looking to implement right now. > > Maybe someone with more security and VM experience can speak up. But it seems > to me that the setup and management of all of this is a lot easier if you > have a rather locked down baremetal setup, and then you have one or more > virtual machines that are more "exposed". And if they get hacked, it's a ton > more straightforward to preserve its virtual disk, point the VM to a backup > image, replace keys and passwords, and get it up and running in minutes vs > hours for a truly clean install of a baremetal setup. > > >> Here are the current steps I've used, feel free to tell me where I've >> gone off track. > > I already gave you the proper grub.conf 2nd entry. That's what you got wrong > and why it won't boot. It's pointing to the wrong root which is what I said > from the beginning. > > > > Chris Murphy > > -- > users mailing list > users@lists.fedoraproject.org > 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 users@lists.fedoraproject.org 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
