Multi-boot with Trisquel and other GNU/Linux distro(s)
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
I am a translator!
I have Trisquel installed on an SSD. There is a boot partition formatted as ext2 which is 730 MB (32% is used but there are multiple kernels that could be deleted) and an extended partition as a LVM physical volume, in which there are two logical volume groups, swap and root partition of about 930 MB, of which about 10% is used now.
I like Trisquel and I don't plan to use any other system on my laptops on which it runs fine but since I still don't manage to avoid my desktop freezing following a number of issues apparently occuring in the graphic card driver, while it is supposed to be very well supported, I'd like to give a try to Debian and Guix system.
Could the existing /boot partition be shared between Trisquel, Debian and Guix, while I would shrink the volume group used for the root partition of Trisquel and create two new volume groups to hold the root partition of the two other systems?
Or do I need separate boot partitions? Any other suggestion is welcome.
The easy way would certainly be to have one /boot partitions per distribution or, even simpler, to have /boot on the root partition (but I imagine you want to encrypt the root partition, hence the separate /boot). That said, I believe it is possible to have a shared /boot. Nevertheless, I fear os-prober, called by grub-mkconfig, itself called by update-grub, would not know how to map the kernel images with the root partitions. In other terms, you may have to edit your /boot/grub/grub.cfg every time you install a kernel: https://www.gnu.org/software/grub/manual/grub/html_node/Multi_002dboot-manual-config.html#Multi_002dboot-manual-config
Notice that I speculate: I have never tried that myself nor have heard of anybody trying that.
I am a translator!
Trisquel was not installed by me, ciphering is not used and I don't know why /boot is separate. I have coreboot+SeaBIOS on the flash and my disk has a DOS partition table, with /boot, a physical volume holding a single volume group, with two logical volumes, one for swap one for root.
Supposing I use separate partitions on the same disk (with /boot in the root partition), is there any installation option to get a single menu at boot with the choice of OS/partition, without having to do some manual configuration of grub? (manual configuration of grub looks not easy and might interfere with the OS tools).
If there is such an option, this is what I'd like to do, even if I need to switch to a GPT partition table, repartition, neither use LVM nor ciphering and reinstall Trisquel. I am really looking for the easiest/least risky way to have multi-boot without separate disks.
If there is a way to launch Debian or Guix from Trisquel, that could be fine too.
manual configuration of grub looks not easy and might interfere with the OS tools
Indeed.
I am really looking for the easiest/least risky way to have multi-boot without separate disks.
Then, you do not want to share anything (but the swap partition). Just shrink the largest partition to have enough space for the new system. For Debian, that can be done in its installer, I believe. For Guix SD, I have no idea. I believe update-grub will find all systems (thanks to os-prober) and adequately list them in the menu.
It is possible to have /boot on your encrypted root partition. This requires GRUB to decrypt it, which means that you have to add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub. I doubt the installer supports this configuration but it can be done manually. Some extra configuration is needed if you don't want to enter your password twice (once for GRUB, and another time for cryptsetup). If you're interested in doing this, I can provide more details (at least for Trisquel and Debian)
> is there any installation option to get a single menu at boot with the choice of OS/partition, without having to do some manual configuration of grub
Install GRUB from just one of the OS's. update-grub (via os-prober) will detect the other partitions and set up the menu for you.
I am a translator!
In order to resize the Trisquel root logical volume, tried to boot on a Trisquel live USB but all I get is
graphics initialization failed Error setting up gfxboot boot:
Since I had a parabola live ISO, I tried and it booted successfully (but when using the arrow down key to move to the next boot menu entry, instead of showing it with reverse constrast, a new line at the bottom appeared and the whole display was clumsy).
In parabola, I used "lvresize -r -L 200G oem-vg/root" (many thanks to the people who wrote the man page for lvresize, it is very clear, and lvresize did the filesystem check first, resize the filesystem, then the volume, then recheck, great tool).
I rebooted after that, starting of Trisquel was very very slow, for several minutes there was just a mouse pointer, then after I could enter the login password, it also took several minutes. I tried to reboot again, this time everything was back to normal.
I installed Debian using the netinstaller and the second entry (install, not graphical install as it apparently did not work), there was a message
Undefined video mode number: 314 Press to see video modes available, to continue, or wait 30s
I pressed ENTER, it listed a number of modes, I selected F01 80x50 VGA, it worked ok.
Install was ok, although in the manual partitioning, when creating a new logical volume in the same volume group, some message saying the existing logical volumes "will be formatted" was extremly worrying. However, as mentioned below, the existing Trisquel root volume seem untouched.
At some point, the installer said it has detected that there was another system called Trisquel and is asking whether to install GRUB on the MBR with a menu that let choose between all the detected systems, so I confidently said yes.
At reboot, all I see is:
SeaBIOS (version rel-1.14.0.0-g122821a) Press ESC for boot menu. Booting from Hard Disk... GRUB loading Welcome to GRUB!
If I don't touch any key, after a while I see Debian starting. If I touch any key, this is frozen forever. I suspect there is an issue that it can't display the menu. Once, after more than 10 minutes, it started booting and ended quickly with kernel panic as it can't mount the root file system.
I left it on all night with Debian running, today there was no display and no reaction, so I finally used the physical reset button and decided to reinstall Debian only with Mate (I was so lost). Now it works and I could deactivate any sleep or screen off feature, in case that was the problem. I'll see how it goes.
Overall, thanks Magic Banana and Legimet for the advice, it worked well besides the display issues in initial boot menus of Grub or installers.
Any further advice on how to get back a Grub menu (I had one with Trisquel before) and boot Trisquel again is welcome. I mounted the Trisquel root volume, it seems perfectly fine, so I suspect the problem is "only" Grub.
I would try to add that line to /etc/default/grub (for instance using your favorite text editor, using administrative privileges):
GRUB_TIMEOUT_STYLE=menu
You then need to execute update-grub (still using administrative privileges) for the change to be taken into consideration.
I suspect there is an issue that it can't display the menu.
You may need to define GRUB_GFXMODE in /etc/default/grub: https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html
I am a translator!
Thanks.
I was unsure about the GFX modes, so I uncommented the "GRUB_TERMINAL=console" line in /etc/default/grub, ran "sudo upgrade-grub", rebooted, then I have a menu with Trisquel and Debian, the layout is similar to what is visible in https://help.ubuntu.com/community/Grub2
The comment in /etc/default/grub before the line I uncommented says "Uncomment to disable graphical terminal" but I don't know what the "graphical terminal" that could be enabled is. Does that bring any functional difference or is just a nicer layout? For a boot menu, reliably having a usable menu seems far more important than some fancy graphical layout.
I was unsure about the GFX modes
According to https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html :
‘GRUB_GFXMODE’
Set the resolution used on the ‘gfxterm’ graphical terminal. Note that you can only use modes which your graphics card supports via VESA BIOS Extensions (VBE), so for example native LCD panel resolutions may not be available. The default is ‘auto’, which tries to select a preferred resolution. See gfxmode.
I would therefore try "auto".
Does that bring any functional difference or is just a nicer layout?
I believe it would just be nicer.
I am a translator!
I would therefore try "auto".
I tried, it does not work. I found https://libreboot.org/docs/hardware/kcma-d8.html#graphics. I have coreboot without any non-free piece, I guess the situation is the same like Libreboot.
While I can understand that graphics can be popular, using it by default in GRUB is not so friendly to free boot projects.
In my experience, you can multi-boot as many OS's as you can fit on a single hard drive using either separate partitions or logical volumes inside a single physical volume (GPT is the best choice these days, even on older BIOS based systems using HDDs instead of SSDs). The issue, of course, is that if you install grub on more than one OS then they want to individually update grub all the time, which can result in issues specific to using Guix System, since the OS's configuration is hard coded in its scm file, which is read every time it you boot it. That said, you can install all but one of the OS's without installing grub, then install grub only during the installation of the distro you want to use to manage it. It is probably best to let Guix System manage Grub if you decide to use it as one of your multi-boot installs due to the unique way it works.
As already mentioned, you can share the swap partition between all the *nix distros. Additionally, I like to use a shared storage array (with BTRFS raid 1,0) between all the distros using symlinks from $HOME. That way, it never really matters what happens to any or all of the multiple OS installations...you can always just reinstall any distro and make new symlinks to the directories in the storage array (you can set this up with the skeleton file if you really want, but doing it manually is simple enough, although you will have to ensure they are mounted at each boot). This leaves all of your dot files for their own distro to manage while easily accessing all your data between them. This also prevents data loss in the case of a drive failure (BTRFS raid 1,0 needs at least 4 separate drives to prevent data loss).
Last time I checked LVM does not work with Guix System, though, so plan accordingly (separate physical partitions using GPT in this case). The Debian installer allows you to select "continue without bootloader" during installation to avoid installing Grub, while you can achieve the same thing with all Ubuntu based distros (like Trisquel) by manually running the installer from the live cd on the command line as follows: 'ubiquity --no-bootloader'.
All of this assumes, of course, that the idea of using a shared /boot partition is to avoid issues relating to how the boot process works with Grub. Running the Grub utilities from the single distro that has the only Grub installation should auto-detect the other installations (or simply hard coding the additional OSs into the scm file with Guix System, in my example) while multi-booting is the key to avoiding all of your /boot related issues without having to share a /boot between them.
Edit: Note that in normal circumstances not involving Guix System, having each distro run its own Grub isn't an issue as each one runs the Grub utilities when it is updated which finds the other OSs you are multi-booting. The information provided above specifically relate to issues when using Guix System in a multi-boot setup.
Depending on the size of your hard drive or solid state drive,
You could probably disk clone from different qemu images to do this, I have never tried to do this with multiple images though, but more because, I don't feel the need.
It is somewhat advanced though, but it is a technique that is nearly perfect for distrohoppers.
As a side note, I been there... ;)
"https://en.wikibooks.org/w/index.php?title=QEMU/Images&action=edit§ion=6"
The above guide does work for me, but do research first so you don't screw it up.
:)
- Vous devez vous identifier ou créer un compte pour écrire des commentaires