Installing debian/Ubuntus AFTER Puppy

[mikeslr]

The recipe for Multi-booting from a hard-drive used to be (1) Leave Windows if you have it; (2) 'Custom' install your choice of 'Major Distro' to the partition you selected; then (3) Install Puppys to their own or any other partition; then (4) run grub2config, https://www.forum.puppylinux.com/viewto ... 703#p29703 or add Puppys to the boot manager provided by the Major Distro by customizing it. Adding Puppys to the boot manager provided by the Major Distro by customizing it should still work but is cumbersome.

What running grub2config does, and still tries to do, is install grub2 to sda(1) and generate a grub.cfg which includes listings for Windows and previously installed Major Distros as a 'Chainload' of their respective boot-managers.

The problem is that the 'default' install of a Major Distro sometimes modifies sda(1). Zorin's Version 17, for example, may change sda1 to an extended partition, installing itself to a logical partition it creates. I'm not sure what Manjaro and other Distros using the Calamares installer do. But on two of my computers grub2config could no longer write all required files to sda1. And grub2config does not provide an option other than writing to sda1.

So if you replace a Major distro either with an upgrade or a different Major distro you may find yourself locked out of Puppys [except, perhaps by customizing the grub.cfg of that distro].

The following work-around avoids this for debian, ubuntu and any other Distros using the ubiquity boot installer. Do Not click the 'Install' button on the desktop (or start it from the Menu). Rather open a terminal and run the command 'ubiquity -b'. This will run the installer but NOT install a boot-loader. Then select 'custom install' and choose the partition on which debian/Ubuntu is to be located. [I've found no way to do a custom install without the installer also formatting the partition you chose].

To boot into your new Major Distro [and Puppys] you'll need to install a new boot-manager. I've discovered that grub2config ALMOST does it right. It creates a listing which doesn't boot. Ubiquity has located both specific versions of vmlinuz and initrd.img in /boot with symlinks just named vmlinuz and initrd.img, respectively. Being only one layer below the partition's root, grub2config should find them during booting; but doesn't although it did to create the listing. Edit, actually grub2config does find both, but errors in writing the 'linux' line. see below.

The work-around: See Edit below. Since the Major Distro utilizes the entire partition, open two windows: one to the root of that partition, the other to /boot. From within /boot find and drag thespecific versions of both vmlinuz and initrd.img to the root of the partition, then rename the symlinks created just vmlinuz and initrd.img, respectively. [Attempting to copy the already existent symlinks in /boot was not permitted].

Running grub2config now will generate two listings: one referencing the symlinks named vmlinuz and initrd.gz symlinks at the root of the partition; the other those files in /boot. When you discover which listing doesn't work, delete it. [Untested: delete the symlinks in /boot].

Remember, you'll have to do this each time your Major Distro updates its vmlinuz or initrd.img.

Sample grub Listing after manual edit:

menuentry 'Linux Mint 21.3 Virginia (sda3)'{
search --no-floppy --set=root --fs-uuid cd037026-ETC.
linux /vmlinuz root=UUID=cd037026--ETC quiet splash
initrd /initrd.img
}

I have found no way to circumvent the Calamares insistence on installing a boot-loader.

Edit 25 April 2024:

This grub2 stanza worked with Kubuntu. Similar might also work with Linux Mint.

menuentry 'Kubuntu 22.04.4 LTS (sda4/boot)'{
search --no-floppy --set=root --fs-uuid 5f904af5-31d4-4401-93de-1f95123edd21
linux /boot/vmlinuz root=UUID=5f904af5-31d4-4401-93de-1f95123edd21 quiet splash
initrd /boot/initrd.img
}

grub2config finds the operating system but doesn't provide it with a name. Simple edit of the title. No symbolic link at the partition's root was necessary. Only the linux line had to be edited. As edited, it calls the vmlinuz in /boot. What grub2config had written is noted below. The files, vmlinuz and initrd.img, are symlinks to the actual specified vmlinuz and intrd. This stanza is preferable because --I think-- if and when the kernel is updated those symlinks are replaced by ones pointing to the new versions. So no further 'user-intervention' would be necessary.

linux line as created by grub2config:
linux /boot/vmlinuz/boot/initrd.img root=UUID=5f904af5-31d4-4401-93de-1f95123edd21 quiet splash

"/boot/initrd.img" above --colored in this post for clarity-- was the error. Editing it out solves the issue.

[mikewalsh]

@mikeslr :-

I know we've all grown used to the business where, if you ARE dual-booting with Windows, there's an on-going battle between Windoze & Linux as to who has the right to control the boot partition. However, it still remains the case that, no matter HOW many partitions you have, or whatever distros you happen to be running, every OS in existence wants to write its bootloader config stuff to the primary partition.

GRUB2 - despite my dislike of the thing - will at least "recognise" any other distro that's written its bootloader stuff to the primary boot partition using GRUB2, and will incorporate those into its 'updated' listing. Puppy, of course, is always the fly in the ointment, because OOTB, 'standard' GRUB2 neither recognises nor understands Puppy's layout.....so we've usually had to manually re-jig things.

Having tried Shinobar's Grub2config utility, I'll confirm that it does seem to work beautifully - for US, at any rate.....but no matter which way you look at it, it's still a 'modified' version of GRUB2, built to take Puppy into account. 'Standard' GRUB2 still ignores Puppy, and you need to use a custom GRUB file to add our Pup into 'the mix'.

I still maintain the simplest way to do multi-booting is to have a separate drive for every OS. Let that OS write its bootloader to that drive's primary partition.....and then use your main boot Menu to "chainload" each and every additional distro's drive.

Simple.....and foolproof. Yeah!

(*shrug...*)

Mike.

[mikeslr]

Mikewalsh, "I still maintain the simplest way to do multi-booting is to have a separate drive for every OS. Let that OS write its bootloader to that drive's primary partition.....and then use your main boot Menu to "chainload" each and every additional distro's drive."

I agree with you. My puppies are on a separate partition: either sda2 with a Major on sda3 or vice-versa. But as my OP suggests, some or all of the major distro's I tried 'messed' with sda(1) and grub2config can only write to sda(1).

On my Dell laptop what I eventually had to do to overcome the Notice that grub2config was unable to write a required file to sda was:
(1) Use gparted to create a new ms-dos partition table --wiping out everything.
(2) Deploy a Puppy to, say. sda2.
(3) Install the grub4dos boot-loader.
(4) Deploy Linux-Mint to sda3 without a boot-loader (via ubiquity -b).
(5) Boot into Puppy.
(6) create the top-level symlinks as noted in the OP.
(7) Install grub2config to sda1.
(8) Edit the grub stanza for Linux Mint as noted in the OP.

The Dell Laptop was not structured as UEFI. Not use if the above would have worked if it had been. Not sure (un-tried) I could have kept grub4dos as boot-loader.

[wiak]

I can't verify any of it just now, but seems to be some useful related info here: https://forums.linuxmint.com/viewtopic.php?t=397103

By default, Mint (or any Ubuntu derivative) will put its boot loader on the first drive it sees, regardless of what you specify in the installer (it's a bug of long standing). Usually this will be the SSD and therefore Mint's boot loader will go in the same EFI partition as you're currently using for Windows. FWIW, this is how UEFI was designed and not a problem, but some users prefer to keep the two systems separate. If that's your preference, you need to (a) be sure to put a second EFI partition on the HDD; and (b) disconnect the Windows drive while installing Mint or disable its EFI partition. With a tower, the former usually is pretty simple. If you would like to know how to do the latter, let us know and someone can explain. It's a pretty simple procedure, just new to you.

Be aware, it's not possible to completely separate the two systems. UEFI boot is managed by firmware settings stored in NVRAM. Your computer only has one NVRAM store for this purpose and the UEFI settings matter much more than the boot loaders, as the settings are what determine boot priority. So, don't get too hung up on separate. If you really care about that, you should be installing to separate computers.

Similar looking info is: https://forums.linuxmint.com/viewtopic. ... 4#p2331914

https://forums.linuxmint.com/viewtopic. ... 8#p1336558