Hi - I know I should probably post to centos, but I'm testing this with centos, and then with fedora.
I'm trying to basically do a dual boot test, that will allow me to dual boot into 2 different versions of centos, although, in this case, I'm using the centos 6.5 image.
I went through the process that I've found from different sites/articles, in order to set up the 2 OS installs.
I can boot into the 1st OS. I have screwed something up, as I'm not able to boot into the 2nd OS.
I don't know if I screwed something up during the Install/Creation process via the GUI, or if I've screwed something up during the grub.conf modifications.
Any help/pointers would be greatly appreciated.
Thanks
-------------------------------------
The system setup: -lenovo laptop -250G Drive -Centos 6.5
Steps: -Went through the initial setup for the OS1 -setup the root/backup/home/swap OS2 - master root / 50 boot home /home 10 apps /apps 10 backup /backup 5
set the boot to be on sda1 - as 500M
I then went back and installed the 2nd install of the Centos OS using lv2_root root / 10 boot lv2_home home /home2 5 lv2_apps apps /apps2 5 lv2_backup backup /backup2 5
the boot was set to be the "/" on the sda so it's the same as the 1st.. I also didn't install the bootloader, which was the option on the boot/install page of the GUI for the install process
I then modified the grub.conf page
#boot=/dev/sda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz
hidemenu title Centos (2.6.32-431.e16.x86_64) root (hd0,0) kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 rd_LVM_LV=VolGroup/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-431.e16.x86_64.img
title Centos2 (2.6.32-431.e16.x86_64) root (hd0,1) kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/sda2 initrd /initramfs-2.6.32-431.e16.x86_64.img
====================================
the fdisk -l for the system is :: [root@localhost ~]# fdisk -l
Disk /dev/sda: 250.1 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x77e3ed41
Device Boot Start End Blocks Id System /dev/sda1 * 1 64 512000 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 64 30402 243685376 8e Linux LVM Partition 2 does not end on cylinder boundary.
Disk /dev/mapper/VolGroup-lv_root: 53.7 GB, 53687091200 bytes 255 heads, 63 sectors/track, 6527 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_swap: 4009 MB, 4009754624 bytes 255 heads, 63 sectors/track, 487 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_home: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_backup: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_apps: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical):[root@localhost ~]# fdisk -l
Disk /dev/sda: 250.1 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x77e3ed41
Device Boot Start End Blocks Id System /dev/sda1 * 1 64 512000 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 64 30402 243685376 8e Linux LVM Partition 2 does not end on cylinder boundary.
Disk /dev/mapper/VolGroup-lv_root: 53.7 GB, 53687091200 bytes 255 heads, 63 sectors/track, 6527 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_swap: 4009 MB, 4009754624 bytes 255 heads, 63 sectors/track, 487 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_home: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_backup: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_apps: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_root: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_home: 5242 MB, 5242880000 bytes 255 heads, 63 sectors/track, 637 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_backup: 5242 MB, 5242880000 bytes 255 heads, 63 sectors/track, 637 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_apps: 5242 MB, 5242880000 bytes 255 heads, 63 sectors/track, 637 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_root: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_home: 5242 MB, 5242880000 bytes 255 heads, 63 sectors/track, 637 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_backup: 5242 MB, 5242880000 bytes 255 heads, 63 sectors/track, 637 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_apps: 5242 MB, 5242880000 bytes 255 heads, 63 sectors/track, 637 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
update::
forgot to list the Display/Device page from the GUI/Install OS process
LVM Volume Groups VolGroup 237972 lv2_apps 5000 /apps2 lv2_backup 5000 /backup2 lv2_home 5000 /home2 lv2_root 10000 / lv_apps 10000 /apps lv_backup 10000 /backup lv_home 10000 /home lv_root 51200 / lv_swap 3824 free 127948
Hard Drive
sda sda1 500 /boot ext4 sda2 237974 VolGroup physical volume (LVM)
On Fri, Dec 27, 2013 at 2:34 PM, bruce badouglas@gmail.com wrote:
Hi - I know I should probably post to centos, but I'm testing this with centos, and then with fedora.
I'm trying to basically do a dual boot test, that will allow me to dual boot into 2 different versions of centos, although, in this case, I'm using the centos 6.5 image.
I went through the process that I've found from different sites/articles, in order to set up the 2 OS installs.
I can boot into the 1st OS. I have screwed something up, as I'm not able to boot into the 2nd OS.
I don't know if I screwed something up during the Install/Creation process via the GUI, or if I've screwed something up during the grub.conf modifications.
Any help/pointers would be greatly appreciated.
Thanks
The system setup: -lenovo laptop -250G Drive -Centos 6.5
Steps: -Went through the initial setup for the OS1 -setup the root/backup/home/swap OS2 - master root / 50 boot home /home 10 apps /apps 10 backup /backup 5
set the boot to be on sda1 - as 500M
I then went back and installed the 2nd install of the Centos OS using lv2_root root / 10 boot lv2_home home /home2 5 lv2_apps apps /apps2 5 lv2_backup backup /backup2 5
the boot was set to be the "/" on the sda so it's the same as the 1st.. I also didn't install the bootloader, which was the option on the boot/install page of the GUI for the install process
I then modified the grub.conf page
#boot=/dev/sda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz
hidemenu title Centos (2.6.32-431.e16.x86_64) root (hd0,0) kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 rd_LVM_LV=VolGroup/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-431.e16.x86_64.img
title Centos2 (2.6.32-431.e16.x86_64) root (hd0,1) kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/sda2 initrd /initramfs-2.6.32-431.e16.x86_64.img
====================================
the fdisk -l for the system is :: [root@localhost ~]# fdisk -l
Disk /dev/sda: 250.1 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x77e3ed41
Device Boot Start End Blocks Id System /dev/sda1 * 1 64 512000 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 64 30402 243685376 8e Linux LVM Partition 2 does not end on cylinder boundary.
Disk /dev/mapper/VolGroup-lv_root: 53.7 GB, 53687091200 bytes 255 heads, 63 sectors/track, 6527 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_swap: 4009 MB, 4009754624 bytes 255 heads, 63 sectors/track, 487 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_home: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_backup: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_apps: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical):[root@localhost ~]# fdisk -l
Disk /dev/sda: 250.1 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x77e3ed41
Device Boot Start End Blocks Id System /dev/sda1 * 1 64 512000 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 64 30402 243685376 8e Linux LVM Partition 2 does not end on cylinder boundary.
Disk /dev/mapper/VolGroup-lv_root: 53.7 GB, 53687091200 bytes 255 heads, 63 sectors/track, 6527 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_swap: 4009 MB, 4009754624 bytes 255 heads, 63 sectors/track, 487 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_home: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_backup: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv_apps: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_root: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_home: 5242 MB, 5242880000 bytes 255 heads, 63 sectors/track, 637 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_backup: 5242 MB, 5242880000 bytes 255 heads, 63 sectors/track, 637 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_apps: 5242 MB, 5242880000 bytes 255 heads, 63 sectors/track, 637 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_root: 10.5 GB, 10485760000 bytes 255 heads, 63 sectors/track, 1274 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_home: 5242 MB, 5242880000 bytes 255 heads, 63 sectors/track, 637 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_backup: 5242 MB, 5242880000 bytes 255 heads, 63 sectors/track, 637 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Disk /dev/mapper/VolGroup-lv2_apps: 5242 MB, 5242880000 bytes 255 heads, 63 sectors/track, 637 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
On Dec 27, 2013, at 12:34 PM, bruce badouglas@gmail.com wrote:
Hi - I know I should probably post to centos, but I'm testing this with centos, and then with fedora.
CentOS 6 uses grub legacy. Fedora uses grub2. They are completely different, FYI.
set the boot to be on sda1 - as 500M
In grub legacy that's (hd0,0)
I then went back and installed the 2nd install of the Centos OS using lv2_root root / 10 boot lv2_home home /home2 5 lv2_apps apps /apps2 5 lv2_backup backup /backup2 5
the boot was set to be the "/" on the sda so it's the same as the 1st..
This description isconfusing. You have two / on sda, VolGroup/lv_root and VolGroup-lv2_root. I have no idea what "same as the 1st" means because boot on rootfs is not the same thing as CentOS install #1 which uses a separate /boot on sda1.
title Centos2 (2.6.32-431.e16.x86_64) root (hd0,1)
This is pointing to /dev/sda2 which is LVM. /boot cannot be on LVM using grub legacy, so in fact you ought to use a single shared /boot since they're the same distro.
kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/sda2
The root= entry is completely wrong, you're pointing gruby to an LVM PV rather than to the specific 2nd install root LV.
Chris Murphy
Hi Chris,
For my tests right now, I'm simply trying to get dual Centos up/running,
Based on what you've said, there are errors in what I'm trying to accomplish. You wouldn't have a few mins to walk me through this would you.
I'm convinced that this is doable, and that whatever mistakes I've made are probably subtle/easy to correct.
Do you happen to know of a good tutorial for this that walks through all the steps.
Thanks
On Fri, Dec 27, 2013 at 3:30 PM, Chris Murphy lists@colorremedies.com wrote:
On Dec 27, 2013, at 12:34 PM, bruce badouglas@gmail.com wrote:
Hi - I know I should probably post to centos, but I'm testing this with centos, and then with fedora.
CentOS 6 uses grub legacy. Fedora uses grub2. They are completely different, FYI.
set the boot to be on sda1 - as 500M
In grub legacy that's (hd0,0)
I then went back and installed the 2nd install of the Centos OS using lv2_root root / 10 boot lv2_home home /home2 5 lv2_apps apps /apps2 5 lv2_backup backup /backup2 5
the boot was set to be the "/" on the sda so it's the same as the 1st..
This description isconfusing. You have two / on sda, VolGroup/lv_root and VolGroup-lv2_root. I have no idea what "same as the 1st" means because boot on rootfs is not the same thing as CentOS install #1 which uses a separate /boot on sda1.
title Centos2 (2.6.32-431.e16.x86_64) root (hd0,1)
This is pointing to /dev/sda2 which is LVM. /boot cannot be on LVM using grub legacy, so in fact you ought to use a single shared /boot since they're the same distro.
kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/sda2
The root= entry is completely wrong, you're pointing gruby to an LVM PV rather than to the specific 2nd install root LV.
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
On Dec 27, 2013, at 1:48 PM, bruce badouglas@gmail.com wrote:
Hi Chris,
For my tests right now, I'm simply trying to get dual Centos up/running,
OK but why do it the hard way, instead of putting one of them in a VM? Or better, Fedora 20, and put two CentOS and another Fedora each in their own VM? In that case you don't have to deal with the esoteric, user hostile, world of bootloaders on Linux. You can just get to booting multiple OS's. And they boot faster.
The only reason for dual booting I can think of is expressly to learn about the challenges of getting bootloaders to do dual booting.
Based on what you've said, there are errors in what I'm trying to accomplish. You wouldn't have a few mins to walk me through this would you.
It's a lot more than that I can assure you. It took me more time than I care to admit, and if I could get that time back from the life blood sucking experience it was, I'd probably do that.
remove "hidemenu" so you can see the menu, and duplicate the two entries, changing just the one thing that matters which is the menu entry name, and the root. You do not need separate swaps either.
hidemenu title Centos (2.6.32-431.e16.x86_64) root (hd0,0) kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 rd_LVM_LV=VolGroup/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-431.e16.x86_64.img
title Centos2 (2.6.32-431.e16.x86_64) root (hd0,0) kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/mapper/VolGroup-lv2_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 rd_LVM_LV=VolGroup/lv2_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-431.e16.x86_64.img
I'm convinced that this is doable, and that whatever mistakes I've made are probably subtle/easy to correct.
Do you happen to know of a good tutorial for this that walks through all the steps.
Not really. It's the domain of bad documentation designed for developers, not users. I learned what I learned via immense suffering and blunt contact.
Chris Murphy
Do over, missing new line:
hidemenu title Centos (2.6.32-431.e16.x86_64) root (hd0,0) kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 rd_LVM_LV=VolGroup/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-431.e16.x86_64.img
title Centos2 (2.6.32-431.e16.x86_64) root (hd0,0) kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/mapper/VolGroup-lv2_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 rd_LVM_LV=VolGroup/lv2_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-431.e16.x86_64.img
Probably best to use this one in case email messes up the lines or whatever.
Also note that for grub2, hd0,0 becomes hd0,1. And all the dracut notations are different. Oh, and grub.cfg is no longer supposed to be directly edited, you're supposed to use /etc/default/grub and grub2-mkconfig -o /boot/grub2/grub.cfg which creates grub.cfg from scratch and replaces it based on what it finds installed.
Chris Murphy
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!!
Everything I've seen regarding doing reinstalling of OS, requires having access to the box, with fresh media.
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.
So, the test is to have a dual Centos process, which is what I'm looking to implement right now.
Here are the current steps I've used, feel free to tell me where I've gone off track.
-Centos6.5 -Lenovo -250G Drive
OS1 -insert the centos 6.5 dvd -select the fresh install -basic storage device -Fresh Installation -Create Custom Layout (-Please Select Device)
LVM Volume Groups VolGroup 237972 lv_apps 10000 /apps lv_backup 10000 /backup lv_home 10000 /home lv_root 51200 / lv_swap 3824 free 127948
Hard Drive
sda sda1 500 /boot ext4 sda2 237974 VolGroup physical volume (LVM)
Now, at this point, I get a valid OS/grub.conf
However, when I try to install the 2nd OS is when I run into issues..
So, here's what I'm trying to figure out. When I get to the (Please Select Device) page, what do I have to insert to create the minimal OS/system for the 2nd OS install.
For the 2nd install, I'm looking to implement a system that has the backup/apps/home/root dirs (mt points)
Do I have to have completely separate partitions for each of the OS installs? If I do, how/where do they get created?
I think this is close, but again, without really knowing how to do this, one could spend hours/days on this!
Thanks
On Fri, Dec 27, 2013 at 5:43 PM, Chris Murphy lists@colorremedies.com wrote:
Do over, missing new line:
hidemenu title Centos (2.6.32-431.e16.x86_64) root (hd0,0) kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 rd_LVM_LV=VolGroup/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-431.e16.x86_64.img
title Centos2 (2.6.32-431.e16.x86_64) root (hd0,0) kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/mapper/VolGroup-lv2_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 rd_LVM_LV=VolGroup/lv2_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-431.e16.x86_64.img
Probably best to use this one in case email messes up the lines or whatever.
Also note that for grub2, hd0,0 becomes hd0,1. And all the dracut notations are different. Oh, and grub.cfg is no longer supposed to be directly edited, you're supposed to use /etc/default/grub and grub2-mkconfig -o /boot/grub2/grub.cfg which creates grub.cfg from scratch and replaces it based on what it finds installed.
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
On 12/27/2013 3:15 PM, bruce wrote:
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!!
Everything I've seen regarding doing reinstalling of OS, requires having access to the box, with fresh media.
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.
Please excuse me for late to the party(discussion)
I'm not understanding, Are you saying if you suspect your main install is compromise you can simply reboot into the second OS installed on the same computer? if that is case, my opinion is, the second os can also be compromise and forensics analysis of the whole system would need to be done, for example, reconstructing a breach,etc.
On Dec 27, 2013 4:15 PM, "bruce" badouglas@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!!
Everything I've seen regarding doing reinstalling of OS, requires having access to the box, with fresh media.
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.
So, the test is to have a dual Centos process, which is what I'm looking to implement right now.
I am perpetually curious about this process. How do you intend to invoke a net install from a minimal installation?
--Pete
Pete.
The 1st OS will be the os that gets run, it's the "master".. However if I detect that it's hacked, I want to be able to reinstall the OS.
Noramlly, you'd do that with a cd, and do it manually, but if you don't have access to the box, then what?
My approach is to have a 2nd minimal system/OS that has the only function to invoke a complete/fresh netinstall to restore/refresh the OS on the 1st system.
This allows the 1st OS/system to be completely restored, wiping out any remnants of the hacked process.
At the same time, the master/2nd OS will periodically update/restore the minimal/1st OS by the 2nd OS/system. This process allows the system to be able to be refreshed as required, with a clean OS..
If you have a better approach, I'm open for discussion.
On Fri, Dec 27, 2013 at 7:43 PM, Pete Travis lists@petetravis.com wrote:
On Dec 27, 2013 4:15 PM, "bruce" badouglas@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!!
Everything I've seen regarding doing reinstalling of OS, requires having access to the box, with fresh media.
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.
So, the test is to have a dual Centos process, which is what I'm looking to implement right now.
I am perpetually curious about this process. How do you intend to invoke a net install from a minimal installation?
--Pete
-- 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
On Fri, 27 Dec 2013 19:49:42 -0500 bruce badouglas@gmail.com wrote:
My approach is to have a 2nd minimal system/OS that has the only function to invoke a complete/fresh netinstall to restore/refresh the OS on the 1st system.
How exactly (step by step, please) do you intend to invoke the netinstall from the installed minimal system?
Best, :-) Marko
On Dec 27, 2013 5:49 PM, "bruce" badouglas@gmail.com wrote:
Pete.
The 1st OS will be the os that gets run, it's the "master".. However if I detect that it's hacked, I want to be able to reinstall the OS.
Noramlly, you'd do that with a cd, and do it manually, but if you don't have access to the box, then what?
My approach is to have a 2nd minimal system/OS that has the only function to invoke a complete/fresh netinstall to restore/refresh the OS on the 1st system.
Yes, but how do you plan to actually do it? Do you intend to write your own installation program from scratch? What makes a minimal installation capable of performing a net install?
This allows the 1st OS/system to be completely restored, wiping out any remnants of the hacked process.
At the same time, the master/2nd OS will periodically update/restore the minimal/1st OS by the 2nd OS/system. This process allows the system to be able to be refreshed as required, with a clean OS..
If you have a better approach, I'm open for discussion.
I do, but you don't seem interested. If you want to perform an installation, boot the installer. If you want to install using an alternative boot option instead of with removable media, do a medialess installation. There are instructions and examples in the installation guide.
--Pete
On Dec 27, 2013, at 5:49 PM, bruce badouglas@gmail.com wrote:
Pete.
The 1st OS will be the os that gets run, it's the "master".. However if I detect that it's hacked, I want to be able to reinstall the OS.
What if the drive dies? What method are you going to use to get back up and running as soon as possible? And why is that method invalid for the hacked use case? Why wouldn't you have that drive imaged onto another drive, so that if the first one dies, you can replace it and be up and running quickly? Reinstalling is going to take a while and you have all sorts of unknowns that haven't been figured out. It sounds like a Rube Goldberg contraption that doesn't really meet the first requirement you have, and can't be easily repurposed for other failure cases. So it's a single use kitchen tool that also doesn't work very well. I think you need to rethink your approach.
My approach is to have a 2nd minimal system/OS that has the only function to invoke a complete/fresh netinstall to restore/refresh the OS on the 1st system.
Nope, won't work. 1st system is compromised? The 2nd one must be assumed to be compromised.
This allows the 1st OS/system to be completely restored, wiping out any remnants of the hacked process.
Which as I said before is almost certainly illegal destruction of evidence, you should be asking a lawyer about this.
At the same time, the master/2nd OS will periodically update/restore the minimal/1st OS by the 2nd OS/system. This process allows the system to be able to be refreshed as required, with a clean OS..
This makes no sense.
If you have a better approach, I'm open for discussion.
Well no, you chopped that part of the conversation out entirely, twice for me, no response to Edward's concerns along the same lines
Chris Murphy
Chris.
At the basic level, if I could somehow run a cmd and somehow invoke a "os" install for the existing system, that would be great. IE, if I had an "image" that could be downloaded to get a complete refresh/reinstall that's what I'm looking for.
So, starting from the start, how can I get there, without having access to the system. And I fully recognize that the soln that gets developed will not be perfection.
So, if you want to get together to discuss. Hell, I'll do pizza!
Thanks
On Fri, Dec 27, 2013 at 8:17 PM, Chris Murphy lists@colorremedies.com wrote:
On Dec 27, 2013, at 5:49 PM, bruce badouglas@gmail.com wrote:
Pete.
The 1st OS will be the os that gets run, it's the "master".. However if I detect that it's hacked, I want to be able to reinstall the OS.
What if the drive dies? What method are you going to use to get back up and running as soon as possible? And why is that method invalid for the hacked use case? Why wouldn't you have that drive imaged onto another drive, so that if the first one dies, you can replace it and be up and running quickly? Reinstalling is going to take a while and you have all sorts of unknowns that haven't been figured out. It sounds like a Rube Goldberg contraption that doesn't really meet the first requirement you have, and can't be easily repurposed for other failure cases. So it's a single use kitchen tool that also doesn't work very well. I think you need to rethink your approach.
My approach is to have a 2nd minimal system/OS that has the only function to invoke a complete/fresh netinstall to restore/refresh the OS on the 1st system.
Nope, won't work. 1st system is compromised? The 2nd one must be assumed to be compromised.
This allows the 1st OS/system to be completely restored, wiping out any remnants of the hacked process.
Which as I said before is almost certainly illegal destruction of evidence, you should be asking a lawyer about this.
At the same time, the master/2nd OS will periodically update/restore the minimal/1st OS by the 2nd OS/system. This process allows the system to be able to be refreshed as required, with a clean OS..
This makes no sense.
If you have a better approach, I'm open for discussion.
Well no, you chopped that part of the conversation out entirely, twice for me, no response to Edward's concerns along the same lines
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
On 12/27/2013 5:31 PM, bruce wrote:
At the basic level, if I could somehow run a cmd and somehow invoke a "os" install for the existing system, that would be great. IE, if I had an "image" that could be downloaded to get a complete refresh/reinstall that's what I'm looking for.
So, starting from the start, how can I get there, without having access to the system. And I fully recognize that the soln that gets developed will not be perfection.
So, if you want to get together to discuss. Hell, I'll do pizza!
If you will be in the greater Los Angeles area on Feb 21-23, 2014 you may want to attend SCALE 12X (Southern California Linux Expo), you may acquire the knowledge you seek there.
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!!
Everything I've seen regarding doing reinstalling of OS, requires having access to the box, with fresh media.
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.
So, the test is to have a dual Centos process, which is what I'm looking to implement right now.
Here are the current steps I've used, feel free to tell me where I've gone off track.
-Centos6.5 -Lenovo -250G Drive
OS1 -insert the centos 6.5 dvd -select the fresh install -basic storage device -Fresh Installation -Create Custom Layout
LVM Volume Groups VolGroup 237972 lv2_apps 5000 /apps2 lv2_backup 5000 /backup2 lv2_home 5000 /home2 lv2_root 10000 / lv_apps 10000 /apps lv_backup 10000 /backup lv_home 10000 /home lv_root 51200 / lv_swap 3824 free 127948
Hard Drive
sda sda1 500 /boot ext4 sda2 237974 VolGroup physical volume (LVM)
On Fri, Dec 27, 2013 at 5:36 PM, Chris Murphy lists@colorremedies.com wrote:
On Dec 27, 2013, at 1:48 PM, bruce badouglas@gmail.com wrote:
Hi Chris,
For my tests right now, I'm simply trying to get dual Centos up/running,
OK but why do it the hard way, instead of putting one of them in a VM? Or better, Fedora 20, and put two CentOS and another Fedora each in their own VM? In that case you don't have to deal with the esoteric, user hostile, world of bootloaders on Linux. You can just get to booting multiple OS's. And they boot faster.
The only reason for dual booting I can think of is expressly to learn about the challenges of getting bootloaders to do dual booting.
Based on what you've said, there are errors in what I'm trying to accomplish. You wouldn't have a few mins to walk me through this would you.
It's a lot more than that I can assure you. It took me more time than I care to admit, and if I could get that time back from the life blood sucking experience it was, I'd probably do that.
remove "hidemenu" so you can see the menu, and duplicate the two entries, changing just the one thing that matters which is the menu entry name, and the root. You do not need separate swaps either.
hidemenu title Centos (2.6.32-431.e16.x86_64) root (hd0,0) kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 rd_LVM_LV=VolGroup/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-431.e16.x86_64.img
title Centos2 (2.6.32-431.e16.x86_64) root (hd0,0) kernel /vmlinux-2.6.32-431.e16.x86_64 ro root=/dev/mapper/VolGroup-lv2_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 rd_LVM_LV=VolGroup/lv2_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-431.e16.x86_64.img
I'm convinced that this is doable, and that whatever mistakes I've made are probably subtle/easy to correct.
Do you happen to know of a good tutorial for this that walks through all the steps.
Not really. It's the domain of bad documentation designed for developers, not users. I learned what I learned via immense suffering and blunt contact.
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
On Dec 27, 2013, at 4:40 PM, bruce badouglas@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
On Dec 27, 2013, at 5:30 PM, Chris Murphy lists@colorremedies.com wrote:
On Dec 27, 2013, at 4:40 PM, bruce badouglas@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.
So actually, if I have compromised a system with that USB stick pre-inserted, I can create a custom kernel that causes hacked install image on that media to pass checksum. The apparently valid checksum would seem to imply the key hasn't been hacked. But since it has been, my hacked kernel can install a rootkit or other such malware in the course of you reinstalling the system. So I think this is invalid short of it leveraging UEFI Secure Boot.
Chris Murphy
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 lists@colorremedies.com wrote:
On Dec 27, 2013, at 4:40 PM, bruce badouglas@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
On Dec 27, 2013, at 5:44 PM, bruce badouglas@gmail.com wrote:
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.
If you point the two installers to two different primary partitions so they get separate /boot directories, you'll get to see their unique installer created grub.conf and you can see the differences.
In particular, do I simply select the sda for the boot partition?
No. You either need to point the installer to sda1 twice (once for each install), or you need to create three primary partitions: sda1 boot for install #1, sda2 will be LVM which both installs can use, and sda3 will be boot for install #2.
Chris Murphy
Hi again Chris!
I owe you OJ/Beer/Pizza!
With regards to creating the 3 partitions, umm.. using the Installation GUI, where does that happen? I can't seem to find it on the Create Custom Layout Page. Am I looking at the wrong/right place?
thanks
On Fri, Dec 27, 2013 at 7:54 PM, Chris Murphy lists@colorremedies.com wrote:
On Dec 27, 2013, at 5:44 PM, bruce badouglas@gmail.com wrote:
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.
If you point the two installers to two different primary partitions so they get separate /boot directories, you'll get to see their unique installer created grub.conf and you can see the differences.
In particular, do I simply select the sda for the boot partition?
No. You either need to point the installer to sda1 twice (once for each install), or you need to create three primary partitions: sda1 boot for install #1, sda2 will be LVM which both installs can use, and sda3 will be boot for install #2.
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
-
bruce -
Chris Murphy -
Edward M -
Marko Vojinovic -
Pete Travis