LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   Dual Boot/GRUB Woes (https://www.linuxquestions.org/questions/linux-software-2/dual-boot-grub-woes-4175545645/)

triphazard 06-17-2015 01:06 PM

Dual Boot/GRUB Woes
 
Hi All,

I'm returning back into the Linux fold after a few years off and am aiming to achieve a dual-boot Debian/Kali encrypted system.

Right now I have Debian 8 set up with a non-encrypted boot partition (/dev/sda1), and separate /, swap, and home partitions inside an encrypted LUKS volume. All told I've used about half of the (one) physical disk. Grub is installed to the MBR.

Now, I've left a separate blank ext4 partition at /dev/sda2 to act as the non-encrypted Kali boot partition and plan to set up an identical encrypted volume layout as above for Kali. However, after the first attempt at installing Kali I couldn't get the existing grub to 'see' Kali and offer me that as a 2nd boot option. I set the bootable flag on /dev/sda2 and even mounted it within Debian before running update-grub but can't get it to offer me Kali as an option for love nor money.

So I figured I must have made a mistake somewhere along the line but am unsure where. I don't suppose anyone is able to shed any light on how I can achieve the above can they? I've wiped all trace of the Kali install to start that from new now, and Debian still boots and runs fine. Just wondering what to try next?

I've Googled this til I'm blue in the face by the way but haven't had any luck.

Thanks in advance.

UPDATE:

I decided to try the Kali installation again but this time choose to allow it to overwrite the existing grub config on /dev/sda - now grub offers me Kali only and no Debian. Makes sense.

When in Kali though, I can mount Debian's boot partition (/dev/sda1) and see its vmlinuz/initrd.img-3.16x files just fine but update-grub just won't detect them.

Has anyone ever encountered anything similar to this before? Does it make a difference that the root partitions of both are encrypted? I assume not as both have booted fine from grub at one point or another.

syg00 06-18-2015 08:47 AM

Quote:

Originally Posted by triphazard (Post 5378801)
When in Kali though, I can mount Debian's boot partition (/dev/sda1) and see its vmlinuz/initrd.img-3.16x files just fine but update-grub just won't detect them.

Has anyone ever encountered anything similar to this before? Does it make a difference that the root partitions of both are encrypted? I assume not as both have booted fine from grub at one point or another.

update-grub calls os-prober to do the real work - I'm doing this from memory when I looked at os-prober a while back, so don't take it as gospel.
To get anything to work, you'll need to have the luks container for the "other" system open - doesn't need to be mounted, but must be readable. However, once a partition is found to be a Linux system, /boot on that partition is checked as well as the mounted /boot for the running system. Because you use a separate /boot for both, the /boot on the second root partition will be empty.

Sooo - if you used a shared /boot, and had issued a luks open for both systems, I reckon update-grub would work. Another option is just to create your own 40_custom member - but you'll have to update that manually for any kernel update.

As I said, untested.

triphazard 06-18-2015 09:35 AM

Thanks for the reply syg00. I actually fixed this just now and here's how: -

I don't know if all steps below are necessarily required but this is exactly what I did and it worked: -

*Firstly, boot up into the only available OS, in this case Kali

*Log in

*Open the File Manager and attempt to mount the encrypted LVM from there (enter encryption passphrase and receive error about it not being recognised or something)

*From the terminal run: -
vgscan --mknodes
Excerpt from the man page: vgscan scans all SCSI, (E)IDE disks, multiple devices and a bunch of other disk devices in the system looking for LVM physical volumes and volume groups

*Then run: -
vgchange -a y
Excerpt from the man page: vgchange allows you to change the attributes of one or more volume groups. Its main purpose is to activate and deactivate VolumeGroup-Name, or all volume groups if none is specified
The -a y at the end marks the volume group as available for change.

*From there I then manually mounted the 2nd OS's Root and Home partitions (/dev/mapper-xxxx) at media mount points, and also mounted the non-encrypted /dev/sda1 boot partition.

*Next, run os-prober - the 2nd installation was recognised at this point

*Finally, run update-grub and watch with joy as it detects the 2nd Linux install and finally writes it to Grub.


Like you said, the key appears to have been having the luks for the 'other' system open within my live system. I suspect the mounting etc wasn't necessary.

Happily dual-booting two Linuxes, each with encrypted /, home, & swap partitions. Happy days.


All times are GMT -5. The time now is 09:59 PM.