| Alexander Kohr via plug on 10 Apr 2020 07:55:56 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: [PLUG] Fixing /boot/ too small |
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 ben 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 > ... > ``` > > Thanks, > 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 > ___________________________________________________________________________ > 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 ___________________________________________________________________________ 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