[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: files under /boot



On 2020-05-29 at 06:40, rhkramer@gmail.com wrote:

> Ahh, thanks -- I'm not the OP, but I think I'm learning something,
> and I want to confirm at least one point -- see below.
> 
> On Thursday, May 28, 2020 09:34:18 PM The Wanderer wrote:
> 
>> What does the following command output?
>> 
>> $ dpkg -l "*4.9.0*" | grep ii
> 
> First I had to figure out (google) to find what the leading ii
> means,

It took me a moment to catch what you meant by this; standard
terminology would describe that as a "trailing" ii, because it's at the
end of the line (thus behind, seen last, trailing) rather than the
beginning (thus ahead, seen first, leading).

> iiuc, the first i means the file (kernel image in this case) should
> be installed (based on something), and the second i indicates that it
> is installed.

Yes, but the details aren't that important.

> Two questions:
> 
> 1. On my Wheezy system, I have 3 kernal images marked ii.  Clearly,
> only one kernel is used on any particular boot, so (as someone else
> mentioned in a later post), the only purpose of the two older kernels
> is as backup?

Generally, yes.

Think of it as a bit similar to the "last known good" configuration from
a Windows boot-recovery menu. If something about the newest kernel (and
initrd, et cetera) turns out not to work on this particular computer,
it's important to have the previously in-use kernel still available so
that the system can boot back into it and the sysadmin can try to
troubleshoot the problem.

There can be special cases where someone might want to keep a third
kernel around for one reason or another, but by and large, unless you
know what you're doing and put the additional kernel there for some
specific reason, you only need to keep around two kernels: the newest
available, and the last one you successfully booted and ran prior to
that newest kernel.

(Technically it's also safe to remove that prior kernel once you're
running the newer one and have confirmed that it's sufficiently stable
for your purposes. In practice, however, I don't find it worth bothering
with to remove the most-recent prior kernel manually, rather than
leaving it up to Debian's automatic mechanisms to mark it as
autoremove'able at some later point.)

> 1.a. (Ok, I can't count)  And maybe they are marked as need to be
> installed (the first i) because they are in grub as alternate boot
> possibilities?

No - this is purely dpkg package-installation state.

Before actually installing a package, dpkg marks it as "selected for
installation". That's the first 'i'.

Then dpkg tries to actually install it. If it succeeds, that's the
second 'i'. Otherwise, you'll see another character there.

The possible values for the selection and installation states are
described in dpkg(1) (AKA 'man dpkg'), but not with the abbreviations as
far as I can see at a glance. I know they're described somewhere else,
but I don't recall where; that said, Greg Wooledge pulled the necessary
information together fairly well.

> 2. As mentioned, I have 3 linux-image files, but only one
> linux-header file (for the latest image (in Wheezy).  Presumably,
> I've done something wrong somewhere along the line, possibly by
> manually deleting the linux-header files for the two older images?

I'm not sure what you mean by 'linux-header file'.

Are you referring to packages like the ones reported by

$ dpkg -l "linux-headers*" | grep ii

? Those aren't individual files, but entire packages, with many files;
on my system, two of them (for one kernel version) have nearly 18,000
total files.

If you manually deleted the files from one of these packages, then you
should probably expect something else to be broken, because these
packages wouldn't get installed if nothing depended on them. I would
recommend reinstalling whichever package it is.

> 2.a. (I said I can't count) And, presumably, to get my system closer
> to a correct configuration, I should consider finding and removing
> the package for the oldest kernel?

I wouldn't necessarily bother, unless you know for sure that you're
never going to boot back into it. Keeping around an older kernel or two
doesn't really hurt, unless you're short on disk space under /boot.

> I guess I'm not very concerned about having a backup kernel (knock on
> wood) -- I've been using this kernel for quite a while without
> problems.

Yeah, unless you've upgraded the kernel recently there's not a lot of
need for the backup. I'm just used to an environment where a new kernel
becomes available on a fairly frequent basis, because I track testing; I
kind of thought that updated kernels (with security fixes, et cetera)
hit stable on a regular basis too, but it's been a long time since I was
in a position to experience that personally.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: