Re: dual booting, was Re: Stupid question
On Sat 12 Feb 2022 at 10:04:43 (+0100), Hans wrote:
>
> I am thinking of a solution of a problem. But I have an understanding problem,
> maybe you can give some background knowledge.
>
> The problem: I have one harddrive, there are two linuces installed.
>
> The partitions are as followed:
>
> kali-linux: 1st primary -> /boot
> 2nd > /
I have to assume that this is a complete linux installation here, with
the possible exception that you could unlock the /home partition (below)
and mount it with either of the systems. That's my standard practice
with two Debians on one drive. (I share swap too.)
> debian 3rd primary -> /boot
> 4th logical > /
> > swap
> > /home (encrypted)
> > /usr (encrypted)
> > /var (encrypted)
It's not generally useful to encrypt /usr if it only consists of
free software, because it's public knowledge. It would be more
useful to encrypt swap.
Sharing /usr between two almost identical /Debian/ systems could
be made to work with care and expertise. OTOH I don't see how you
could sensibly share /var/lib in any way, because it's used to
maintain the state of a system — /one/ system.
But the level of your questions here would indicate that you're
going to struggle to do anything resembling that. I don't know
anything about kali (except the coloured sherbet of my childhood).
So your layout, above, worries me as it seems to imply more than
you're actually saying here. (Not the layout of the partitions
on the disk, but the text's alignment in the layout above.)
> This is the structure, and as said before, only ONE drive.
>
> Now my question: Is it possible to configure grub that way, that I can choose
> either kali or debian to boot?
I'm assuming that you're booting an MBR disk in a BIOS system,
seeing that your disk looks like something that DOS or Windows
would have created years ago (three primary partitions, and an
extended partition containing five logical partitions).
So, yes. You just install the systems as normal. Each installer
should install its own grub packages, and they should configure
its own /boot/grub/ directory (a process you can repeat at any
time by running update-grub¹ on that system). Each installer
should also install Grub's boot code in the disk's MBR (which
will overwrite any previous code).
> What I might to know, please correct me:
> Both are running different kernels.
This is irrelevant, as long as the systems defined by partitions
1, 2 ± /home are not being comingled with that defined by 3, 4
± /home, and that /usr and /var are "owned" entirely by either
one system or the other.
> As far as I understood grub, I can set the
> root partition ( / ) with the UUID. This is an entry in grub.cfg
For Debian, that is the default. It's done for you: you don't have
to transcribe any UUIDs by typing them in.
> and maybe in
> /etc/default/grub.
In that file, one can /prevent/ the use of UUIDs by Grub, but it
makes no sense for you to do so.
> But how can I tell grub, to use the kernel of the second /boot?
If/when you install a system "A" on the disk, its Grub configuration
will only know about that system, and boot it by default. When you
install system B, B's Grub will scan² and see both systems, adding
menu entries for both in its own grub.cfg. Grub on the MBR will
be made to point to B's grub.cfg, and that will have B listed as
the default system to boot (first in the menu).
If you want to boot A, just select it from the menu presented by B's
grub.
When you boot and run A, you can update-grub¹ and that will scan
and see both systems, writing A's grub.cfg with A as the default
system to boot /in its grub.cfg/. However, A's grub.cfg will never
be consulted, because the MBR points to B's grub.cfg. (Think of
B as the "master system".)
(Only if you run grub-install on system A will the MBR be overwritten
so that it points to A's grub.cfg, and from then on, booting would
use A's grub.cfg.)
None of this matters until you upgrade one of the systems with
a new kernel (pretty common) or a new grub (fairly uncommon).
When you upgrade, say, A (the non-master system), A's updated
grub.cfg will be brought up-to-date. But typically, upgrades
will not touch the MBR as there's no need. So, if your MBR was
pointing to B's grub.cfg, the menu items in B for booting A
will be out of date and pointing to the wrong kernel version.
You have to either:
. In A, after the upgrade, run grub-install to make the MBR point
here, to A's grub.cfg. (A is now the "master system".)
or
. Reboot (which will still use B's grub.cfg) and select B. When
B is running, run update-grub¹ to freshen its grub.cfg. Now,
B's grub.cfg will have up-to-date entries for A's kernel.
(B remains the "master system".)
Typically, one would have a primary, "master" linux system which would
be used to write an MBR pointing to itself. The other, legacy system
would have its grub.cfg kept up-to-date, but would never touch the
MBR by running grub-install.
> I dunno, if it is possible at all, to get a dual boot, the way I want it. With
> a combination of Windows + Linux on one harddrive this is working, however,
> just because grub does not touch the windows bootloader (as fas as I know),
> and what of course is also working, if you got two harddrives, each with
> different linux. They all can be booted from one grub installation, of course.
Traditionally, the simple way of dual booting linux+Windows was to
install Windows first (normally done by the manufacturer, of course)
and then install linux. The installer would write an entry to chainload
Windows from grub.cfg, and overwrite the disk's MBR to point to this
grub.cfg. A Windows entry in grub.cfg might look something like:
menuentry 'Windows 7 (loader) (on /dev/sdb1)' --class windows … 'osprober-chain-8CA4761234769684' {
…
search --no-floppy --fs-uuid --set=root 8CA4761234769684
parttool ${root} hidden-
chainloader +1
}
But having multiple drives just complicates the issue, because the
BIOS now has to choose which /disk/ to boot, and therefore which
disk's MBR gets executed. That choice is not always unambiguous,
and is difficult to generalise about because BIOSes vary a lot.
With Windows, there's also the complication that Windows's MBR (the
one that it writes, if you let it) may require the partition to have
a "boot flag" in order to boot it.
> Maybe I could find a solution, if I would have fully understood how grub is
> working, and what it is doing.
Just remember update-grub¹ writes grub.cfg into this system, with a list
of bootable systems on the computer, whereas grub-install makes the MBR
point to the grub.cfg on this system.
> Any hints are welcome, and if this does never work at all, please drop me a
> line.
¹ I'm using the Debian names for the programs concerned.
update-grub is just a wrapper round grub-mkconfig (in
case you look at Grub documentation).
² Install os-prober if it is absent. Enable it if it is
disabled.
Cheers,
David.
Reply to: