home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.linux.suse      Suse is actually not that bad      138,051 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 137,603 of 138,051   
   Andrew to Carlos E.R.   
   Re: Why does boot block for "Purge old k   
   16 Sep 22 22:52:18   
   
   From: Doug@hyperspace.vogon.gov   
      
   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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca