Re: Stretch Backports Kernel
On 9/23/19, Karolis Pabijanskas <karolis@sysadminguy.org> wrote:
> Hey Everyone!
>
> `stretch-backports` kernel seems to have broken dependencies since a few
> days ago. In particular this package:
> https://packages.debian.org/stretch-backports/linux-image-amd64 seems to
> have a broken dependency for linux-image-4.19.0-0.bpo.6-amd64, which does
> not seem to exist in the repositories (rather older
> linux-image-4.19.0-0.bpo.5-amd64 exists). `linux-headers-amd64` is fine and
> has correct dependencies.
>
> Is this a known issue?
Hi.. I don't know anything about it being a known issue or not, but I
wanted to comment because I followed your link there. I wanted to see
if it was maybe a browser display issue or something. Nope, it's a
"nothing to see here" issue explicitly stated on that page. *grin*
So I checked out the offerings there in the righthand side column:
https://packages.debian.org/stretch-backports/linux-image-4.19.0-0.bpo.6-amd64-unsigned
Appears to match except for that minor detail of being called
"unsigned". I've encountered that regularly k/t debootstrap'ing and
thus manually choosing the Linux-image to go with each time, but I've
never pursued just what that "unsigned" is acknowledging.
So I searched:
https://lists.debian.org/debian-user/2016/09/msg01138.html
That's TWICE in one week that something Debian.org was actually on the
first search results page when I searched very specifically for...
something Debian. Yay!
There's also this in that righthand column of the original link:
http://deb.debian.org/debian/pool/main/l/linux-latest/linux-latest_105+deb10u1~bpo9+1.tar.xz
Visiting this parent directory part of that URL shows that [tarball]
*is* about 4.19 because 5.2 references "106" instead of "105":
http://cdn-fastly.deb.debian.org/debian/pool/main/l/linux-latest/
If anyone decides to play with the source for a first time, this
helped me roll my own (for fun) a couple times:
https://kernelnewbies.org/FAQ/KernelCompilation
This is the first time I noticed the part about forming our own
"devel" (or "hack" or ...) group (down towards bottom of page). Very
cool. I know that new users each bring their own group along with when
those users are created. I just never encountered anything about
creating a group of its own, instead. Will have to invent an excuse to
test drive that part of those instructions.
DISCLAIMER: I'm trusting the information about forming a new group
because it's coming from that Kernel Newbies website that includes
*active* users such as Linux developer Greg KH/Greg Kroah-Hartman. A
quick inbox search also turned up an email from Linus Torvalds himself
to the Newbies list last year.
The list has a cutesie name, yes, but packs a little bit of oomph in
the tips from strangers #Trust department. That said, if anyone can
think of a rational reason why we would NOT designate a new group to
working with /usr/src, that would be good information to have. :)
PS Yes, one of the last words on that KernelNewbies how-to is...
Squeeze. The page notes having been last updated in December 2017. I
think my own kernel compilation success was with Buster when Buster
was about half way through testing.
Additionally, it would be nice to know if anything on KernelNewbies'
KernelCompilation page has understandably evolved into outdated,
potentially now unsafe information.
Cindy :)
--
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *
Reply to: