- This topic has 42 replies, 8 voices, and was last updated Mar 16-1:47 pm by Brian Masinick.
-
Posts
-
Brian Masinick
When you have multiple distributions you ideally choose one of them to manage your boot loader. If they’re all Linux, to be honest with you, one day distro 1 can manage it and another day distribution 2 can manage it.
A lot of times I DO keep multiple copies of my boot loader. Not often but on rare occasions something gets messed up. A live USB can get you out of trouble, so can duplicate copies. Again I don’t want to confuse you so I advise you to choose one system to manage all. When you make changes always update the boot loader on that main system and keep a backup USB to assist with correction of any unplanned issues.
Backup copies also help to get back to a stable place when problems arise. I definitely recommend regular backups, then there is less stuff lost when mistakes are made or software causes errors or there is a hardware failure.
--
Brian Masinick
dukester
When you have multiple distributions you ideally choose one of them to manage your boot loader.
Which means edit its GRUB file and that’s it I suppose?
--
dukesterBrian Masinick
Choose one distro and maintain GRUB in that one.
sudo update-grub will take care of it.
--
Brian Masinickdukester
Wallon
Dear Brian,
This is another very interesting topic you are starting.
I had read that it was difficult to put several Linux distributions on the same disk because they could use different grubs. Many distributions do an automatic grub-update.
Are the grubs all the same if I put for example on the same disk;
1) antiX
2) Arch Linux
3) Fedora
4) Debian Gnome Wayland ?There could be older grub versions on the Debian families and more modern grubs on the other distributions.
I have never dared to do this. Is this possible?
I notice that experts (like for example professionals who work with Linux all day long like in universities, hospitals, developers of big web databases…), use a lot of VMs to maintain different distributions on a disk. In this case, each distribution is partitioned and cannot modify another Linux distribution.
Best regards,
WallonBrian Masinick
Hi Wallen,
In fairness, it was Dukester who started asking questions about what to do;
all I have done is answer his questions and I’ve posed a few options about
other things he can try.I do use several distributions but I’ll tell you this:
During the afternoon today, I’ve finished other updates on the other
distributions I installed on my Dell Inspiron 5558 laptop, so I decided
to spend the remainder of the day with antiX 23 Alpha 1.This is our VERY FIRST build; imagine how good it will be once we get the final
image. The good news is:1) The kernels we have: the 4.19 kernel for really old systems,
the 5.10 kernel for moderately old systems (except mine – the Dell has always had strange issues
with the Debian kernels and probably ANYTHING in that 5.10 group, yet it’s never struggled with anything
before or after, yet for some other systems in that era, this odd kernel worked where others did not.
This is one reason we have to always remember that “one size does NOT fit all”, just like
the commercial software that many companies hoist upon the public is frequently not even
close to what they actually want or need! So even though the 5.10 is my least favorite Linux
kernel ever, other people matter more than my one voice! I’m GRATEFUL for CHOICE!2) Our new 6.1.10 and 6.1.11 kernels work well; I have one 6.1.10 on this system and the 6.1.11
kernel on the antiX 22 system I have on my HP-14. I hope that we keep offering old and new kernels.
They don’t ALL have to be standard, but if we want to allow newer systems, I suggest we offer a
V6+ kernel with our final build (and as soon as possible, so we can test them in the remainder of
the Alpha/Beta test cycles).3) It’s the 32 bit users that deserve some specially supported OLD kernel. I don’t know what the
oldest is that we can support; if there are any special kernels that someone OUTSIDE of the kernel.org
space supports, it’d be something worth our investigation; I think 4.19 might be the only one with
support life left otherwise.As I write and think about this, I think about my own needs and interests, and I do my best to
consider as many people as I can in addition to my own biased interests. Hopefully people
will weigh in, not just here, but join in on the antiX 23 testing effort. The more participation
we have EARLY, the more anticapitalista will be able to respond to in time before the release
sneaks up on us. Right now, we DO have time, because Bookworm –
Starting 2023-03-12, key packages and packages without autopkgtest will be treated as in the Full Freeze.
We don’t have a Bookworm Release Date YET.
Here is the policy for Bookworm: https://release.debian.org/testing/freeze_policy.html
2023-01-12 – Milestone 1 – Transition and toolchain freeze
2023-02-12 – Milestone 2 – Soft Freeze
2023-03-12 – Milestone 3 – Hard Freeze – for key packages and
packages without autopkgtests
To be announced – Milestone 4 – Full Freeze
https://lists.debian.org/debian-devel/2022/03/msg00251.html--
Brian MasinickBrian Masinick
As far as GRUB instances go, I have five distributions right now on my Dell Inspiron 5558.
447.13 GiB is the size of my SSD; previously I had a 8 TB HDD, which had far more capacity,
but considerably less throughput. I could easily fit a dozen or more distributions on that
other disk; I don’t think I’ve done that on THIS Dell, but I’ve had a Gateway 17″ PA6A
“portable” (hesitate to call that beast a laptop) and before that I had a Dell Dimension
4100 desktop with two disks, and I definitely ran as many as three different styles of
OS at one time – Windows, Linux and BSD. I also experimented with a real time system
and a few oddball varieties, either live or isolated to the second drive.All were “possible”, though a few were tricky to be 100% recognized by one another
with a single boot loader and that is where I had to get creative with chain loading
and other alternative boot loader methods. I don’t do that stuff any more; for those
who are interested in such things, you’re going to have to pick that up on your own
because it’s been between 15-20 years since I went that deep in that particular area.--
Brian MasinickBrian Masinick
On antiX, depending on which disk organization you have, you can install GRUB:
1) on the root of your local distribution.
2) on the MBR, master boot record.
3) if using a modern implementation with GPT partitions, you can install
on the GPT of the local disk or the EFI/UEFI equivalent of the Master Boot Record.--
Brian Masinick
blur13
Wallon,
To answer your question, yes it is possible to have several linux distributions on the same disk. Its true what you write, that a grub update in one of the distros “will take over” the inital grub screen on start up. Thats easily resolved by going back to your favorite distro (or rather, the distro you want to manage grub) and running sudo update-grub. The grub screen at start up will now be the original one.
I also think that when there is a grub update during the update process you can choose not to have it update the boot loader. This is also true when installing a new distro, there is usually an option to not update the boot loader.
madibi
@blur13
dear, I am a bit confused about your postThats easily resolved by going back to your favorite distro (or rather, the distro you want to manage grub) and running sudo update-grub
As far as I know what you wrote doesn’t do what you described.
In order to put the instruction to mbr to point to the grub of your favorite distro you should use “sudo grub-install”, from within your “main” or favorite distro. Only then you should use the “sudo grub-install”.For perennial newbies as I am, instead of the above commands, in antiX you can easily use the gui from Menu-> Control Centre -> maintenance -> Grub Repair. This tool is really good and easy to use.
I also think that when there is a grub update during the update process you can choose not to have it update the boot loader
also this latest above statement lets me confused. As far as I know, the grub updates only in case of new kernel install. So, in case you don’t update-grub, how can you use it?
Thanks for your attention 🙂
m- This reply was modified 1 month, 3 weeks ago by madibi.
blur13
Yes sorry, I think I dont have my terminology correct and when dealing with these issues its important to be specific. I guess my point is that when you install a new distro, or the distro updates grub, then the grub.cfg of that distro will be used for the menu that displays boot entries. In a sense, the grub.cfg gets “hijacked” by the new distro. In order to restore the grub.cfg you have to run sudo update-grub in the old distro. The new/updated menu will display boot entries about other distributions that are installed on the system.
caprea
Yes, the command to make the installation you previously selected to control grub,
the grub controlling system again, is
sudo grub-install /dev/sdXexecuted after booting into that system.
Whenever a new kernel is installed on any of the systems, grub must be updated (sudo update-grub) on the controlling system, to pick up the new kernel.
The installation which controlls grub,should be the installation with a solid system that you trust the most for this job.I always prefer antiX for that.All in all, dual- or multi-booting is not that complicated if you follow a few rules.Brian Masinick
Yes, the command to make the installation you previously selected to control grub,
the grub controlling system again, is
sudo grub-install /dev/sdXexecuted after booting into that system.
Whenever a new kernel is installed on any of the systems, grub must be updated (sudo update-grub) on the controlling system, to pick up the new kernel.
The installation which controls grub should be the installation with a solid system that you trust the most for this job.I always prefer antiX for that. All in all, dual- or multi-booting is not that complicated if you follow a few rules.Perfect!
--
Brian Masinick
- You must be logged in to reply to this topic.
