Re: Update: Last Linux kernel did not install correctly (was: Re: Problems with Apper / automatic upgrading of my Debian 7.11 system)
On Wednesday 29 June 2016 10:44:46 Selim T. Erdoğan wrote:
> On Tue, Jun 28, 2016 at 09:32:43AM -0400, rhkramer@gmail.com wrote:
> > Ok, I now believe that my problem is that the last Linux image
> > (kernel) update did not install correctly / completely. That image
> > was "linux-image-3.2.0-4- amd64 Linux 3.2 for 64-bit PCs"
> >
> > I believe that what has been happening since then is that, each time
> > I've installed something else (either recommended by apper to keep
> > the system up- to-date or as a new program I wanted) both the
> > intended program and the Linux image attempted to install, and,
> > typically, the intended program was installed or updated
> > successfully, but the Linux image was not.
> >
> > I can't absolutely confirm that for every case before a few days
> > ago, but, in the updates or installs I've done since then, I've
> > noticed that the popup message that says there was a problem occurs
> > while apper is attempting to install the new kernel. (To
> > clarify--since that attempt about two weeks ago to install the
> > kernel, every subsequent attempt to install anything has caused that
> > message to popup, but, before a few days ago, I hadn't noticed that
> > apper was re-attempting to install the Linux image).
> >
> > Aside: apper has installed several linux images before this one, and
> > I never had this problem before, and typically did not reboot soon
> > after the update-- instead, I waited until there was some other
> > reason to reboot.
> >
> > So, now what do I do?
>
> I sometimes have problems with /boot getting full. If you've
> installed several linux images and they're all taking up room in
> /boot, you might have to get rid of an old one (which you won't be
> using anymore).
>
> You can check if /boot is getting full with the "df -h" command.
>
> To get rid of an old image cleanly, just purge the associated package.
Another case where one can get bit is if the vmlinuz file is split by the
allocation of a 2nd inode to it, and this inode is beyond the ability of
the bios to reach. My own /boot is a directory in /, and without a
separate /boot partition, this could bite me even though a du -h /boot
says its only using 97Mb.
Our tools for mapping that and showing us meaningful data do not seem to
exist, or I have not been made aware of them.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: