Buggered up my Mint partition

fox · February 19, 2019, 05:52:03 PM

I messed up my internal Mint 19.1 partition on my 5k iMac when I tried to install Ubuntu on an external SSD. The installation froze at some point, and rebooting into Mint now takes about 3 minutes instead of 20 seconds. I think it may have had to do with my asking the installer to put grub onto the external drive instead of the internal. The slow reboot now happens whether the external is plugged in or not.

I want to fix this; Mint has been great on this machine. Note that I have no separate partition for my /home folder, though I do have a backup through Timeshift.

In Ubuntu, one can reinstall the same version of a distro over the same partition without losing data files or settings. This doesn't seem to be the case with Mint, or at least I can't find any reference to it on the internet. Any suggestions as to how I can fix this? Perhaps all it would take is a grub reinstall? Can I do that from the working Mint partition or should it be from an installation disk? I know that one possibility is boot-repair, but I would like to avoid that if possible because it seems to add useless options to the boot menu.

Jason · February 19, 2019, 06:18:40 PM

I would try a grub reinstall since it'd be easier than the other options. It's best to do it from within the Linux Mint that is installed since you can still get in there. You can do it from another boot disk but it's a bit more complicated as you're not changing grub on the boot disk but on the installed disk.

Timeshift, by default, doesn't back up your home folder but you can set it to this. I'm not sure about installing LM over itself. You could always make room for a separate partition for home, move your files onto it and then re-install LM and telling it that you use that partition as /home under custom settings. It'd be under custom partitioning.

You could also try re-running the LM install and when you get to that section, see if it gives you the option to not format that partition when installing.

Regardless, I'd make sure your /home directory is backed up somewhere just to be safe before you make any changes.

Jason · February 19, 2019, 06:24:18 PM

Timeshift won't have a backup of the the actual grub bootloader because it's on the MBR. It will have a backup of the configuration file that was used to create the MBR the last time it was updated so re-running the grub repair (grub-install???) would still be necessary.

fox · February 20, 2019, 12:41:16 PM

I managed to find part of the problem. The /etc/fstab table in Mint had a UUID for a swap partition that didn't exist. When I changed the UUID in the fs table to match the UUID of the swap partition, that cut 1 1/2 minutes off the boot time. But it's still about 50 sec; 20-30 more than what I think it was. Watching the boot sequence, it seems to get stuck for about 30 seconds on something related to my video driver, with a repeated message "amdgpu (powerplay) ... failed to send message" or premessage. I googled it without success.

I reinstalled grub after this in my 19.1 installation, but it didn't take the message away, nor speed up booting. I tried with several kernels I had installed (two 4.15's and an old 4.

; all did the same thing. I also tried booting up another partition with Mint 18.3; same error messages. Ubuntu18.04 doesn't seem to have this problem; it boots up in 20 sec.

Jason · February 20, 2019, 01:36:44 PM

There's probably a kernel parameter that can be removed or added (like using =disable with an option) that will fix it. Don't know which one it is though.

Jason · February 20, 2019, 06:31:48 PM

You might want to compare the kernel parameters passed in Ubuntu against those with Mint. When Grub comes up, you can press e to edit an entry. That gives you a chance to view the complete information parameters passed. Since it's on the same hardware and LM 19.x is based on Ubuntu 18.04, you should be able to use the same parameters (related just to the kernel) from Ubuntu with Mint.

https://wiki.ubuntu.com/Kernel/KernelBootParameters

fox · February 25, 2019, 02:42:24 PM

Quote from: Jason Wallwork on February 20, 2019, 06:31:48 PM
You might want to compare the kernel parameters passed in Ubuntu against those with Mint. When Grub comes up, you can press e to edit an entry. That gives you a chance to view the complete information parameters passed. Since it's on the same hardware and LM 19.x is based on Ubuntu 18.04, you should be able to use the same parameters (related just to the kernel) from Ubuntu with Mint.
....

I did that, and the boot parameters are identical except for reference to the specific UUID. Yet Ubuntu boots in 23 sec, Mint in 48, all because of the amdgpu message. I also have Mint 18.3 installed on an internal HD and when booting it, I get the same stalling problem that I do with Mint 19 on the internal SSD.

I also tried booting with a Mint 19.1 installer. Interestingly enough, the installer boots faster than either installed version of Mint. What is going on here? What I might try is a new installation from that installer to see what happens then and if it boots quickly, I might replace my current version with this one. Either that or replace Mint with Ubuntu.

fox · February 26, 2019, 07:26:00 PM

I followed through with a new installation, and after that, I restored a version stored on Timeshift before I noticed the slow boot, putting it on a different partition. Neither one produced a faster booting version of Mint without the amdgpu slowdown. This is making me wonder whether the slow boot wasn't always there, but I hadn't noticed it before. At any rate, fixing the 20-30 second "amdgpu [powerplay]" boot delay" is out of my pay grade. I give up.

Jason · February 26, 2019, 07:29:19 PM

That makes it really likely it was likely always there. I mean you recreated the boot loader and the exact OS configuration during Time Machine. Everything is the same as it was before unless you changed a BIOS/EUFI setting which it doesn't sound like you did.

fox · March 06, 2019, 12:42:30 PM

Well if this isn't strange, after upgrading a MacOS partition, I rebooted into Mint. Although I still got same messages, the delay was gone and Mint booted up at least as fast as Ubuntu (20 sec). This also convinces me that it wasn't the long boot before, but rather that something I did on another partition had a negative effect on the amount of time it takes for Mint to boot up. I wish I knew the cause.

Jason · March 06, 2019, 11:39:11 PM

Had you done any updates between the last time you booted into it and when you adjusted the partition?

You upgraded a MacOS partition? Do you mean you just upgraded the MacOS and didn't change the partition because that would make no sense why it would be able to boot faster as a result. I doubt Linux cares what is on a foreign partition but changing the size might help grub if the drive geometry was slightly off and changing the size corrected it.

fox · March 07, 2019, 07:49:36 AM

My internal blade SSD is only 128 gb and with Mint and Ubuntu partitions on it, I'm running out of space. My thought was to remove the Ubuntu partition, leaving the entire to Mint (my main distro on this computer). The intent is to move it to the new external SSD.
I wanted a more responsive MacOS than the slow booting and running Mac partition on the internal spinning drive.

Jason · March 08, 2019, 12:29:47 AM

Okay, so if I understand you correctly, the drive that now has Mint on it had been restored (I didn't see you mentioning a Mint partition) after having been cloned and it was that drive (internal) basically had an entirely new partition table?

If that's the case, it could definitely have something to do with how it was partitioned before. I've sometimes noticed errors about overlapping partitions or them not aligning properly, I honestly forget the exact error message. But maybe it had something to do with why Mint took longer to boot before. And in the re-partitioning, you "accidentally" fixed a partition error that you didn't know existed. We'll probably never know.

fox · March 08, 2019, 07:52:50 AM

It's all academic now, but your explanation doesn't seem consistent with the fact that the slow boot only affected Mint and not Ubuntu, when both partitions were on the same drives. Also, it wasn't the drive with Mint on it that was restored. I had Mint on both internal drives (SSD blade and HD); the restored drive was the external SSD. There was a point when I had Mint on the external SSD as well. It was a test I ran after the slow boot problem appeared. I installed Mint from scratch onto that drive just to see if it would also slow boot; it did. Incidentally, disconnecting the external SSD and booting Mint on the internal blade SSD still resulted in a slow boot - until the external SSD was reformatted as gpt. (It had previously been formatted as MBR; not purposely.)

One of the wildcards I'm working with by running Linux on Mac hardware is the refind boot manager. What it does that grub doesn't is to show, with icons, all of the bootable partitions connected to the computer at startup. You then select which partition to boot by selecting its icon. Grub doesn't pick up Mac partitions, or on the few distros where it does, you can't boot a Mac partition by selecting it in grub; grub doesn't configure it correctly. (I've read that one can manually add a MacOS partition to grub and it works, but I never tried this.) To get this to work, you install refind from a Mac partition. The only other way I know of to boot a Mac partition with just grub is to bypass grub by holding down the option (alt) key when you boot. It's possible that refind was a part of the problem; I'll never know. But again, if refind was the problem, why did it only affect Mint partitions and not Ubuntu ones?