• Re: Upcoming changes to Debian Linux kernel packages

    From Michel Verdier@21:1/5 to Bastian Blank on Sun Oct 1 12:20:01 2023
    On 2023-10-01, Bastian Blank wrote:

    Then I upgrade the system, which brings Linux 6.7 (along linux-image-6.6
    which is kept installed) and a new version of the gpu driver (which adds
    support for 6.7). So the old gpu module for 6.6 gets removed and a new one >> is built for 6.7 only (since there are only 6.7 headers now).

    Ah, here lays the missconception. No, the 6.6 ones are not removed. Why should they be? The system knows it can't rebuild them.

    As the old kernel driver is not rebuild it perhaps could break things if libraries/programs are tied on a specific version of the driver

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bastian Blank@21:1/5 to Michel Verdier on Sun Oct 1 13:50:02 2023
    Hi Michel

    On Sun, Oct 01, 2023 at 12:19:22PM +0200, Michel Verdier wrote:
    On 2023-10-01, Bastian Blank wrote:
    Ah, here lays the missconception. No, the 6.6 ones are not removed. Why should they be? The system knows it can't rebuild them.
    As the old kernel driver is not rebuild it perhaps could break things if libraries/programs are tied on a specific version of the driver

    So you upgrade the driver and libaries and suddenly your system fails
    until you reboot? Okay, I could imaging NVidia doing something like
    tying libraries to kernel modules. At least in the past they replaced
    gl libraries that did not longer work with X forwarding.

    Could you please name the culprit, or is this just a theoretical
    problem?

    However what if the new driver does not build with the old kernel?

    There are endless possibilities to break this. Which ones are important
    and can be supported?

    Bastian

    --
    Well, Jim, I'm not much of an actor either.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michel Verdier@21:1/5 to Bastian Blank on Sun Oct 1 16:40:01 2023
    On 2023-10-01, Bastian Blank wrote:

    So you upgrade the driver and libaries and suddenly your system fails
    until you reboot? Okay, I could imaging NVidia doing something like
    tying libraries to kernel modules. At least in the past they replaced
    gl libraries that did not longer work with X forwarding.

    Could you please name the culprit, or is this just a theoretical
    problem?

    Yes you named it. Without rebuilding with dkms the old kernel disable
    nvidia loading.

    However what if the new driver does not build with the old kernel?

    Of course. But it would fail during compilation not days after when you desperately need to boot on the only supposedly working kernel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From herve@21:1/5 to All on Tue Oct 3 17:30:01 2023
    This is a multi-part message in MIME format.
    6.7). So the old gpu module for 6.6 gets removed and a new one is
    >> built for 6.7 only (since there are only 6.7 headers now).

    Bastian> Ah, here lays the missconception. No, the 6.6 ones are not
    Bastian> removed. Why should they be? The system knows it can't
    Bastian> rebuild them.

    Bastian> If the current implementation would remove them, it is a
    Bastian> problem there, not in the concept.

    I still think it would help if you would work more on articulating what problem you are trying to solve with the linux-headers versioning
    change. I have read multiple versions of this proposal, and your
    follow-ups, and I still do not understand what is prompting the
    linux-headers change.

    My intuition mirrors others in the conversation that it is problematic
    to support multiple kernel versions without also supporting multiple
    header versions.

    concerning the linux-headers. may i explain what happend to me.

    I reinstalled a debian 11.6 some months ago. and last week i had to make virtualbox functioning again. it had to "compile" some kernel modules
    and need some "headers". my kernel (from the install is  5.10.0-23-amd64
    #1 SMP Debian 5.10.179-3 (2023-07-27) x86_64 GNU/Linux) so virtualbox
    need some 5.10.0-23 headers... you can find 5.10.0.20, 5.10.0.22, 
    5.10.0.25 in the repos from where the install came from.

    I had to surf the web and find a 5.10.0.23 in the web site of an
    university and wget it to dpkg -i it.

    I do not know (maybe i could not even understand) the security reasons/problems of the headers versioning but it seems from my end-user
    point of view that, the actual situation that lend me to download from a website is the worst possible solution.


    hervé


    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    &gt;&gt; 6.7). So the old gpu module for 6.6 gets removed and a new
    one is
    <blockquote type="cite" cite="mid:tsl34yrdbfm.fsf@suchdamage.org">
    <pre class="moz-quote-pre" wrap=""> &gt;&gt; built for 6.7 only (since there are only 6.7 headers now).

    Bastian&gt; Ah, here lays the missconception. No, the 6.6 ones are not
    Bastian&gt; removed. Why should they be? The system knows it can't
    Bastian&gt; rebuild them.

    Bastian&gt; If the current implementation would remove them, it is a
    Bastian&gt; problem there, not in the concept.

    I still think it would help if you would work more on articulating what
    problem you are trying to solve with the linux-headers versioning
    change. I have read multiple versions of this proposal, and your
    follow-ups, and I still do not understand what is prompting the
    linux-headers change.

    My intuition mirrors others in the conversation that it is problematic
    to support multiple kernel versions without also supporting multiple
    header versions.

    </pre>
    </blockquote>
    <p>concerning the linux-headers. may i explain what happend to me.</p>
    <p>I reinstalled a debian 11.6 some months ago. and last week i had
    to make virtualbox functioning again. it had to "compile" some
    kernel modules and need some "headers". my kernel (from the
    install is  5.10.0-23-amd64 #1 SMP Debian 5.10.179-3 (2023-07-27)
    x86_64 GNU/Linux) so virtualbox need some 5.10.0-23 headers... you
    can find 5.10.0.20, 5.10.0.22,  5.10.0.25 in the repos from where
    the install came from.</p>
    <p>I had to surf the web and find a 5.10.0.23 in the web site of an
    university and wget it to dpkg -i it.</p>
    <p>I do not know (maybe i could not even understand) the security
    reasons/problems of the headers versioning but it seems from my
    end-user point of view that, the actual situation that lend me to
    download from a website is the worst possible solution.</p>
    <p><br>
    </p>
    <p>hervé<br>
    </p>
    <div id="grammalecte_menu_main_button_shadow_host" style="width:
    0px; height: 0px;"></div>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to herve on Tue Oct 3 19:10:01 2023
    herve <herve@couvelard.com> writes:

    concerning the linux-headers. may i explain what happend to me.

    I reinstalled a debian 11.6 some months ago. and last week i had to
    make virtualbox functioning again. it had to "compile" some kernel
    modules and need some "headers". my kernel (from the install is  5.10.0-23-amd64 #1 SMP Debian 5.10.179-3 (2023-07-27) x86_64
    GNU/Linux) so virtualbox need some 5.10.0-23 headers... you can find 5.10.0.20, 5.10.0.22,  5.10.0.25 in the repos from where the install
    came from.

    I had to surf the web and find a 5.10.0.23 in the web site of an
    university and wget it to dpkg -i it.

    No, you didn't. You could, and should, simply update the kernel with
    the latest security fixes, and then install the matching headers from
    the same repo.

    I do not know (maybe i could not even understand) the security reasons/problems of the headers versioning but it seems from my
    end-user point of view that, the actual situation that lend me to
    download from a website is the worst possible solution.

    Running out-of-tree kernel code means that you can't use the security
    card. Sorry.


    Bjørn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From herve@21:1/5 to All on Tue Oct 3 20:40:01 2023
    This is a multi-part message in MIME format.
    e 03/10/2023 à 19:06, Bjørn Mork a écrit :
    herve <herve@couvelard.com> writes:

    concerning the linux-headers. may i explain what happend to me.

    I reinstalled a debian 11.6 some months ago. and last week i had to
    make virtualbox functioning again. it had to "compile" some kernel
    modules and need some "headers". my kernel (from the install is
    5.10.0-23-amd64 #1 SMP Debian 5.10.179-3 (2023-07-27) x86_64
    GNU/Linux) so virtualbox need some 5.10.0-23 headers... you can find
    5.10.0.20, 5.10.0.22,  5.10.0.25 in the repos from where the install
    came from.

    I had to surf the web and find a 5.10.0.23 in the web site of an
    university and wget it to dpkg -i it.
    No, you didn't. You could, and should, simply update the kernel with
    the latest security fixes, and then install the matching headers from
    the same repo.

    I do not know (maybe i could not even understand) the security
    reasons/problems of the headers versioning but it seems from my
    end-user point of view that, the actual situation that lend me to
    download from a website is the worst possible solution.
    Running out-of-tree kernel code means that you can't use the security
    card. Sorry.


    Bjørn

    Bjørn

    thank you for your answer.

    I remember that linus had the aim to be the less annoying for the user-expérience. I can understand _your_ point of view to have the "kernel-three-code" and the "security" card things. the fact is i didn't
    choose neither testing, neither sid but stable. And in my experience
    upgrading kernel is not always smooth. so I used to keep the same
    kernel, until it is important to change, and i have time to do it. Not
    when i have to run a wm to finish a job.

    It is, from my point of view a "geek" stuff to "delete" the packages
    from the repos. _you_ think I _must_ upgrade my kernel. OK. But if it
    was so simple their would not have theses messages on the list. When i
    tried to install the headers i had no message i should upgrade, just the packages were not existing (the same that if there was was a typo). So i
    surfed the web to find it. How could i know that i _should_ upgrade to
    benefit the right to get some headers ? If i installed them in the same
    time as the kernel, i would have them already : which differences in
    terms of security (installed in july - installed in september) ?

    I just want to  point, that i didn't initiate a thread to complain, i
    just  share my experience on an existing thread about headers and
    security. i was not shamming security or else. i was just saying that
    the politic to improve security pushed me to download from the web
    instead of the repos. is the solution worse than the disease ? I use
    linux on the desktop for almost 25 years, red hat, then fedora, then
    debian and that never happened until last week. I was thinking that the difference between free software and proprietary one is the possibility
    for free software user to upgrade when _they_ want and not when the
    _supplier_ decide they should. and suppress headers is _forcing_ user to upgrade.

    So to conclude, my experience is not a way to propose or impose a
    solution but to point that there are sometimes between chair and screen
    some "normal" persons that just want things to run. If the solution
    proposed by virtualbox (install headers, naming them) could not
    function, they will install something else. And, if i find alone the
    solution by some little experience, lots of people won't. Of course you
    are right about "Running out-of-tree kernel code" but that would not
    help them.

    Linux is not so easy, maybe it is not a good idea to had some
    complications. if a kernel is so rapidly "out-of-tree" why let it in the "stable" distribution ?

    my 2 cents.

    hervé

    ps : i really understand your point of view, i just want to say it is
    not in the 10 commandments










    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <div class="moz-cite-prefix">e 03/10/2023 à 19:06, Bjørn Mork a
    écrit :<br>
    </div>
    <blockquote type="cite" cite="mid:87fs2riqka.fsf@miraculix.mork.no">
    <pre class="moz-quote-pre" wrap="">herve <a class="moz-txt-link-rfc2396E" href="mailto:herve@couvelard.com">&lt;herve@couvelard.com&gt;</a> writes:

    </pre>
    <blockquote type="cite">
    <pre class="moz-quote-pre" wrap="">concerning the linux-headers. may i explain what happend to me.

    I reinstalled a debian 11.6 some months ago. and last week i had to
    make virtualbox functioning again. it had to "compile" some kernel
    modules and need some "headers". my kernel (from the install is  5.10.0-23-amd64 #1 SMP Debian 5.10.179-3 (2023-07-27) x86_64
    GNU/Linux) so virtualbox need some 5.10.0-23 headers... you can find
    5.10.0.20, 5.10.0.22,  5.10.0.25 in the repos from where the install
    came from.

    I had to surf the web and find a 5.10.0.23 in the web site of an
    university and wget it to dpkg -i it.
    </pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap="">
    No, you didn't. You could, and should, simply update the kernel with
    the latest security fixes, and then install the matching headers from
    the same repo.

    </pre>
    <blockquote type="cite">
    <pre class="moz-quote-pre" wrap="">I do not know (maybe i could not even understand) the security
    reasons/problems of the headers versioning but it seems from my
    end-user point of view that, the actual situation that lend me to
    download from a website is the worst possible solution.
    </pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap="">
    Running out-of-tree kernel code means that you can't use the security
    card. Sorry.


    Bjørn
    </pre>
    </blockquote>
    <br>
    <pre class="moz-quote-pre" wrap="">Bjørn</pre>
    <p>thank you for your answer.<br>
    </p>
    <p>I remember that linus had the aim to be the less annoying for the
    user-expérience. I can understand _your_ point of view to have the
    "kernel-three-code" and the "security" card things. the fact is i
    didn't choose neither testing, neither sid but stable. And in my
    experience upgrading kernel is not always smooth. so I used to
    keep the same kernel, until it is important to change, and i have
    time to do it. Not when i have to run a wm to finish a job.<br>
    </p>
    <p>It is, from my point of view a "geek" stuff to "delete" the
    packages from the repos. _you_ think I _must_ upgrade my kernel.
    OK. But if it was so simple their would not have theses messages
    on the list. When i tried to install the headers i had no message
    i should upgrade, just the packages were not existing (the same
    that if there was was a typo). So i surfed the web to find it. How
    could i know that i _should_ upgrade to benefit the right to get
    some headers ? If i installed them in the same time as the kernel,
    i would have them already : which differences in terms of security
    (installed in july - installed in september) ?<br>
    </p>
    <p>I just want to  point, that i didn't initiate a thread to
    complain, i just  share my experience on an existing thread about
    headers and security. i was not shamming security or else. i was
    just saying that the politic to improve security pushed me to
    download from the web instead of the repos. is the solution worse
    than the disease ? I use linux on the desktop for almost 25 years,
    red hat, then fedora, then debian and that never happened until
    last week. I was thinking that the difference between free
    software and proprietary one is the possibility for free software
    user to upgrade when _they_ want and not when the _supplier_
    decide they should. and suppress headers is _forcing_ user to
    upgrade.<br>
    </p>
    <p>So to conclude, my experience is not a way to propose or impose a
    solution but to point that there are sometimes between chair and
    screen some "normal" persons that just want things to run. If the
    solution proposed by virtualbox (install headers, naming them)
    could not function, they will install something else. And, if i
    find alone the solution by some little experience, lots of people
    won't. Of course you are right about "Running out-of-tree kernel
    code" but that would not help them.</p>
    <p>Linux is not so easy, maybe it is not a good idea to had some
    complications. if a kernel is so rapidly "out-of-tree" why let it
    in the "stable" distribution ?<br>
    </p>
    <p>my 2 cents.<br>
    </p>
    <p>hervé</p>
    <p>ps : i really understand your point of view, i just want to say
    it is not in the 10 commandments <br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div id="grammalecte_menu_main_button_shadow_host" style="width:
    0px; height: 0px;"></div>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)