Re: dual booting, was Re: Stupid question
With respect to the original problem, this response is moot. On Sun 13 Feb 2022 at 18:50:43 (+0100), Hans wrote: > > 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.) > yes, that is what I thought, would be working. But sadly did not. > > I expected, after using update-grub, that os-prober would detect both > partitions with the menu.lst or grub.cfg inside and create two entries in the > boot menu. > > However, this did not work, only one (the last installation, which was kali), > was seen. > > Maybe I did something wrong! Saying something didn't work is no help. Even the observation here is of little use without the pasted output, and possibly requires yet more context than that. And saying "the menu.lst or grub.cfg inside" gives the /impression/ that you're not doing the work on your side, not even looking to see what you're dealing with. > I had had Windows-7 and Debian on the hardddrive. Then I deleted the > Windows-7 > partition (good choice, eh?) and installed kali on this partition. > > With installing grub during the installation process, I expected grub to see > both, kali and debian. But, it only recognized kali. > > So my idea was, to edit kali's grub.cfg manually, so that I got two entries, > but did not succeed (becauuse I did not know, how exactly to do). Again, your report is sadly lacking. No indication of what is where, even though I had tried to guess in my first post. And no indication of the edits you made and what the output said, just "did not succeed". > Meanwhile I am using the whole harddrive for kali, because I discovered that > the partition was to small for kali (34GB, but I needed 50GB). > > But I think, this problem will appear in some time, when I am buying a bigger > harddrive, where I intend to put several different operating systems on one > harddrive. When it does, please read some parts of these before you post: http://www.catb.org/~esr/faqs/smart-questions.html https://www.chiark.greenend.org.uk/~sgtatham/bugs.html > Thanks for the feedback, and all your help. > > If I got a solution, I will tell you. Cheers, David.
Re: dual booting, was Re: Stupid question
On Sun 13 Feb 2022 at 19:26:51 (+0100), Andrei POPESCU wrote: > On Du, 13 feb 22, 11:01:48, David Wright wrote: > > > > 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. > > Another option (at least with MBR, didn't try this with GPT) is to tell > the Installer to install GRUB in the partition instead of the MBR, and > then manually install another GRUB instance to the MBR with a > handcrafted config that is chain-loading the GRUBs in the partitions. > > This way each system's GRUB config is nicely following kernel upgrades > automatically. There are implications in doing that. If you install Grub on a logical partition, then some sources suggest that you get the space for its core.img after the Extended Boot Record (EBR), but I don't see any firm evidence for that, particularly if the partitioning was done by non-Windows partitioners, and compounded by non-CHS disks. I can't examine a real example as I haven't created a logical partition since the last millennium. As for primary partitions after the first, there's no BR for there to be a gap after. So the core.img for Grub has to be placed in the filesystem itself, yet it's addressed by block addresses, which are not known to nor respected by normal filesystem utilities, and which therefore means they can get moved. As for GPT disks, where you have to use a BIOS Boot partition for Grub's core.img, there's no way to manage that space other than to juggle multiple such partitions so that each Grub instance is forced to use a different BIOS Boot partition instance. Cheers, David.
Re: dual booting, was Re: Stupid question
On Mon 14 Feb 2022 at 10:18:13 (+1100), David wrote: > On Mon, 14 Feb 2022 at 05:27, Andrei POPESCU wrote: > > On Du, 13 feb 22, 11:01:48, David Wright wrote: > > TLDR: > On the topic of grub automatic configuration > 1) suggestions how to avoid it > 2) why I prefer to do that > > Disclaimer: contains generalisations and lacks full justifications of > points made. This is just a brain dump of some thoughts that some > people might find useful alternative options. I don't have time to > polish it into a nice piece of considered writing. If you disagree > with something, that's fine. I'm just offering an alternative > perspective, not trying to change your mind :) Ditto in this response. > > > 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. > > > Another option (at least with MBR, didn't try this with GPT) is to tell > > the Installer to install GRUB in the partition instead of the MBR, and > > then manually install another GRUB instance to the MBR with a > > handcrafted config that is chain-loading the GRUBs in the partitions. (I've responded to this post itself.) > And yet another option for avoiding bootloader conflicts in multiboot > setups (at least with MBR, didn't try this with GPT) is to avoid > installing the os-prober and/or grub-update machinery on all but one > of the linux installs. This can be done (in the installer expert mode, > and maybe the others) by skipping the "install grub" step and choosing > "install without a boot loader". It's provided for a good reason :) > > The installed OS will run fine without grub, provided that you ensure > that there is a bootloader somewhere else that can start it. That's > your job now! After booting, if you want to you can even install a > constrained version of grub that lacks the grub-update machinery, by > installing the package 'grub-pc-bin' instead of 'grub-pc'. > > It too is provided for a good reason :) > As the maintainer says: > > $ apt show grub-pc-bin > [...] > It can be installed in parallel with other flavours, but will not > automatically install GRUB as the active boot loader nor automatically > update grub.cfg on upgrade unless grub-pc is also installed. > $ I must think about that with respect to my PC that has three Debians, one booting with UEFI- and two with BIOS-mode. Of course, I can currently boot all three in either mode, and even update-grub, but grub-install might cause problems if run in the wrong mode. I was considering how to convert a BIOS-mode installation into a UEFI one (I'm posting that in another thread), but I could just leave the two BIOS ones with no grub at all. > When grub2 first was released I avoided it for years! I do not like > the automation that generates the grub.cfg file so full of > human-unfriendly content, compared to grub version 1. > > The automation is fine if it works and gives results you like, so you > can ignore it. It is a heroic programming effort and I'm sure it > handles all sorts of situations that I've never considered. > > However I was/am multibooting various OS, and I didn't like > to watch helplessly while os-prober made all kinds of inappropriate > decisions on my systems and update-grub mangled my boot menus. > > The idea of automation is worthy, but it seems to me with grub2 that > years later one downside is that we have moved to a situation of > learned helplessness. Now we have people in the situation like Hans, > where we have to explain the grub automation as if it is the only > possible way to do things. (I like "learned helplessness"!) True, but the upside of posting only the "official" automated way is that you don't have to support it. As you suggested above, a customised method would really require a polished HOWTO, were I to recommend it. > And no-one dares to touch their grub.cfg anymore because it's > overwheming. Even though most of that overwhelming content is very > much not necessary, it is a primary deterrent causing people to avoid > configuring the bootloader menu themselves. People ask about how to > tinker with the tiny bit of configuration that grub exposes [1], and we > don't dare to recommend that they throw it all away because we've all > become reliant on the automation. And explaining the alternative is > too hard. Yes, I've certainly used the GRUB_DEFAULT for the NextBoot facility in the past: when fsck'ing a device took ages, NextBoot would automatically select a forcefsck boot when the BIOS turned the machine on (again, automatically) in the morning. And GRUB_CMDLINE_LINUX is still useful for adding system-dependent tweaks, like libata.force=3.00:disable on a broken machine and video=960x540 on a laptop with unusable resolution. But I run a shell script on any new grub.cfg that automatically makes all the changes I want (like
Re: dual booting, was Re: Stupid question
On Mon, 14 Feb 2022 at 05:27, Andrei POPESCU wrote: > On Du, 13 feb 22, 11:01:48, David Wright wrote: TLDR: On the topic of grub automatic configuration 1) suggestions how to avoid it 2) why I prefer to do that Disclaimer: contains generalisations and lacks full justifications of points made. This is just a brain dump of some thoughts that some people might find useful alternative options. I don't have time to polish it into a nice piece of considered writing. If you disagree with something, that's fine. I'm just offering an alternative perspective, not trying to change your mind :) > > 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. > Another option (at least with MBR, didn't try this with GPT) is to tell > the Installer to install GRUB in the partition instead of the MBR, and > then manually install another GRUB instance to the MBR with a > handcrafted config that is chain-loading the GRUBs in the partitions. And yet another option for avoiding bootloader conflicts in multiboot setups (at least with MBR, didn't try this with GPT) is to avoid installing the os-prober and/or grub-update machinery on all but one of the linux installs. This can be done (in the installer expert mode, and maybe the others) by skipping the "install grub" step and choosing "install without a boot loader". It's provided for a good reason :) The installed OS will run fine without grub, provided that you ensure that there is a bootloader somewhere else that can start it. That's your job now! After booting, if you want to you can even install a constrained version of grub that lacks the grub-update machinery, by installing the package 'grub-pc-bin' instead of 'grub-pc'. It too is provided for a good reason :) As the maintainer says: $ apt show grub-pc-bin [...] It can be installed in parallel with other flavours, but will not automatically install GRUB as the active boot loader nor automatically update grub.cfg on upgrade unless grub-pc is also installed. $ When grub2 first was released I avoided it for years! I do not like the automation that generates the grub.cfg file so full of human-unfriendly content, compared to grub version 1. The automation is fine if it works and gives results you like, so you can ignore it. It is a heroic programming effort and I'm sure it handles all sorts of situations that I've never considered. However I was/am multibooting various OS, and I didn't like to watch helplessly while os-prober made all kinds of inappropriate decisions on my systems and update-grub mangled my boot menus. The idea of automation is worthy, but it seems to me with grub2 that years later one downside is that we have moved to a situation of learned helplessness. Now we have people in the situation like Hans, where we have to explain the grub automation as if it is the only possible way to do things. And no-one dares to touch their grub.cfg anymore because it's overwheming. Even though most of that overwhelming content is very much not necessary, it is a primary deterrent causing people to avoid configuring the bootloader menu themselves. People ask about how to tinker with the tiny bit of configuration that grub exposes [1], and we don't dare to recommend that they throw it all away because we've all become reliant on the automation. And explaining the alternative is too hard. And if that automation breaks for some reason, like Stella had a while back, then in general everyone is helpless because it's too hard to give instruction on how to write their own grub.cfg and recover. I suppose I could write something for the wiki but I'm too lazy or too busy, and therefore part of the problem. Plus multiboot is quite unfashionable, other people like to advocate more modern methods with VM and such. I prefer not to become reliant on infrastructure that I can avoid (I do use VM for throwaway tasks). And these days I'm not multibooting disk partitions, I'm multibooting logical volumes inside one huge LUKS container that I only need to create once and provide one password for at boot. I like having all my multiboot filesystems easily mountable from everywhere, it helps me manage them collectively with scripts. Eventually I dug a little bit deeper with grub2. I experimented by writing my own simple grub.cfg. When that worked, the next step was to learn ways to prevent that effort being blown away by the automation at every update, as described above. Thee are other ways to do this too [2]. I persevered and I eventually learned to love grub2. It has some amazing features. Once you can get it to stop imposing its default behaviour on you, it's a powerful ally. For instance, it contains a full scripting language [3]. The authors wanted a control language, so they built a shell-like parser into it. Do you know that you can
Re: dual booting, was Re: Stupid question
On Du, 13 feb 22, 11:01:48, David Wright wrote: > > 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. Another option (at least with MBR, didn't try this with GPT) is to tell the Installer to install GRUB in the partition instead of the MBR, and then manually install another GRUB instance to the MBR with a handcrafted config that is chain-loading the GRUBs in the partitions. This way each system's GRUB config is nicely following kernel upgrades automatically. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: dual booting, was Re: Stupid question
Hi David, yes, that is what I thought, would be working. But sadly did not. I expected, after using update-grub, that os-prober would detect both partitions with the menu.lst or grub.cfg inside and create two entries in the boot menu. However, this did not work, only one (the last installation, which was kali), was seen. Maybe I did something wrong! I had had Windows-7 and Debian on the hardddrive. Then I deleted the Windows-7 partition (good choice, eh?) and installed kali on this partition. With installing grub during the installation process, I expected grub to see both, kali and debian. But, it only recognized kali. So my idea was, to edit kali's grub.cfg manually, so that I got two entries, but did not succeed (becauuse I did not know, how exactly to do). Meanwhile I am using the whole harddrive for kali, because I discovered that the partition was to small for kali (34GB, but I needed 50GB). But I think, this problem will appear in some time, when I am buying a bigger harddrive, where I intend to put several different operating systems on one harddrive. Thanks for the feedback, and all your help. If I got a solution, I will tell you. Best regards Hans > 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.)
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.) > debian3rd 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
