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