[SOLVED] Damaged my other Linux OS using Mint installer

[Joe2Shoe]

What is Partition 2 and what's on it? Use Gparted to find out.

[sanmig]

What is Partition 2 and what's on it? Use Gparted to find out.

Partition 2 is the extended partition of the SSD, I've linked the image before but it doesn't show up as a thumbnail or inline :



Both, sda5 and sda6 were created by PCLOS, Mint Tara boots from sda7 (created in Mint using "Something else").

Again, Disks is only confused when GParted is / was started before, but until the next reboot.
Rem:
Watching Nemo when starting GParted the section "Devices" disappears. The same moment Disks goes crazy. Closing GParted the Devices come back to Nemo, but Disks does not come back to recognizing partition 2, also not after close/open Disks again.

More likely GParted doesn't vanish completely?

[sanmig]

Sorry, forgot to post Disks before GParted:

https://pasteboard.co/HSiTnBX.png

Strange, ext2 (v1.0) not mounted, but Mint running from sda7?

[sanmig]

I think I'll start a dedicated thread for the GParted / Disks issue, keeping this one to find out what the installer has done to my PCLOS installation.

I still have no clue how Mint interfered with the other OS.

[gm10]

Again, Disks is only confused when GParted is / was started before, but until the next reboot.

See the udve bug I linked earlier. But you don't need GParted anyway, just use Disks for everything.

[sanmig]

But you don't need GParted anyway, just use Disks for everything.

However, GParted is the well known, often referenced partition manager. It may cause the problem, but Disks is the program to show wrong data.

But as I wrote, I wanted this thread to learn about damaging PCLOS by installing Mint19.

- Would that be the same with 19.1 (because if not I'd have start from zero)?

- Would be GRUB the next suspect?
In my Mint grub.cfg at the PCLOS section there is a line "resume=UUID514aabla..." but no such drive / partition is mentioned in Mint lsblk -f ?

So resume would point to an invalid partition, if: How come
Should I try to correct it manually (sda5 PCLOS swap), just to see?

Code: Select all

(I've removed the PCLOS swap sda5 from Mint /etc/fstab)
san@san-Mint:~$ lsblk -f
NAME   FSTYPE LABEL    UUID                                 MOUNTPOINT
sda                                                         
├─sda1 ext2   PCLOS    a69ceebe-ff4f-449d-ae91-07ae20e65340 
├─sda5 swap            e6a556d2-fad2-4105-bfd3-cfb8f6459c35 
├─sda6 ext4   Evo100GB 6ec9596b-6098-4a3c-8887-c895c1b6f76a 
├─sda7 ext4            f2bcc2f9-96d4-4b75-bff1-f4b0f21194b9 /
├─sda8 swap            597d68e4-62b2-4ce2-b558-8192ec73f5ad [SWAP]
└─sda9 ext4            8c6d85b3-bc30-4d36-8621-b1294320e3f5 /home
sdb                                                         
├─sdb1 ext4            fac4cab1-767f-4abb-90a3-13f966aa2be5 
└─sdb2 ext2            a69ceebe-ff4f-449d-ae91-07ae20e65340 
sr0                                                         
san@san-Mint:~$ 

[gm10]

- Would be GRUB the next suspect?
In my Mint grub.cfg at the PCLOS section there is a line "resume=UUID514aabla..." but no such drive / partition is mentioned in Mint lsblk -f ?

That UUID might refer to a swap file but otherwise it's obviously a problem. Remove it and see what happens. You only need something like that if you're planning on hibernating that system.

[sanmig]

That UUID might refer to a swap file but otherwise it's obviously a problem. Remove it and see what happens. You only need something like that if you're planning on hibernating that system.

Guess I was too optimistic.
It seems the line in grub.cfg is not starting with the resume, so I don't know where to cut it out.
I'll try to read more about that.
- Is this (with root=UUIDa69ceebe...) the line to start PCLOS?
- And the resume-part to cut out?

Code: Select all

### END /etc/grub.d/20_memtest86+ ###

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'PCLinuxOS (on /dev/sda1)' --class pclinuxos --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-a69ceebe-ff4f-449d-ae91-07ae20e65340' {
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  a69ceebe-ff4f-449d-ae91-07ae20e65340
	else
	  search --no-floppy --fs-uuid --set=root a69ceebe-ff4f-449d-ae91-07ae20e65340
	fi
	linux /boot/vmlinuz-4.18.5-pclos1 root=UUID=a69ceebe-ff4f-449d-ae91-07ae20e65340 ro nokmsboot splash quiet noiswmd resume=UUID=514aab1a-62c4-477b-9953-10f614739687 audit=0 vga=788
	initrd /boot/early_ucode.img
}
submenu 'Advanced options for PCLinuxOS (on /dev/sda1)' $menuentry_id_option 'osprober-gnulinux-advanced-a69ceebe-ff4f-449d-ae91-07ae20e65340' {
	menuentry 'PCLinuxOS (4.18.5-pclos1) 2018 (on /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.18.5-pclos1--a69ceebe-ff4f-449d-ae91-07ae20e65340' {
		insmod part_msdos
		insmod ext2

[gm10]

Why, just cut that entire resume=UUID=514aab1a-62c4-477b-9953-10f614739687 part out, reboot into PCLOS and see if it makes a difference. Although the value must be configured somewhere on the PCLOS side as well for GRUB to detect it.

[sanmig]

... Although the value must be configured somewhere on the PCLOS side as well for GRUB to detect it.

Good point!
The Mint grub.cfg section seems to be a copy of the PCLOS grub.cfg, there is the same resume=UUID=514aabla.... mentioned.
Obviously was this originally the UUID of the PCLOS swap. It seems Mint installer has changed the UUID of sda5 to claim it as it's own.

Now, checking the Mint grub.cfg, the new UUID for sda5 swap (e6a55...) is nowhere mentioned, and the Mint sda8 swap, that I have created during install, is also missing.
So Mint doesn't hibernate per default.

However, the "old" sda5 UUID is 6x there:
PCLinuxOS + Advanced Options with Kernel 4.18.5, + PCLinuxOS with 4.11.8,
as well as the same entries 3x pointing at my PCLOS safety copy on sdb2.

- Strange:
a) The Mint grub.config retrieved information from other grub.cfg files before changing swap UUID
(likely GRUB is running before Mint installer is claiming sda5 and/or they don't know each other).

b) I did not expect GRUB to copy from those other grub files, I thought it would rather point at them?

This is what I was chewing on: Would I ever get the PCLOS-grub menu back when once selecting PCLOS instead of Cinnamon with the new GRUB?
Now it seems as Mint grub.cfg would start PCLOS and the PCLOS grub.config is out of work.
But I'll check that.

First I try to change the UUID only in the Mint grub.cfg (6x) - No, doesn't work, same panic than before.

So I'm going to change the PCLOS grub.cfg as well. Here in /boot I see there is a directory grub and a directory grub2 (I did not notice this small difference before ).
The grub doesn't have a grub.cfg, but grub2 has it. This may be another issue, however, I'll try:

In the PCLOS grub.cfg there are only 2 resume entries with UUID=514aab..., not 3, one for 4.18.5 and the other for 4.11.8 Kernel.
Anyway, changed both to sda5 (e6a556...).

But no success, same panic than before!
OK, it would have been too easy if the wrong UUID in the grub.cfg would be the cause.

- But the point with grub + grub2 folder on PCLOS may well be an issue!

***
However, it's Christmas, I think we should stop tinkering now, but instead relax and charge our batteries:

Thank you again for your help, I wish you some quiet days and a

Merry Christmas to you - and to all the Minters out there!

[gm10]

There's only ever one boot loader. Which grub.cfg it reads basically depends on which system last ran grub-install (which then changes the boot sector to point to the respective partition).

And I agree, merry christmas to you and yours/talk to you after the holidays.

[sanmig]

There's only ever one boot loader. Which grub.cfg it reads basically depends on which system last ran grub-install (which then changes the boot sector to point to the respective partition).

OK, after reading about GRUB2 booting OSes, I found the problem located in the (Mint) grub.cfg section for PCLOS (see the code snippet above from Dec. 23rd).
First it correctly loads the latest vmlinuz-4.18.5-pclos1 linux kernel.
Then it goes on to load initrd, but only the microcode-update:
initrd /boot/early_ucode.img,
the real initial ramdisk is missing.

The line must read:
initrd /boot/early_ucode.img /boot/initrd-4.18.5-pclos1.img

I've edited the grub.cfg manually and PCLOS started immediately from the (Mint installed) Grub menu.

Then I've deleted the manually added initrd-part, checked back (panic as expected) and then run the update-grub from a Mint terminal, hoping it would find the problem itself.
But it didn't:

Code: Select all

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.15.0-39-generic
Found initrd image: /boot/initrd.img-4.15.0-39-generic
Found linux image: /boot/vmlinuz-4.15.0-20-generic
Found initrd image: /boot/initrd.img-4.15.0-20-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
Found PCLinuxOS on /dev/sda1
Found PCLinuxOS on /dev/sdb2
done

So I'm stuck at the moment with manually editing the grub.cfg file.
Where to go from now?

Is the concept of early-ucode.img
https://pclinuxoshelp.com/index.php/CPU_Microcode
not known to GRUB2 (installer)?

To me it seems the (Mint) Grub has taken a copy of the original PCLOS grub.cfg (thus the now obsolete swap UUID because Mint claimed it),
but did not fully copy the initrd - line, it stopped at the blank after the first entry?

And update-grub doesn't care any more, because the (incomplete) PCLOS-entry is already there?

[gm10]

Is the concept of early-ucode.img
https://pclinuxoshelp.com/index.php/CPU_Microcode
not known to GRUB2 (installer)?

Responsible here would be the os-prober package, which contains the script that GRUB uses to automatically detect and add other installed operating systems. Apparently (and surprisingly to me) that does either not support the concept or is otherwise bugged in applying it. I didn't check the code on that one.

Does your PCLOS create a symlink to the kernel initrd? Like on Mint the last installed kernel will always be at /initrd.img. If yes, then you could add this to your /etc/default/grub

Code: Select all

GRUB_DISABLE_OS_PROBER=true

and add the PCLOS entry manually by scripting it in /etc/grub.d. Typically you'll add it to /etc/grub.d/40_custom. Make sure to point it to the symlink so changes to the PCLOS kernel won't affect it.

When you then run update-grub it will automatically include those entries and having disabled os-prober ensures they won't get duplicated.

PS: If desired, you can also disable os-prober only for the PCLOS partition but keep it for everything else. The configuration line would then be GRUB_OS_PROBER_SKIP_LIST=UUID, with UUID being the UUID of the PCLOS partition.

[sanmig]

Interesting workarounds, thanks, I'll try that (after reading more details from GRUB2). I guess the Microcode update would be possible to include as GRUB2 basically understands the line with 2 initrds. I have yet to see how this is done in Mint.
- But you know I prefer the straight, automated and n00b-friendly way

Does your PCLOS create a symlink to the kernel initrd?

Yes, there is a /boot/initrd.img in PCLOS, it reports the same size as the initrd-4.18.5-pclos1.img (but the "Type" is "Link to Unknown" in Mint, I dunno). However, it would only start the initrd-4.18.5-pclos1 without a chance for loading the initrd-4.11.8-pclos1.img at boot.


I see it as a basic GRUB design flaw to copy from the other OS's cfg file.
Why not use the other boot/grub system directly? In PCLOS I had a nice (custom) GRUB menu and could select which kernel version I'd want to boot, that's all lost - while it is still there. Strange.

Or would it be possible to jump from the Mint-GRUB to the other OS-GRUB (similar to chainloading WinWin)?

[gm10]

I see it as a basic GRUB design flaw to copy from the other OS's cfg file.
Why not use the other boot/grub system directly? In PCLOS I had a nice (custom) GRUB menu and could select which kernel version I'd want to boot, that's all lost - while it is still there. Strange.

Or would it be possible to jump from the Mint-GRUB to the other OS-GRUB (similar to chainloading WinWin)?

There's no design flaw, all of that is possible (GRUB is incredibly powerful really). The thing is just that you're using the automated os-prober component which tries to make things as simple as possible and stick it all into a single menu - and apparently fails in this case.

To load another grub.cfg you only need to set the partition it resides on as root in your grub.cfg menuentry and then point to it via a configfile /boot/grub/grub.cfg (or whatever your path is on PCLOS) entry. Should all be in the GRUB documentation.

Theoretically you can also chainload the other GRUB, of course, but in your case with, as far as I understood, both systems on the same disk and installed to MBR that probably won't work, but I guess you could multiboot the other GRUB's core.img instead. But the menu solution above seems easier.

[sanmig]

Yup, it worked with

Code: Select all

configfile (hdo,1)/boot/grub2/grub.cfg

First I've tried from the GRUB terminal and then also from within the Mint-grub.cfg.
That's the best solution in my case, with a working second OS, I'm a happy camper again!

I got a glimpse how mighty GRUB2 is, indeed ...

On the other hand, it's really sad to go into full auto mode with the best intentions and only sub-optimal results. It reminds me of the auto-installer insisting to use the bigger space on the HDD instead of asking. A little bit of more awareness (and less CLI) could bring Linux to more desktops, especially with the failing of the locked-in systems.

So should we close it here with a smile or is there enough to file a bug for the GRUBers?

[gm10]

So should we close it here with a smile or is there enough to file a bug for the GRUBers?

Both I think? Not much else to do around here but definitely sounds like a bug. Should be filed against the os-prober package https://packages.ubuntu.com/bionic/os-prober if you want. I see there is already one filed against the Debian version: https://bugs.debian.org/cgi-bin/bugrepo ... bug=820838 with a patch submitted in 2016 that seems to be going nowhere and that you could try to bump. Or ideally do both. Good luck!

[sanmig]

Should be filed against the os-prober package ... Or ideally do both. Good luck!

I couldn't locate where / how grub is going to use os-prober or linux-boot-prober (part of the os-prober package?).
However, I've bumped the initrd/os-prober Debian issue and filed a new one at Ubuntu.
Grub is a mighty toolbox, but I found more questions than answers.

Again, in my opinion the better way for grub would be to use configfile to jump to an existing bootable Linux system. Why bother with all that strange OSes, they'd much better care for themselves, so keep their grub.cfg.
Good intentions ("automagically, don't confuse the user") remind me of the Mint installer ("let's take the largest free space to install").
It is not easy, see Mi$o auto update / upgrade.

Anyway, thank you again for your patience and insights, I've learned a lot here!

Now I'll delete Tara, make sure PCLOS is up to date, and then restart with installing Tessa.

Btw., did you see my GParted - acquittal in the other thread?
I've set it to solved, too, so RIP.

[gm10]

Yep, I saw. Don't waste too much energy on it, it's such a fringe problem at the end of the day. You don't need GParted that often.

See you on Tessa.