[TriLUG] What might I be getting myself into?...
Roger via TriLUG
trilug at trilug.org
Wed Dec 21 13:00:32 EST 2016
/boot commonly fills because old kernels and associated cruft are not automatically deleted. Try, as root (sudo) apt-get autoclean. (I'm going from memory on this!)
Otherwise, ubuntu tweak has the ability to do this. Probably no need to resize and otherwise muck around with partitions.
Lemme know if this works.
--
Roger Broseus
(Please excuse tiepos induzed by the droided predictive text tool.)
On December 21, 2016 12:46:10 PM EST, Ken Mink via TriLUG <trilug at trilug.org> wrote:
>I've had to resize a /boot a couple times. If you're using lvm, you can
>
>free up the primary drive without taking the machine down.
>
>
>1. Attach a USB drive
>
>2. Extend the VG into the drive.
>
>3. pvmove all the data from the primary drive to the USB drive.
>
>4. vgreduce the primary drive out of the vg.
>
>5. backup /boot and unmount it.
>
>Now you're primary drive is not in use. Do what ever partitioning you
>need to.
>
>6. Remount and restore /boot(if needed)
>
>7. Extend the vg back into the primary drive
>
>8. pvmove everything back
>
>9. vgreduce the USB drive out of the vg
>
>10. Disconnect the USB drive
>
>
>The machine doesn't need to come down through the process. pvmove
>operates a very low priority. The performance of the machine should not
>
>be affected. It will take time, however.
>
>Ken
>
>p.s. The above is a summary. There are commands left out for brevity.
>
>
>On 12/21/2016 02:57 PM, Brian via TriLUG wrote:
>> Hiya folks,
>>
>> So, I've got my server basically back up and running satisfactorily
>> from the weekend's excitement. Except for one thing: /boot is too
>> small. I didn't want to lose an important partition on the one HDD
>in
>> the box, so I reused all the existing partitions from the previous
>> CentOS 5 setup. Go figure, kernels have grown since then, and a 100
>MB
>> /boot partition isn't enough to hold more than one kernel image.
>>
>> It isn't really a huge deal at the moment, although it means I can't
>> update the kernel with yum, and it means logwatch whines about /boot
>> being almost out of space. But...I'd like to make the situation
>> better, eventually. I see two apparent options:
>>
>> 1) Back up the entire drive (500 GiB), wipe the whole thing,
>> repartition from scratch, reinstall everything, basically throw away
>> the work I did these past few days
>>
>> 2) Get a secondary drive, maybe a small SSD, that I can tuck inside
>> the machine to hold /boot (it's a very compact 1U rack enclosure; no
>> room for more than one 3.5" HDD, but I could probably squeeze a 2.5"
>> SSD in there) and perhaps other system partitions
>>
>> My instinct is toward option 2, but I wonder how smoothly it would
>go.
>> fstab has all the partitions identified by UUID, so I suppose it
>would
>> continue to find them; as long as I correct the kernel boot arguments
>
>> to find /, should it all just work?
>>
>> This is my (only) server/router, so I'm reluctant to just experiment.
>>
>> Thanks in advance for all insights!
>> -Brian
>
>--
>This message was sent to: Roger <rogerb at bronord.com>
>To unsubscribe, send a blank message to trilug-leave at trilug.org from
>that address.
>TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
>Unsubscribe or edit options on the web :
>http://www.trilug.org/mailman/options/trilug/rogerb%40bronord.com
>Welcome to TriLUG: http://trilug.org/welcome
More information about the TriLUG
mailing list