Fresh install Mint 18.3

Hi Mark and a belated Happy New year to you and all forumites!

I’m now good to go for a fresh install of Mint 18.3 64bit on my larger drive (150GiB) - currently with M17 installed. My smaller (40GiB) drive has M18 on it which, if all goes well, I’ll later change to a data only disk. Given the boot issues that I’ve had with this machine in the past, I’ll need to manually partition the drive.

What is the best layout for partitioning please, given I’d like to create a separate home partition as well as boot, / and swap?

Currently, M17 has a small 1st partition (boot) of 500MiB where the boot files reside. Strangely, M18 (on sdb) also has exactly the same partitioning arrangement, but the boot files aren’t in the boot partition! So, given that Mint does not delete old kernels automatically -

1, would it be advantageous to make the 1st (boot) partition a bit larger than 500MiB to accommodate the increasing number of kernels?
2, is it possible to force the boot files to actually land in that 1st partition?

Any advice would be good!


Is this a UEFI system ?

From memory, I think secure boot options are available in the BIOS but I’ve never enabled it. If so, should I use it or leave it disabled?

For info I found this -

richard@richard-OEM ~ $ sudo efibootmgr
[sudo] password for richard: 
efibootmgr: EFI variables are not supported on this system.
richard@richard-OEM ~ $

Edit: I’ve tried using code tags as you previously requested but it’s not working? Unless I’m doing it wrong… most likely!!

Another edit: - Got it! I was using the wrong brackets! (Senior moment)

Is Mint 18.3 to go on a completely separate HDD than Mint 17 but the intent is for it to be dual-boot ?

No, Mint 18.3 is to replace M17 on the main (150GiB) drive. No intention to dual boot with any other system. The slave drive (40GiB) is redundant and eventually will be set up as a data disk only. I only used it as a test bed for M18 64bit to make sure my machine could handle it. It will be disconnected before I do the fresh install on the larger disk. :wink:

In that case I’d just accept the defaults … personally I don’t use a separate /boot or /home … can’t see the point.

As I said in my opening post, “Given the boot issues that I’ve had with this machine in the past, I’ll need to manually partition the drive”.

For some obscure reason, my machine seems to have an issue in picking up the boot files from a standard default installation resulting in black screens and other non-booting problems. On your advice, I created a small (500Mb) boot partition at the beginning of the disk to get around this and it’s worked well since. (Possibly something has changed in the more up-to-date iterations of Mint - but I’m guessing?)

Lately, I had an issue with an updated kernel that refused to boot and found a whole raft of kernels still present. Mint doesn’t remove old kernels automatically - hence the idea of making the partition larger. (I may be wrong here if the kernels sit somewhere else?) The reason for a separate /home partition is to safeguard my data should I have to do a reinstall of the OS in future. NB: I’ve never used a separate /home before but I do plan to also use the other, smaller HDD for data storage once I have M18.3 up and running but would need guidance on how to set this up too.

If you think none of this is necessary, I’ll go ahead with the default installation and take it from there.

A separate /boot shouldn’t be necessary, but I’m not doubting we added one to fix something … I just can’t remember why.

A separate /home partition can be useful if you ever have to reinstall, but IMHO ONLY if you’re installing the same distro/version … iff you’re installing something else, it can cause problems.

If I were you, I’d boot to a LiveUSB … use GParted to delete ALL partitions on the drive leaving nothing but unpartitioned space.

Then close GParted, open the installer, and run a default install … and see what happens.

But if you prefer your method, I can’t see anything that’d cause issues … just make /boot and /home whatever size you want.

Hi Mark

I did the fresh install of Mint 18.3 and all went well - until I got to the updates! (Used the update manager, btw). I allowed all the available updates which included new kernels and headers (I know, I know!) and thought it would be ok as it’s a fresh install… Fat chance! I’m now back at the ‘kernel panic’ I had previously!

I tried running the install disk again and followed your instructions to repair grub from last time but unfortunately, no go this time! Can you help please?



EDIT: I’ve also tried the Linux Repair Disk but no joy there either…

EDIT 2: Something has gone seriously amiss so I’ll start again from scratch and repost when done

If it happens again, try booting the earlier 4.10 kernel from the GRUB screen.

Hi Mark - yes, I tried that but my originally-shipped kernel wouldn’t boot either, so I did a full re-install from scratch and when updating, made sure no new kernels were selected. All seems fine now (fingers crossed!!)

I reconnected my slave drive (with M18.2 on it) and successfully copied all the data across to the new installation. I haven’t updated grub as I don’t intend booting to the slave - it will sit there as a back up for now in case I mess up the new one!

For info: The kernel panic issue has been caused, it appears, due to the problems with the Meltdown exploit. If I’ve read it right, the chips were distributed with a security flaw and downstream developers have been left with the task of correcting this? The Mint team have done so but the patch has caused a lot of system breakages, especially on older hardware. There are newer, secure kernels available but, to be honest, I’m reluctant to try them in case my box breaks again. In your opinion, what, if any are the dangers to an ordinary user, like most of us are? If it’s minimal, I’ll leave well alone and see what develops. If insecure, I’ll get on to Mint and see what they say about older equipment. Btw, have you had to patch Peppermint?

As ever, thanks for all your help. :wink: