From: Doug@hyperspace.vogon.gov   
      
   Carlos E.R. wrote:   
   > On 2022-09-16 22:52, Andrew wrote:   
   >> Carlos E.R. wrote:   
   >>> On 2022-08-21 22:11, Andrew wrote:   
   >>>> Carlos E.R. wrote:   
   >>>>> On 2022-08-20 20:47, Andrew wrote:   
   >>>>>> Carlos E.R. wrote:   
   >>>>>>> On 2022-08-12 20:02, Andrew wrote:   
   >>>>>>>> The older system has another problem anyway, my /boot partition   
   >>>>>>>> is over 500MB and has around 50% free with the current kernel   
   >>>>>>>> and the -1 kernel.   This is insufficient when it comes to   
   >>>>>>>> installing a new kernel and I'm going to have to start getting   
   >>>>>>>> rid of the -1 kernel before installing the new one.  The beast   
   >>>>>>>> is dual-boot with Windows 10 and I am not prepared to risk   
   >>>>>>>> moving the main Windows partion which is just behind /boot.   
   >>>>>>>   
   >>>>>>> Try instead uninstalling "plymouth" (and then run mkinitrd).   
   >>>>>>>   
   >>>>>>> This package does the graphic display during boot, and it makes   
   >>>>>>> the kernel image much larger.   
   >>>>>>>   
   >>>>>>> 500 M should be enough.   
   >>>>>>>   
   >>>>>>> Telcontar:~ # df -h | grep boot   
   >>>>>>> /dev/nvme0n1p4        1011M   98M  862M  11% /boot   
   >>>>>>> /dev/nvme0n1p1         500M   19M  482M   4% /boot/efi   
   >>>>>>> Telcontar:~ #   
   >>>>>>>   
   >>>>>>>   
   >>>>>>   
   >>>>>> Thanks, that particular machine is a test system so I tried it.   
   >>>>>> It still boots with no problems but I won't see if it really   
   >>>>>> helped until the next kernel comes along.   
   >>>>>> It's my only pre-UEFI system and has been running since 2010,   
   >>>>>> which is why the /boot is sized the way it is.   
   >>>>>   
   >>>>>   
   >>>>> You can simply do:   
   >>>>>   
   >>>>> df -h /boot   
   >>>>>   
   >>>>> before and after removing the package, to see the effect it has.   
   >>>>>   
   >>>>> This is the file that changes:   
   >>>>>   
   >>>>> cer@Telcontar:~> ls -lh /boot/initrd*   
   >>>>>   
   >>>>> ... 13M Aug  8 14:45 /boot/initrd-5.3.18-150300.59.63-default   
   >>>>> ... 13M Aug  8 14:45 /boot/initrd-5.3.18-150300.59.87-default   
   >>>>>   
   >>>>>   
   >>>>   
   >>>> Oh, I did that immediately.  The file was slightly smaller and the   
   >>>> partition dropped to 48% used.   
   >>>   
   >>> Oh. I expected a significant difference. When I tested this was long   
   >>> ago, though, so I suppose that now they are including so many things   
   >>> in the initrd that it no longer makes an impact.   
   >>>   
   >>>> Given that the previous 50% was with two kernels, an additional one   
   >>>> should still only be 75% before reverting to 50% once the oldest one   
   >>>> had been removed, I don't see any alternative to waiting for a new   
   >>>> kernel update.   
   >>>> The -1 kernel still has the Plymouth stuff in there so the next   
   >>>> update may fail until I remove it, and the following one could then   
   >>>> still be ok.  Calculations will not help.   
   >>>   
   >>> Er... no, when you remove the package all the initrds are remade   
   >>> without it. All kernels. Look at the dates of the files (see mine   
   >>> above, same timestamp).   
   >>>   
   >>   
   >> I suppose I could have said "you are right" (with the reduced size)   
   >> but I was waiting for a new kernel to come along.  It has.   
   >>   
   >> 240 MB - Total size of /boot   
   >> 107 MB - Used (with two kernels)   
   >> 117 MB - Free   
   >> This means 48% of /boot is in use.   
   >> zypper still said it needed another 10 MB to install the new kernel.   
   >> Abort, retry, ignore? [a/r/i] (a):   
   >>   
   >> The adventurous solution would have been to have tried "i" as in "do   
   >> it anyway".  I copped out, removed the older kernel with Yast ->   
   >> Software Management (at which point 50-60 MB was in use) and then   
   >> installed the new one using zypper.  The 240 / 107 / 117 / 48% figures   
   >> still hold true.   
   >> I'm assuming zypper's calculation of how much it needs is at fault,   
   >> the additional kernel should have meant 160 MB was in use.  zypper's   
   >> guesstimate of 127 MB for a new kernel seems ridiculous, unless there   
   >> is some compression going on there during the update process.   
   >> There are vmlinux-whatever.gz files in there which take 17-18 MB each,   
   >> if one takes 80 MB before compression that would explain a lot.   
   >   
   >   
   > When this happened to me I tried to find 10 meg I could move temporarily   
   > to another partition. 240 megs is now too small. Mine is a gigabyte   
   > (103M in use), of course after I changed the disk and reformatted.   
   >   
      
   This machine is ancient and is dual boot with Windows 10 (originally   
   Windows 7), I'll have to live with the pain.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)