Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.