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,605 of 138,051   
   Carlos E.R. to Andrew   
   Re: Why does boot block for "Purge old k   
   17 Sep 22 15:00:38   
   
   From: robin_listas@es.invalid   
      
   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.   
      
   --   
   Cheers, Carlos.   
      
   --- 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