JP Vossen via plug on 10 Apr 2020 12:07:20 -0700


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

Re: [PLUG] Fixing /boot/ too small

Another good point in case someone finds this in a search! And it sounds like that was a "fun" time.
In my case, it's a RAID-1 with (only ever) 2 disks, so BIOS is fine. This hardware is so old there's no UEFI anyway, so that's moot for me. 

On 4/10/20 10:55 AM, Alexander Kohr via plug wrote:

A heads up since you are using BIOS.   I ran into the situation on a vm where each time the box needed more disk space it was given  a new vdk file. The box "BIOS" based system i wasn't able to see the newest disk it was given because the bios can only the first so many disks. I think the max my BIOS could see was the first 8 Physical disks as I think I was trying to put the new boot volume on an sdi (9th) disk.

So before you do anything make sure the location of your new /boot disk ends up on a disk that the BIOS can see.
If memory serves me correctly for that box we ended up in-ideally putting the /boot directly in the boxes root disk (it may have been a partition-less) root disk directly as /boot and with some additional steps that I don't remember anymore it worked. However it would have been better to have instead moved volumes around  to get a partition onto a disk that would be within the first 8 disks. I wouldn't recommend doing that myself but we were in a pinch at the time as the box went down due to a undetected mess that exploded during a OS/kernel update that was preventing it from booting.

-Alex


On Apr 9, 2020, at 8:07 PM, Keith C. Perry via plug wrote:


I did a bunch of work like this a couple of years ago but not remotely so I would be nervous about it too but as I recall...

1) For boot... just copy its contents to new to the /boot partition (on main partition).  I usually umount /boot and mount it to a tmp location so I can copy directly to the new /boot path.  Then upgrade grub to reflect the new UUID that will be booting (for Ubuntu / Debian distro's there is an "update-grub" command).

2) RAID-1... here is where I'm weird... I don't use mdadm, only straight LVM (which uses mdadm behind the scenes for LVM above a certain version which I forget now... 2.02.140 maybe).  The trick here is to do the "grub-install" to both mirror images- so sda and sdb in your case.  I don't think it matters that you're using mdadm directly instead of LVM but I want to be very honest in saying that I've only even done this with straight LVM.

(Ok, so I wrote that before I saw your steps...  looks good, I've never done the update-initramfs step but that can't hurt.  Only thing missing was my #2 but I don't think its strictly required in your case)

I'm sure you've been meticulous in your testing on the VM but I would be prepared to take that drive and have live cd / usb in your kit.  Grub can be finicky but the mirroring piece of this honestly makes me the most nervous even though that obviously is already working.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Keith C. Perry, MS E.E.
Managing Member, DAO Technologies LLC
(O) +1.215.525.4165 x2033
(M) +1.215.432.5167
www.daotechnologies.com

----- Original Message -----
From: "JP Vossen via plug" <plug@lists.phillylinux.org>
To: plug@lists.phillylinux.org
Sent: Wednesday, April 8, 2020 9:49:39 PM
Subject: Re: [PLUG] Fixing /boot/ too small

On 4/8/20 12:08 AM, brent timothy saner via plug wrote:

On 4/7/20 23:24, JP Vossen via plug wrote:

Summary: I need to fix some Mint-19 workstations where /boot/ is too small.


is it using UEFI or BIOS booting?


They are old, it's BIOS and MBR, but UUIDs are in use in /etc/fstab.
And everything Just Works now, the only thing I need to do is move
'/boot/' from its own md device into '/' so there is space.


`/etc/fstab` excerpt (updated to but not rebooted):
```
# / was on /dev/md2 during installation
UUID=bafdc515-511e-44b9-85d0-e1cd164cc58c /               ext4
errors=remount-ro 0       1

# /boot was on /dev/md1 during installation
#UUID=21fd376b-fa9a-4dd0-bfa3-f3ca314d0648 /boot           ext4
defaults        0       2
# 2020-04-07 /boot/ HACK
UUID=21fd376b-fa9a-4dd0-bfa3-f3ca314d0648 /boot.old        ext4
defaults        0       2
```

And (edited for clarity):
```
$ df -hl
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/md2       ext4      913G  285G  582G  33% /
/dev/md1       ext4      190M   86M   90M  49% /boot.old

$ lsblk -f
sda
├─sda1  linux_raid_member mint:0 9ce43e0d-5683-e2fb-e0e5-abaaf06ca0f8
│ └─md0 swap                     314df59b-cdd2-46a4-b07b-9d0bfb77b0f7
├─sda2  linux_raid_member mint:1 79eb3cbb-2e42-5a08-4be3-39ff2a609919
│ └─md1 ext4                     21fd376b-fa9a-4dd0-bfa3-f3ca314d0648
/boot.old
└─sda3  linux_raid_member mint:2 e696d253-57f3-ca09-c8ec-d5b452209e51
   └─md2 ext4                     bafdc515-511e-44b9-85d0-e1cd164cc58c /
sdb
├─sdb1  linux_raid_member mint:0 9ce43e0d-5683-e2fb-e0e5-abaaf06ca0f8
│ └─md0 swap                     314df59b-cdd2-46a4-b07b-9d0bfb77b0f7
├─sdb2  linux_raid_member mint:1 79eb3cbb-2e42-5a08-4be3-39ff2a609919
│ └─md1 ext4                     21fd376b-fa9a-4dd0-bfa3-f3ca314d0648
/boot.old
└─sdb3  linux_raid_member mint:2 e696d253-57f3-ca09-c8ec-d5b452209e51
   └─md2 ext4                     bafdc515-511e-44b9-85d0-e1cd164cc58c
...
```

Later,
JP
--  -------------------------------------------------------------------
JP Vossen, CISSP | http://www.jpsdomain.org/ | http://bashcookbook.com/
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug