upgrade failure from Leap 15.1 with disk space warning on /boot

[BerndSpeiser]

Here are the results of two tests to decrease the size of the /boot contents:

1. moved out the g-zipped symvers and vmlinux - the usage of /boot goes back to 24%; upgrade to 15.2 still fails with an estimated usage of /boot of 116%
2. in addition: dracut --hostonly --force - this results in only a marginal decrease of initrd from 1.417 to 1.416 MB, so I didn't even try to attempt the upgrade with that

So, in conclusion up to this point: there seem to be no easy way to solve this problem and increasing the size of the /boot partition on my system would be the path to go.

Thus, I would like to come back to mrmazda's suggestion to do this as

You should be able to shrink the sda2 lvm at its front, backup the content of sda1, delete and recreate sda1 at a larger size, then restore sda1 content, with plenty of room on /boot/ resulting.

Can you give me some additional advice on that? Maybe some of the following questions are somehow obvious to the expert, but I would like to learn about disk modification in this process.

From what I read, I would probably have to do this from a live CD or USB stick to have the partitions on the hard disk unmounted for such a process. Right?
Which tool would you recommend? I read about gparted, but could the Yast partitioner be used as well?
How would I shrink sda2 at its front (which probably means at the border between sda1 and sda2)? I seem to find information how to shrink at the end, but then I would have to move the contents of the file system somehow to the end of the partition. Is that the idea?
I am not sure, why sda1 needs to be deleted/recreated and consequently its content needs to be "restored" - is there no way to enlarge the file system in sda1 once there is enough free space at the right place?
Once there is "free space" at the front of sda2, this could be used to enlarge the size of sda1 by "recreating". If I would want to take the "free space" from sda3 rather than from sda2, would I need to do this precedure twice, i.a. shrink sda3, "move" sda2 and then enlarge sda1?

[BerndSpeiser]

edit:

the numbers in item 2 of the following list

1. moved out the g-zipped symvers and vmlinux - the usage of /boot goes back to 24%; upgrade to 15.2 still fails with an estimated usage of /boot of 116%
2. in addition: dracut --hostonly --force - this results in only a marginal decrease of initrd from 1.417 to 1.416 MB, so I didn't even try to attempt the upgrade with that

are incorrect (misplacement of decimal point), they should be 14.17 and 14.16 MB. This does of course not alter the conclusion given in my last post.

[OrsoBruno]

From what I read, I would probably have to do this from a live CD or USB stick to have the partitions on the hard disk unmounted for such a process. Right?

Right, if you are going to change the partition mounted at / (root). You may unmount and work on the /boot partition though, but any mistake might leave you with an unbootable system.

Which tool would you recommend? I read about gparted, but could the Yast partitioner be used as well?

GParted Live is a good option. The YaST partitioner seems to be safer in a sense, but that likely means that it won't allow you to do what you are planning to do here...

How would I shrink sda2 at its front (which probably means at the border between sda1 and sda2)? I seem to find information how to shrink at the end, but then I would have to move the contents of the file system somehow to the end of the partition. Is that the idea?[I am not sure, why sda1 needs to be deleted/recreated and consequently its content needs to be "restored" - is there no way to enlarge the file system in sda1 once there is enough free space at the right place?

Don't assume that sda1 is _just in front_ of sda2 or that sda3 follows sda2 in disk order: that depends on the history of that disk since its first formatting. To say something about that we need to see the result of:

gdisk -l /dev/sda

If partitions are really in disk order, likely you will be able to shrink sda2 at the front with GParted, then grow sda1 and finally grow the filesystem on sda1 to fill all available space.
I'm not sure if lvm has additional constraints, anyway with GParted you can plan the sequence of changes _before_ actually committing to disk, so anything illegal should pop up as error.

Once there is "free space" at the front of sda2, this could be used to enlarge the size of sda1 by "recreating". If I would want to take the "free space" from sda3 rather than from sda2, would I need to do this precedure twice, i.a. shrink sda3, "move" sda2 and then enlarge sda1?

Yes, I think so, but again GParted allows you to plan the sequence and then commit to disk once you are satisfied with your plan.

[BerndSpeiser]

Don't assume that sda1 is _just in front_ of sda2 or that sda3 follows sda2 in disk order: that depends on the history of that disk since its first formatting. To say something about that we need to see the result of:

gdisk -l /dev/sda

OK, good to hear about the tools. "sda3" is in fact "sda4" on this disk.

Here is the output of gdisk:

> sudo gdisk -l /dev/sda
[sudo] password for root:
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************

Disk /dev/sda: 312581808 sectors, 149.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 5F983376-61E2-4F57-A4BE-511BB0A72517
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 312581774
Partitions will be aligned on 1-sector boundaries
Total free space is 9007 sectors (4.4 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          321535   156.0 MiB   8300  Linux filesystem
   2          321536        46313471   21.9 GiB    8E00  Linux LVM
   4        46315395       312576704   127.0 GiB   8E00  Linux LVM

Looks to me that the partitions are in order sda1, sda2, sda4, with sda1 and sda2 directly adjacent, while there is a gap between sda2 and sda4 with respect to sectors. Also, at the end, some sectors seem to be not in use.

Same result with respect to sector counts from fdisk -l:

Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Disk model: WDC WD1600BEVT-2
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000c12a9

Device     Boot    Start       End   Sectors  Size Id Type
/dev/sda1  *        2048    321535    319488  156M 83 Linux
/dev/sda2         321536  46313471  45991936   22G 8e Linux LVM
/dev/sda4       46315395 312576704 266261310  127G 8e Linux LVM




Disk /dev/mapper/cr_ata-WDC_WD1600BEVT-22ZCT0_WD-WXE708N10973-part2: 22 GiB, 23545774080 bytes, 45987840 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/system-root: 19.9 GiB, 21395144704 bytes, 41787392 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/system-swap: 2 GiB, 2147483648 bytes, 4194304 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/cr_ata-WDC_WD1600BEVT-22ZCT0_WD-WXE708N10973-part4: 127 GiB, 136323693568 bytes, 266257214 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/system-home: 127 GiB, 136319074304 bytes, 266248192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

So, would that be a "go" for trying out GParted Live and look how far I can get? Or do you see any particular problems to expect?

[OrsoBruno]

So, would that be a "go" for trying out GParted Live and look how far I can get? Or do you see any particular problems to expect?

I would try GParted Live and plan on:

-shrinking sda4 and possibly moving to the end of the disk;
-moving sda2 towards the end of the disk;
-growing sda1 as needed and enlarge its filesystem to fill all available space;

and see if GParted has something to complain about.
BE CAREFUL: I would not do the following step (actually committing to disk) unless you are absolutely sure of what you are doing and have a known good backup of all important data just in case.
Also please note that I have no experience with moving/resizing logical volumes so don't take my word for it.

[nrickert]

Also please note that I have no experience with moving/resizing logical volumes so don't take my word for it.

It has been a while. When I last wanted to resize an LVM partition:

(1) backup the data;
(2) delete partition, then recreate to the new size;
(3) create the LVM on that partition, and structure into volumes as needed
(4) restore data.

Actually, I only backed up and restored for "/home". I find it easier to do a clean install than to backup and restore for the root volume. And, of course, there isn't much point in backup/restore on a swap volume.

[BerndSpeiser]

sorry, it took some time to finish up repartitioning the hdd in order to have more space for /boot (now 666 MB). Indeed, the upgrade process has now been started successfully.
I used GParted for this purpose, as suggested. For those interested, what had to be done, see the following topic in the GParted forum: http://gparted-forum.surf4.info/view...d=35638#p35638
Thanks for your help in the present forum as well. I guess, this is resolved.

[BerndSpeiser]

For those interested, here is the space used in /boot after upgrade to Leap 15.2 and doing all available updates (so there are now two versions of the 5.3.18 kernel):

>df -H
total 83445
-rw-r--r-- 1 root root      512  4. Aug 2017  backup_mbr
lrwxrwxrwx 1 root root        1  4. Aug 2017  boot -> .
-rw-r--r-- 1 root root     1725  8. Jun 21:25 boot.readme
-rw-r--r-- 1 root root   228172 12. Jun 14:11 config-5.3.18-lp152.19-default
-rw-r--r-- 1 root root   228310 22. Jul 08:44 config-5.3.18-lp152.33-default
drwxr-xr-x 2 root root     1024  4. Aug 2017  grub
drwxr-xr-x 6 root root     1024 31. Jul 13:56 grub2
lrwxrwxrwx 1 root root       30 31. Jul 13:30 initrd -> initrd-5.3.18-lp152.33-default
-rw------- 1 root root 14534728 31. Jul 13:47 initrd-5.3.18-lp152.19-default
-rw------- 1 root root 14537856 31. Jul 13:48 initrd-5.3.18-lp152.33-default
drwx------ 2 root root    12288 12. Feb 2015  lost+found
-rw-r--r-- 1 root root   432065 12. Jun 14:57 symvers-5.3.18-lp152.19-default.gz
-rw-r--r-- 1 root root   432172 22. Jul 08:54 symvers-5.3.18-lp152.33-default.gz
-rw-r--r-- 1 root root      484 12. Jun 14:57 sysctl.conf-5.3.18-lp152.19-default
-rw-r--r-- 1 root root      484 22. Jul 08:54 sysctl.conf-5.3.18-lp152.33-default
-rw-r--r-- 1 root root  4599521 12. Jun 14:53 System.map-5.3.18-lp152.19-default
-rw-r--r-- 1 root root  4601182 22. Jul 08:53 System.map-5.3.18-lp152.33-default
-rw-r--r-- 1 root root 13879463 12. Jun 15:01 vmlinux-5.3.18-lp152.19-default.gz
-rw-r--r-- 1 root root 13879527 22. Jul 08:56 vmlinux-5.3.18-lp152.33-default.gz
lrwxrwxrwx 1 root root       31 31. Jul 13:30 vmlinuz -> vmlinuz-5.3.18-lp152.33-default
-rw-r--r-- 1 root root  9031920 12. Jun 15:36 vmlinuz-5.3.18-lp152.19-default
-rw-r--r-- 1 root root  9036016 22. Jul 09:19 vmlinuz-5.3.18-lp152.33-default

The previous values on Leap 15.1 were reported in post

https://forums.opensuse.org/showthread.php/541873-upgrade-failure-from-Leap-15-1-with-disk-space-warning-on-boot?p=2948029#post2948029

.
Except for vmlinux-5.3.18-lp152.19-default.gz the size increase is rather moderate, and the files should have fit nicely into my previous /boot partition. So, it is not really clear why the Installer of Leap 15.2 had been complaining.

But anyhow, the whole thing was an interesting experience.