[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: grub-install problem after trixie upgrade



On Mon, Aug 11, 2025 at 01:57:00AM +0000, Andy Smith wrote:

> > So ... on sda I could delete partition 1 so that it starts at 2048, but there
> > is not enough room as the start of partition 2 is closer to the start of disk,
> > so I would need to make it smaller on sdb as well.

Summary: It is now all working again (I need to do a final reboot to test).

I made sda have the same partition layout as sdb. The only issue is a /boot
that is smaller than trixie recommends, I do not expect this to be a real
issue.

Several steps to get there.

This write up is more by way of commentary than a request for help.

> You don't need /boot to be a separate partition and grub can read MD
> RAID-1 so you could "just":

I tried that, got rid of partition 1, put it all in partition 2.

Instead of wipefs I did: mdadm --zero-superblock /dev/sda1

That failed:

	root@mint:~# grub-install --target=i386-pc  /dev/sda
	Installing for i386-pc platform.
	grub-install: error: unknown filesystem.
	root@mint:~# grub-install --target=i386-pc  /dev/sdb
	Installing for i386-pc platform.
	grub-install: error: unknown filesystem.
	root@mint:~# cat /proc/mdstat 

> Alternatively if you can find a way to shrink the filesystem and RAID
> for sd{a,b}3 you could make an sd{a,b}4 and a new MD device there for
> /boot, as /boot does not need to be at the start of the disk. Depending
> on what you've done with sd{a,b}3 you might not be able to do this one
> without booting into a live/rescue system.

Yes /boot MUST be close to the start of disk. It is a 4TB disk, I believe that
the maximum that BIOS can go is 2TB. BIOS is used for loading the initial
kernel by Grub ... remember that I have an ancient BIOS that only understands
MBR - so there is a risk of it being size limited as well.



Partition 2 is LVM, not file system and so I used pvresize to make it
(temporarily) much smaller - but what happened was:

	# mdadm --verbose --manage --add /dev/md1 /dev/sda2
	mdadm: /dev/sda2 not large enough to join array

Using gparted to make it smaller did not do it either.

This shows it smaller:
	pvs -v --segments /dev/md1

lsblk -lb /dev/md1 showed the size unchanged, even after a reboot. I gave up
which is why I did what I said above.


> As ypu say you could fail out all partitions on sda. Remove all those
> partitions then wipefs the sda disk before creating new ones that match
> sdb and add them back into each RAID. Has the advantage of all being
> done online pretty straightforward. Disadvantage of leaving you with a
> 500M /boot but I think you'll push the problem quite far down the road
> even if the recommendation is now 768M. Don't forget to grub-install
> /dev/sda afterwards!

Which is, roughly, what I did.

Thanks

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>


Reply to: