| 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 |
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