[opensuse] Idea / Help needed: /boot is too small, how do I resize a bog standard partition with filesystem?
Hi,
(this is on 15.2)
today's kernel update barfed on me, "package kernel-xxxx needs YY MB on /boot". I managed to install the update by manually moving the old kernel images to /tmp, installing the update rpm, and then moving them back, but for obvious reasons I don't want to have to do that with every kernel update, so here's the plea for inspiration:
how can I resize /dev/sda1 and the filesystem on it, without loosing anythign on my system?
The situation:
/dev/sda[abcd] exist. /dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot /dev/sda2 covers the rest of the disk, and is a PV for LVM /dev/sd[bcd]1 all exist, span their whole disks, and are PVs in the same VG as /dev/sda2
I have enough room to do a pvmove from /dev/sda2 to anywhere else if i resize a few of the volumes in my VG, so getting to the point where /dev/sda1 is all that's left on /dev/sda should be easy enough, but I've never resized a normal partition - learned about LVM too early in my career ;)
How do I resize a normal partition and the filesystem on it? Like I already said, filesystem is ext4.
Cheers Mathias
Mathias Homann wrote:
How do I resize a normal partition and the filesystem on it? Like I already said, filesystem is ext4.
Kurz und bündig: You extend that partition and then you run resize2fs.
I guess the real issue is how to get some more room for sda1 ?
Move all data off your sda2, remove from VG, probably also pvdelete. Delete partitions sda2 and sda1, recreate sda1 at the same starting point, but with more room. Recreate sda2. resize2fs sda1.
Have someone look over the above, just in case I missed something.
Am 2020-07-07 09:12, schrieb Per Jessen:
Mathias Homann wrote:
How do I resize a normal partition and the filesystem on it? Like I already said, filesystem is ext4.
Kurz und bündig: You extend that partition and then you run resize2fs.
I guess the real issue is how to get some more room for sda1 ?
No, that's all just plain LVM - pvmove, pvremove, delete sda2, that's peanuts, I have been teaching RHCE students for five years how to do that...
Delete partitions sda2 and sda1, recreate sda1 at the same starting point, but with more room. Recreate sda2. resize2fs sda1.
this is the actual issue - the only solutions I've found all involve deleting and recreating the partition and I'm just a bit ... i guess scared by that. If I break that system I won't have working internet or email at home until i reinstall it, and my wife's totally hooked on this series on netflix right now...
I'm just thinking "what if the block addressing scheme in the partition table has been changed in the meantime", the partition table is over 7 years old...
Cheers Mathias
Mathias Homann wrote:
Delete partitions sda2 and sda1, recreate sda1 at the same starting point, but with more room. Recreate sda2. resize2fs sda1.
this is the actual issue - the only solutions I've found all involve deleting and recreating the partition and I'm just a bit ... i guess scared by that.
I totally understand.
If I break that system I won't have working internet or email at home until i reinstall it, and my wife's totally hooked on this series on netflix right now...
Yes, that is something to worry about, agree :-)
I'm just thinking "what if the block addressing scheme in the partition table has been changed in the meantime", the partition table is over 7 years old...
Those things are not changed so fast. The MS-DOS partition table goes back to .....
I don't know if it makes you feel more comfortable, but the changing of the upper partition boundary is really not very different to doing an lvextend and resizing the filesystem.
Am Dienstag, 7. Juli 2020, 10:55:40 CEST schrieb Per Jessen:
I don't know if it makes you feel more comfortable, but the changing of the upper partition boundary is really not very different to doing an lvextend and resizing the filesystem.
I'm creating a bootable USB stick with gparted right now. That should take care of it.
Cheers Mathias
Am 2020-07-07 12:23, schrieb Mathias Homann:
Am Dienstag, 7. Juli 2020, 10:55:40 CEST schrieb Per Jessen:
I don't know if it makes you feel more comfortable, but the changing of the upper partition boundary is really not very different to doing an lvextend and resizing the filesystem.
I'm creating a bootable USB stick with gparted right now. That should take care of it.
That worked quite quickly and well. Now /boot is 350MB instead of 150MB, that should take care of any kernel updates in the foreseeable future.
Related: is there a way to "rebalance" a LVM?
Cheers Mathias
On 07/07/2020 13.06, Mathias Homann wrote:
Am 2020-07-07 12:23, schrieb Mathias Homann:
Am Dienstag, 7. Juli 2020, 10:55:40 CEST schrieb Per Jessen:
I don't know if it makes you feel more comfortable, but the changing of the upper partition boundary is really not very different to doing an lvextend and resizing the filesystem.
I'm creating a bootable USB stick with gparted right now. That should take care of it.
That worked quite quickly and well. Now /boot is 350MB instead of 150MB, that should take care of any kernel updates in the foreseeable future.
That was pretty fast :-o
Related: is there a way to "rebalance" a LVM?
It just occurred to me that you could place /boot at the end of the disk. It is easier to move the end of a partition than the start.
On 2020-07-07 07:10 AM, Carlos E. R. wrote:
It just occurred to me that you could place /boot at the end of the disk. It is easier to move the end of a partition than the start.
I seem to recall some issues with that, at least with BIOS rather than UEFI configurations.
On 07/07/2020 15.28, James Knott wrote:
On 2020-07-07 07:10 AM, Carlos E. R. wrote:
It just occurred to me that you could place /boot at the end of the disk. It is easier to move the end of a partition than the start.
I seem to recall some issues with that, at least with BIOS rather than UEFI configurations.
Ancient history, no longer relevant :-D
Read: https://www.tldp.org/HOWTO/Large-Disk-HOWTO-4.html
Mathias Homann wrote:
Related: is there a way to "rebalance" a LVM?
The only way I know of is pvmove data to other disk, then pvmove back.
On 2020-07-07 07:31 AM, Per Jessen wrote:
Mathias Homann wrote:
Related: is there a way to "rebalance" a LVM?
The only way I know of is pvmove data to other disk, then pvmove back.
https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)#Basic_functiona...
On 07/07/2020 07:31, Per Jessen wrote:
Mathias Homann wrote:
Related: is there a way to "rebalance" a LVM?
The only way I know of is pvmove data to other disk, then pvmove back.
I recall trying that with AIX, which had the "Veritas disk system" which was the AIX version of what became LVM under Linux. I had a LOT (as in tens of terabytes and hundreds of spindles) to work with.
The answer is both yes and no. If you move back onto a LV that is striped across a number of spindles, then maybe. It depends on how many disk access channels you have. It also depends on what you are transferring, and what the application to access it is[1].
We had a DB2 application. OK so its not as all-in-one as CICS. the 'code' side got loaded and that was that. The traffic was the DB2 database, which was VERY^3 active. The DBA and I spend my weeks trying to figure out where to put the tables that were 'static' (e.g 'lookup') and what was degrees of 'dynamic'. IBM support was less than helpful. It turned out we knew more about how DB2 performed (and in due course AIX) than they did.
BD2 managed things it's own way quite regardless of our efforts with striping.
Just as I hated the "one application to rule it all" attitude of CICS (and it's imitators on Tandem and elsewhere) I came to hate DB2 attitude towards disks management.
I also hate BtrFS's 'one file system to to manage all disks' attitude.
OK, so I'm an old UNIX fogie of the "Each thing does one thing, just one thing and does it well" school.
[1] There are many specific answers to that were a SSD is the answer. Perhaps you want an ultra-fast boot[2]. Maybe you want fast program load. Maybe you need fast data access for some value of data. Maybe you can afford the terabytes of SSD and do it all.
[2] I get up in the morning and turn the computer on as I pass by on the way to the bathroom. On my way back I log in. By the time my coffee is brewed all my email is collected and sorted and de-spammed; my web browser is up and pages renewed, etc etc. Fast boot is not an issue for me.
On 2020-07-07 07:06 AM, Mathias Homann wrote:
Related: is there a way to "rebalance" a LVM?
It's been a while since I've used LVM, but I thought that was one of it's features, in that it was easy to resize partitions. Back when I had an IBM Netfinity server, I'd set up one large partition on each of the 4 RAID drives and then use LVM to create the various partitions as needed.
James Knott wrote:
On 2020-07-07 07:06 AM, Mathias Homann wrote:
Related: is there a way to "rebalance" a LVM?
It's been a while since I've used LVM, but I thought that was one of it's features, in that it was easy to resize partitions.
Resize != "re-balance". I take it Mathias meant "re-balance" = distribute the data equally (more or less) over the PVs available.
On 07/07/2020 09:39, Per Jessen wrote:
James Knott wrote:
On 2020-07-07 07:06 AM, Mathias Homann wrote:
Related: is there a way to "rebalance" a LVM?
It's been a while since I've used LVM, but I thought that was one of it's features, in that it was easy to resize partitions.
Resize != "re-balance". I take it Mathias meant "re-balance" = distribute the data equally (more or less) over the PVs available.
Please do read the 'lvcreate' man page. In particular look at 'contiguous' and 'stripe' and how metadata is going to be handled.
On 07/07/2020 07:06, Mathias Homann wrote:
Related: is there a way to "rebalance" a LVM?
Can you explain what you mean by that, please.
On 2020-07-07 04:55 AM, Per Jessen wrote:
I'm just thinking "what if the block addressing scheme in the partition table has been changed in the meantime", the partition table is over 7 years old...
Those things are not changed so fast. The MS-DOS partition table goes back to .....
I don't know if it makes you feel more comfortable, but the changing of the upper partition boundary is really not very different to doing an lvextend and resizing the filesystem.
What I'd be tempted to do is get a new drive, partition it as required and then copy over the contents. Disks have gotten a lot bigger and cheaper in 7 years. Perhaps change to SSD as well. You might also use the opportunity to switch to UEFI, if you haven't already done that. That gets rid of all that extended partition nonsense.
You can then put the old drive in an external case and use it for backups, etc.. I have a couple here that I've done that with.
On 07/07/2020 04:55, Per Jessen wrote:
I don't know if it makes you feel more comfortable, but the changing of the upper partition boundary is really not very different to doing an lvextend and resizing the filesystem.
Oh no it is not!
You can do a lvextend with the system running and the file system in use. With some file systems such as ReiserFS you can do that while resizing the file system as well.
That sort of flexibility - 'late binding' - is why I like LVM. I think Mathias is probably in agreement there.
It is also why I long for the development and acceptance into the mainstream of Reiser4FS.
On Tue, 07 Jul 2020 09:52:26 +0200 Mathias Homann Mathias.Homann@openSUSE.org wrote:
Am 2020-07-07 09:12, schrieb Per Jessen:
Mathias Homann wrote:
How do I resize a normal partition and the filesystem on it? Like I already said, filesystem is ext4.
Kurz und bündig: You extend that partition and then you run resize2fs.
I guess the real issue is how to get some more room for sda1 ?
No, that's all just plain LVM - pvmove, pvremove, delete sda2, that's peanuts, I have been teaching RHCE students for five years how to do that...
Delete partitions sda2 and sda1, recreate sda1 at the same starting point, but with more room. Recreate sda2. resize2fs sda1.
this is the actual issue - the only solutions I've found all involve deleting and recreating the partition and I'm just a bit ... i guess scared by that.
I think parted allows to resize partitions, does it not?
If I break that system I won't have working internet or email at home until i reinstall it, and my wife's totally hooked on this series on netflix right now...
That's what backups are for :)
I'm just thinking "what if the block addressing scheme in the partition table has been changed in the meantime", the partition table is over 7 years old...
It hasn't.
Cheers Mathias
Op dinsdag 7 juli 2020 08:51:00 CEST schreef Mathias Homann:
Hi,
(this is on 15.2)
today's kernel update barfed on me, "package kernel-xxxx needs YY MB on /boot". I managed to install the update by manually moving the old kernel images to /tmp, installing the update rpm, and then moving them back, but for obvious reasons I don't want to have to do that with every kernel update, so here's the plea for inspiration:
how can I resize /dev/sda1 and the filesystem on it, without loosing anythign on my system?
I use gparted to move and enlarge partitions with data. I do this when putting an image on a SD card and I want to change the layout of the partitions on the card to change. However these partitions must not be mounted. So maybe you can use a Leap 15.2 system on an USB stick to boot. You can experiment with gparted and a system on a USB stick or SD card.
I am not familiar with LV's. Assuming the size of sda2 can be shrunken, you can do that first; you need some free space at the end. I am not sure you can do that with gparted. So you may need to copy the content of sda2 to a backup. Then you can create a sda2 till the end of the disk, leaving a gap between sda1 and sda2 and populate sda2 with the saved data. This can take quite some time, because all data needs to be moved (maybe twice). After that extending sda1 with the size of the gap is easy.
When you need to delete a partition and create a new one it gets a new UUID, so GRUB on the boot partition, which normally uses UUIDs can't find the new created sda2. However you can also use a label to search for partitions. So when grub uses a label to mount the root partition, where /etc/fstab is located it will find that partition. But also /etc/fstab needs a LABEL to mount the newly created partition.
Mathias Homann composed on 2020-07-07 02:51 (UTC-0400):
(this is on 15.2)
today's kernel update barfed on me, "package kernel-xxxx needs YY MB on /boot". I managed to install the update by manually moving the old kernel images to /tmp, installing the update rpm, and then moving them back, but for obvious reasons I don't want to have to do that with every kernel update, so here's the plea for inspiration:
how can I resize /dev/sda1 and the filesystem on it, without loosing anythign on my system?
The situation:
/dev/sda[abcd] exist. /dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
Surely you cannot need all the kernels that must be installed to exhaust all the space on a 150MB /boot filesystem. How many are there? 2 should be enough.
I just added 5.3.18-lp152-20.7-default to a 15.2 system, which consumed ~39MB on /boot. 9 kernels live in this /boot. Total space consumed by /boot is 1.0GiB.
On 07/07/2020 06:18, Felix Miata wrote:
Mathias Homann composed on 2020-07-07 02:51 (UTC-0400):
(this is on 15.2)
today's kernel update barfed on me, "package kernel-xxxx needs YY MB on /boot". I managed to install the update by manually moving the old kernel images to /tmp, installing the update rpm, and then moving them back, but for obvious reasons I don't want to have to do that with every kernel update, so here's the plea for inspiration:
how can I resize /dev/sda1 and the filesystem on it, without loosing anythign on my system?
The situation:
/dev/sda[abcd] exist. /dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
Surely you cannot need all the kernels that must be installed to exhaust all the space on a 150MB /boot filesystem. How many are there? 2 should be enough.
I just added 5.3.18-lp152-20.7-default to a 15.2 system, which consumed ~39MB on /boot. 9 kernels live in this /boot. Total space consumed by /boot is 1.0GiB.
Oh really? # ls -l /boot/vmlinuz* lrwxrwxrwx 1 root root 32 Jul 6 11:22 /boot/vmlinuz -> vmlinuz-5.7.7-1.gcba119b-default -rw-r--r-- 1 root root 10279648 Jun 13 05:56 /boot/vmlinuz-5.7.2-2.g7721ea3-default -rw-r--r-- 1 root root 10279680 Jun 15 02:14 /boot/vmlinuz-5.7.2-3.ga96d63c-default -rw-r--r-- 1 root root 10279840 Jun 17 05:55 /boot/vmlinuz-5.7.2-4.gfb5dacf-default -rw-r--r-- 1 root root 10283520 Jun 18 03:30 /boot/vmlinuz-5.7.3-1.g44c4af0-default -rw-r--r-- 1 root root 10283040 Jun 21 05:15 /boot/vmlinuz-5.7.4-1.g23bad63-default -rw-r--r-- 1 root root 10283296 Jun 23 05:43 /boot/vmlinuz-5.7.4-2.g23bad63-default -rw-r--r-- 1 root root 10285856 Jun 24 04:44 /boot/vmlinuz-5.7.5-2.gf3d2ea3-default -rw-r--r-- 1 root root 10285856 Jun 26 05:06 /boot/vmlinuz-5.7.5-3.gf3d2ea3-default -rw-r--r-- 1 root root 10287520 Jun 26 09:15 /boot/vmlinuz-5.7.6-2.g1549350-default -rw-r--r-- 1 root root 10288640 Jul 2 03:27 /boot/vmlinuz-5.7.7-1.gcba119b-default
# df -h /boot / Filesystem Size Used Avail Use% Mounted on /dev/sda1 1.9G 400M 1.4G 23% /boot /dev/mapper/vgmain-vROOT4 40G 6.7G 32G 18% /
# blkid /dev/sda1 /dev/mapper/vgmain-vROOT4 /dev/sda1: LABEL="BOOT" UUID="fe7be533-fb41-421d-9216-29c9701ec01c" TYPE="ext2" PTTYPE="dos" PARTLABEL="primary" PARTUUID="cebb3ec5-8cfe-4272-954e-04552ca5305c" /dev/mapper/vgmain-vROOT4: LABEL="ROOT4" UUID="c7fbbfa9-50d8-4d31-add8-7a53c57ca098" TYPE="ext4"
Anton Aylward composed on 2020-07-07 09:36 (UTC-0400):
Felix Miata wrote:
Surely you cannot need all the kernels that must be installed to exhaust all the
^^^^^^^^
space on a 150MB /boot filesystem. How many are there? 2 should be enough.
I just added 5.3.18-lp152-20.7-default to a 15.2 system, which consumed ~39MB on /boot. 9 kernels live in this /boot. Total space consumed by /boot is 1.0GiB.
Oh really?
He's using 15.2...
# ls -l /boot/vmlinuz* lrwxrwxrwx 1 root root 32 Jul 6 11:22 /boot/vmlinuz -> vmlinuz-5.7.7-1.gcba119b-default -rw-r--r-- 1 root root 10279648 Jun 13 05:56 /boot/vmlinuz-5.7.2-2.g7721ea3-default -rw-r--r-- 1 root root 10279680 Jun 15 02:14 /boot/vmlinuz-5.7.2-3.ga96d63c-default -rw-r--r-- 1 root root 10279840 Jun 17 05:55 /boot/vmlinuz-5.7.2-4.gfb5dacf-default -rw-r--r-- 1 root root 10283520 Jun 18 03:30 /boot/vmlinuz-5.7.3-1.g44c4af0-default -rw-r--r-- 1 root root 10283040 Jun 21 05:15 /boot/vmlinuz-5.7.4-1.g23bad63-default -rw-r--r-- 1 root root 10283296 Jun 23 05:43 /boot/vmlinuz-5.7.4-2.g23bad63-default -rw-r--r-- 1 root root 10285856 Jun 24 04:44 /boot/vmlinuz-5.7.5-2.gf3d2ea3-default -rw-r--r-- 1 root root 10285856 Jun 26 05:06 /boot/vmlinuz-5.7.5-3.gf3d2ea3-default -rw-r--r-- 1 root root 10287520 Jun 26 09:15 /boot/vmlinuz-5.7.6-2.g1549350-default -rw-r--r-- 1 root root 10288640 Jul 2 03:27 /boot/vmlinuz-5.7.7-1.gcba119b-default
# df -h /boot / Filesystem Size Used Avail Use% Mounted on /dev/sda1 1.9G 400M 1.4G 23% /boot /dev/mapper/vgmain-vROOT4 40G 6.7G 32G 18% /
...so not likely in need of a new kernel every other day, or keeping many.
# du -sh /boot 129M /boot # ls -Gg /boot/vml*5.3.1* /boot/vml*4.1* -rw-r--r-- 1 8329395 Oct 9 2019 /boot/vmlinux-4.12.14-lp151.28.20-default.gz -rw-r--r-- 1 13880017 May 26 16:31 /boot/vmlinux-5.3.18-lp152.16-default.gz -rw-r--r-- 1 13879463 Jun 12 09:01 /boot/vmlinux-5.3.18-lp152.19-default.gz -rw-r--r-- 1 7311472 Oct 9 2019 /boot/vmlinuz-4.12.14-lp151.28.20-default -rw-r--r-- 1 9036016 May 26 17:12 /boot/vmlinuz-5.3.18-lp152.16-default -rw-r--r-- 1 9031920 Jun 12 09:36 /boot/vmlinuz-5.3.18-lp152.19-default # inxi -SI System: Host: p5bse Kernel: 5.3.18-lp152.19-default x86_64 bits: 64 Console: tty 3 Distro: openSUSE Leap 15.2 Info: Processes: 126 Uptime: N/A Memory: 1.93 GiB used: 129.0 MiB (6.5%) Init: systemd runlevel: 3 Shell: Bash inxi: 3.1.04
OTOH, kernels sure have bloated over the years: -rw-rw-r-- 1 18570712 Nov 7 2008 102/kernel-default-2.6.18.8-0.13.x86_64.rpm -rw-rw-r-- 1 37024090 Feb 23 2011 114/kernel-desktop-2.6.37.1-1.2.2.x86_64.rpm -rw-rw-r-- 1 29111834 Feb 18 2014 114/kernel-desktop-3.0.101-79.1.x86_64.rpm -rw-rw-r-- 1 38123156 Nov 5 2011 121/kernel-desktop-3.1.0-1.2.1.x86_64.rpm -rw-rw-r-- 1 40292045 Aug 4 2012 122/kernel-desktop-3.4.6-2.10.1.x86_64.rpm -rw-rw-r-- 1 41542619 Dec 19 2014 123/kernel-desktop-3.7.10-1.45.1.x86_64.rpm -rw-rw-r-- 1 42695221 Nov 1 2013 131/kernel-desktop-3.11.6-4.1.x86_64.rpm -rw-rw-r-- 1 44870977 Dec 13 2016 131/kernel-default-3.12.67-64.1.x86_64.rpm -rw-rw-r-- 1 48450181 Dec 8 2016 132/kernel-desktop-3.16.7-53.1.x86_64.rpm -rw-rw-r-- 1 45820742 Oct 29 2015 421/kernel-default-4.1.12-1.1.x86_64.rpm -rw-rw-r-- 1 56322448 Jun 18 2019 423/kernel-default-4.4.180-102.1.x86_64.rpm -rw-rw-r-- 1 58886019 May 3 2017 Factory/kernel-default-4.10.13-1.2.x86_64.rpm -rw-rw-r-- 1 58571199 Aug 13 2017 Factory/kernel-default-4.11.8-2.4.x86_64.rpm -rw-rw-r-- 1 64982767 Aug 30 2017 Factory/kernel-default-4.12.9-1.2.x86_64.rpm -rw-rw-r-- 1 61707560 Nov 14 2019 150/kernel-default-4.12.14-lp150.12.82.1.x86_64.rpm -rw-rw-r-- 1 65583028 Jun 12 11:17 151/kernel-default-4.12.14-lp151.28.52.1.x86_64.rpm -rw-rw-r-- 1 61065066 Nov 12 2017 Factory/kernel-default-4.13.12-1.1.x86_64.rpm -rw-rw-r-- 1 62547184 Jan 31 2018 Factory/kernel-default-4.14.15-2.3.x86_64.rpm -rw-rw-r-- 1 64949060 Apr 4 2018 Factory/kernel-default-4.15.13-2.4.x86_64.rpm -rw-rw-r-- 1 66152028 Jun 13 2018 Factory/kernel-default-4.16.12-3.5.x86_64.rpm -rw-rw-r-- 1 66781264 Aug 13 2018 Factory/kernel-default-4.17.14-1.2.x86_64.rpm -rw-rw-r-- 1 66510600 Oct 24 2018 Factory/kernel-default-4.18.15-1.2.x86_64.rpm -rw-rw-r-- 1 67377492 Dec 28 2018 Factory/kernel-default-4.19.12-1.4.x86_64.rpm -rw-rw-r-- 1 67350588 Mar 4 2019 Factory/kernel-default-4.20.13-1.2.x86_64.rpm -rw-rw-r-- 1 67262744 May 10 2019 Factory/kernel-default-5.0.13-1.1.x86_64.rpm -rw-rw-r-- 1 68560788 Jul 16 2019 Factory/kernel-default-5.1.16-1.4.x86_64.rpm -rw-rw-r-- 1 70516856 Sep 21 2019 Factory/kernel-default-5.2.14-1.2.x86_64.rpm -rw-rw-r-- 1 73730132 Jul 6 18:31 152/kernel-default-5.3.18-lp152.20.7.1.x86_64.rpm -rw-rw-r-- 1 81933836 Dec 19 2019 Factory/kernel-default-5.3.12-2.2.x86_64.rpm -rw-rw-r-- 1 79660308 Feb 2 11:42 Factory/kernel-default-5.4.14-2.1.x86_64.rpm -rw-rw-r-- 1 80761600 Mar 29 11:43 Factory/kernel-default-5.5.13-1.2.x86_64.rpm -rw-rw-r-- 1 82639300 Jun 8 22:50 Factory/kernel-default-5.6.14-1.6.x86_64.rpm -rw-rw-r-- 1 85104448 Jun 27 21:16 Factory/kernel-default-5.7.5-1.2.x86_64.rpm
On 07/07/2020 12.18, Felix Miata wrote:
Mathias Homann composed on 2020-07-07 02:51 (UTC-0400):
(this is on 15.2)
...
The situation:
/dev/sda[abcd] exist. /dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
Surely you cannot need all the kernels that must be installed to exhaust all the space on a 150MB /boot filesystem. How many are there? 2 should be enough.
But for an instant, during an update, there are three.
Am Dienstag, 7. Juli 2020, 19:28:24 CEST schrieb Carlos E. R.:
On 07/07/2020 12.18, Felix Miata wrote:
Mathias Homann composed on 2020-07-07 02:51 (UTC-0400):
(this is on 15.2)
...
The situation:
/dev/sda[abcd] exist. /dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
Surely you cannot need all the kernels that must be installed to exhaust all the space on a 150MB /boot filesystem. How many are there? 2 should be enough.
But for an instant, during an update, there are three.
and for that 150MB was not enough, which broke updates for me, hence the whole thread ;)
Cheers MH
On 07/07/2020 13:28, Carlos E. R. wrote:
On 07/07/2020 12.18, Felix Miata wrote:
Mathias Homann composed on 2020-07-07 02:51 (UTC-0400):
(this is on 15.2)
...
The situation:
/dev/sda[abcd] exist. /dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
Surely you cannot need all the kernels that must be installed to exhaust all the space on a 150MB /boot filesystem. How many are there? 2 should be enough.
But for an instant, during an update, there are three.
Well, maybe.
You'll notice that there is also a flag file, /boot/do_purge_kernels created that is used the the "purge_kernels" process, which happens on the next boot thanks to a unit file to that end. /usr/lib/systemd/system/purge-kernels.service ============ [Unit] Description=Purge old kernels After=local-fs.target ConditionPathExists=/boot/do_purge_kernels ConditionPathIsReadWrite=/
[Service] Type=oneshot Nice=19 IOSchedulingClass=idle ExecStartPre=/bin/rm -f /boot/do_purge_kernels ExecStart=/sbin/purge-kernels
[Install] WantedBy=multi-user.target
============
Or you could run it manually.
There are two left behind because that is the setting in your /etc/zypp/zypp.conf
Mine reads
multiversion = provides:multiversion(kernel)
## Comma separated list of kernel packages to keep installed in parallel, if the ## above multiversion variable is set. Packages can be specified as ## 2.6.32.12-0.7 - Exact version to keep ## latest - Keep kernel with the highest version number ## latest-N - Keep kernel with the Nth highest version number ## running - Keep the running kernel ## oldest - Keep kernel with the lowest version number (the GA kernel) ## oldest+N - Keep kernel with the Nth lowest version number ## ## Note: This entry is not evaluated by libzypp, but by the ## purge-kernels service (via /sbin/purge-kernels). ## ## Default: Do not delete any kernels if multiversion = provides:multiversion(kernel) is set multiversion.kernels = latest,latest-4,latest-3,latest-2,latest-1,running
On 07/07/2020 19.57, Anton Aylward wrote:
On 07/07/2020 13:28, Carlos E. R. wrote:
On 07/07/2020 12.18, Felix Miata wrote:
Mathias Homann composed on 2020-07-07 02:51 (UTC-0400):
(this is on 15.2)
...
The situation:
/dev/sda[abcd] exist. /dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
Surely you cannot need all the kernels that must be installed to exhaust all the space on a 150MB /boot filesystem. How many are there? 2 should be enough.
But for an instant, during an update, there are three.
Well, maybe.
I know there are three for an instant :-D
You have two. You run an update, you get three. Then you boot, and the purge-kernel process you mention removes one.
He is not the first person to be bitten by a too small /boot. Mine has 1 gig (75 megs used). Should last for a decade :-p
On Tue, 7 Jul 2020 20:02:11 +0200 "Carlos E.R." robin.listas@gmx.es wrote:
On 07/07/2020 19.57, Anton Aylward wrote:
On 07/07/2020 13:28, Carlos E. R. wrote:
On 07/07/2020 12.18, Felix Miata wrote:
Mathias Homann composed on 2020-07-07 02:51 (UTC-0400):
(this is on 15.2)
...
The situation:
/dev/sda[abcd] exist. /dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
Surely you cannot need all the kernels that must be installed to exhaust all the space on a 150MB /boot filesystem. How many are there? 2 should be enough.
But for an instant, during an update, there are three.
Well, maybe.
I know there are three for an instant :-D
You have two. You run an update, you get three. Then you boot, and the purge-kernel process you mention removes one.
He is not the first person to be bitten by a too small /boot. Mine has 1 gig (75 megs used). Should last for a decade :-p
Why does anybody have /boot in a spearate partition these days? MY kernels and initrds are on the root filesystem, where the installer put them.
On 08/07/2020 14.08, Dave Howorth wrote:
On Tue, 7 Jul 2020 20:02:11 +0200 "Carlos E.R." <> wrote:
On 07/07/2020 19.57, Anton Aylward wrote:
On 07/07/2020 13:28, Carlos E. R. wrote:
On 07/07/2020 12.18, Felix Miata wrote:
Mathias Homann composed on 2020-07-07 02:51 (UTC-0400):
(this is on 15.2)
...
The situation:
/dev/sda[abcd] exist. /dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
Surely you cannot need all the kernels that must be installed to exhaust all the space on a 150MB /boot filesystem. How many are there? 2 should be enough.
But for an instant, during an update, there are three.
Well, maybe.
I know there are three for an instant :-D
You have two. You run an update, you get three. Then you boot, and the purge-kernel process you mention removes one.
He is not the first person to be bitten by a too small /boot. Mine has 1 gig (75 megs used). Should last for a decade :-p
Why does anybody have /boot in a spearate partition these days? MY kernels and initrds are on the root filesystem, where the installer put them.
Me, tradition :-)
But there are combinations that, AFAIK, still need a separate /boot. LVM, some RAIDs...
Dave Howorth wrote:
Why does anybody have /boot in a spearate partition these days? MY kernels and initrds are on the root filesystem, where the installer put them.
Ditto - haven't had /boot on a separate partition since the it had to be within the first 1024cylinders. I'm guessing maybe you need it if your root is on btrfs or some such?
On 08/07/2020 14.24, Per Jessen wrote:
Dave Howorth wrote:
Why does anybody have /boot in a spearate partition these days? MY kernels and initrds are on the root filesystem, where the installer put them.
Ditto - haven't had /boot on a separate partition since the it had to be within the first 1024cylinders. I'm guessing maybe you need it if your root is on btrfs or some such?
No, for btrfs it is much better to have everything except home in the same partition, or you lose the possibility of rebooting to a previous snapshot.
However, maybe we still need a separate /boot for xfs.
On 2020-07-08 08:08 AM, Dave Howorth wrote:
Why does anybody have /boot in a spearate partition these days? MY kernels and initrds are on the root filesystem, where the installer put them.
I don't know about now, but at one time /boot couldn't be in a RAID array, at least not with software RAID.
James Knott wrote:
On 2020-07-08 08:08 AM, Dave Howorth wrote:
Why does anybody have /boot in a spearate partition these days? MY kernels and initrds are on the root filesystem, where the installer put them.
I don't know about now, but at one time /boot couldn't be in a RAID array, at least not with software RAID.
I think RAID5 might still be out, but I have a cluster of servers in an external datacentre, all booting off RAID1. (essentially just two boot-devices).
On 07/07/2020 08.51, Mathias Homann wrote:
Hi,
(this is on 15.2)
today's kernel update barfed on me, "package kernel-xxxx needs YY MB on /boot". I managed to install the update by manually moving the old kernel images to /tmp, installing the update rpm, and then moving them back, but for obvious reasons I don't want to have to do that with every kernel update, so here's the plea for inspiration:
how can I resize /dev/sda1 and the filesystem on it, without loosing anythign on my system?
The situation:
/dev/sda[abcd] exist. /dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
What is "bog"? :-?
/dev/sda2 covers the rest of the disk, and is a PV for LVM /dev/sd[bcd]1 all exist, span their whole disks, and are PVs in the same VG as /dev/sda2
I have enough room to do a pvmove from /dev/sda2 to anywhere else if i resize a few of the volumes in my VG, so getting to the point where /dev/sda1 is all that's left on /dev/sda should be easy enough, but I've never resized a normal partition - learned about LVM too early in my career ;)
How do I resize a normal partition and the filesystem on it? Like I already said, filesystem is ext4.
Different idea: uninstall plymouth. That reduces the size of each initrd by several megabytes, maybe 15 or 20. That might give you some years extra :-D
You could also reformat sda1 as ext2. No journal saves some space, and you really do not need a journal on such a small filesystem.
Or, try format as ext4 without journal (it is what I do on USB sticks):
mke2fs -t ext4 -O ^has_journal /dev/sda1
but I think it is better as ext2. All my /boot partitions are ext2.
On 07/07/2020 06:31, Carlos E. R. wrote:
/dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
What is "bog"? :-?
Context is Everything.
Never mind what 'bog' might mean, the use here is "bog-standard" which means 'vanilla' or 'off the shelf' or 'normal' or 'as sold & delivered.
Am Dienstag, 7. Juli 2020, 16:31:55 CEST schrieb Anton Aylward:
On 07/07/2020 06:31, Carlos E. R. wrote:
/dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
What is "bog"? :-?
Context is Everything.
Never mind what 'bog' might mean, the use here is "bog-standard" which means 'vanilla' or 'off the shelf' or 'normal' or 'as sold & delivered.
personally I use "bug-" as "so normal that it is actually quite boring" :)
Cheers M
On 07/07/2020 16.31, Anton Aylward wrote:
On 07/07/2020 06:31, Carlos E. R. wrote:
/dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
What is "bog"? :-?
Context is Everything.
Never mind what 'bog' might mean, the use here is "bog-standard" which means 'vanilla' or 'off the shelf' or 'normal' or 'as sold & delivered.
I get that, but I still want to know what bog is :-) Dictionary says "swamp".
On 07/07/2020 13:26, Carlos E. R. wrote:
On 07/07/2020 16.31, Anton Aylward wrote:
On 07/07/2020 06:31, Carlos E. R. wrote:
/dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
What is "bog"? :-?
Context is Everything.
Never mind what 'bog' might mean, the use here is "bog-standard" which means 'vanilla' or 'off the shelf' or 'normal' or 'as sold & delivered.
I get that, but I still want to know what bog is :-) Dictionary says "swamp".
Indeed. Getting bogged down is akin to getting swamped over.
Am Dienstag, 7. Juli 2020, 19:26:10 CEST schrieb Carlos E. R.:
On 07/07/2020 16.31, Anton Aylward wrote:
On 07/07/2020 06:31, Carlos E. R. wrote:
/dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
What is "bog"? :-?
Context is Everything.
Never mind what 'bog' might mean, the use here is "bog-standard" which means 'vanilla' or 'off the shelf' or 'normal' or 'as sold & delivered.
I get that, but I still want to know what bog is :-) Dictionary says "swamp".
Actually, "bog-standard" is not just some idiom, at least its in the cambridge dictionary: https://dictionary.cambridge.org/de/worterbuch/englisch/bog-standard
this one's nice too:
https://en.wiktionary.org/wiki/bog-standard "from the unattested acronym BOG, allegedly short for British or German, referring to the supposed dominance of British and German engineering during Victorian times."
XD Mathias
On 07/07/2020 19.59, Mathias Homann wrote:
Am Dienstag, 7. Juli 2020, 19:26:10 CEST schrieb Carlos E. R.:
On 07/07/2020 16.31, Anton Aylward wrote:
On 07/07/2020 06:31, Carlos E. R. wrote:
/dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
What is "bog"? :-?
Context is Everything.
Never mind what 'bog' might mean, the use here is "bog-standard" which means 'vanilla' or 'off the shelf' or 'normal' or 'as sold & delivered.
I get that, but I still want to know what bog is :-) Dictionary says "swamp".
Actually, "bog-standard" is not just some idiom, at least its in the cambridge dictionary: https://dictionary.cambridge.org/de/worterbuch/englisch/bog-standard
this one's nice too:
https://en.wiktionary.org/wiki/bog-standard "from the unattested acronym BOG, allegedly short for British or German, referring to the supposed dominance of British and German engineering during Victorian times."
Thanks! That's a good one :-D
On Tue, 07 Jul 2020 19:59:20 +0200 Mathias Homann Mathias.Homann@opensuse.org wrote:
Am Dienstag, 7. Juli 2020, 19:26:10 CEST schrieb Carlos E. R.:
On 07/07/2020 16.31, Anton Aylward wrote:
On 07/07/2020 06:31, Carlos E. R. wrote:
/dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
What is "bog"? :-?
Context is Everything.
Never mind what 'bog' might mean, the use here is "bog-standard" which means 'vanilla' or 'off the shelf' or 'normal' or 'as sold & delivered.
I get that, but I still want to know what bog is :-) Dictionary says "swamp".
Actually, "bog-standard" is not just some idiom, at least its in the cambridge dictionary: https://dictionary.cambridge.org/de/worterbuch/englisch/bog-standard
this one's nice too:
https://en.wiktionary.org/wiki/bog-standard "from the unattested acronym BOG, allegedly short for British or German, referring to the supposed dominance of British and German engineering during Victorian times."
Hmm, see also http://www.worldwidewords.org/qa/qa-bog1.htm
But ... I've never heard the expression box-standard before, while I've been familiar with bog-standard as long as I can remember. Never really though about its etymology before.
XD Mathias
Carlos E. R. wrote:
On 07/07/2020 16.31, Anton Aylward wrote:
On 07/07/2020 06:31, Carlos E. R. wrote:
/dev/sda1 is a bog-standard ext4, 150MB, mounted on /boot
What is "bog"? :-?
Context is Everything.
Never mind what 'bog' might mean, the use here is "bog-standard" which means 'vanilla' or 'off the shelf' or 'normal' or 'as sold & delivered.
I get that, but I still want to know what bog is :-) Dictionary says "swamp".
Correct. It is also slang / colloquial for 'toilet'.
-
Anton Aylward -
Carlos E. R. -
Carlos E.R. -
Dave Howorth -
Felix Miata -
Freek de Kruijf -
James Knott -
Mathias Homann -
Mathias Homann
-
Per Jessen