Re: Rejuvenated kernel-package uploaded to unstable, please test - Debian

This is a discussion on Re: Rejuvenated kernel-package uploaded to unstable, please test - Debian ; Manoj wrote: > It correctly installs firmware in a versioned location under > /lib/firmware. Problem is that even though this may avoid package conflicts, it is *not* correct given the way Debian currently looks for firmware. Also, it is not ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Re: Rejuvenated kernel-package uploaded to unstable, please test

  1. Re: Rejuvenated kernel-package uploaded to unstable, please test

    Manoj wrote:
    > It correctly installs firmware in a versioned location under
    > /lib/firmware.


    Problem is that even though this may avoid package conflicts, it is *not*
    correct given the way Debian currently looks for firmware. Also, it is
    not the way upstream recommends to install firmware.

    All (non-free) Debian firmware packages install the firmware files
    directly under /lib/firmware, not /lib/firmware/$kernel-version.

    And Debian's udev does not consider the kernel-version when looking for
    firmware. /lib/udev/hotplug.functions has:
    FIRMWARE_DIRS='/lib/firmware /usr/local/lib/firmware /usr/lib/hotplug/firmware'

    This means that if you start installing the same firmware file under
    versioned directories, udev will use the first one it finds. Which will
    be the one for some $random kernel version and not the one for the
    currently running kernel.

    Installing firmware in versioned directories will also result in bloated
    initramfs initrds as the whole /lib/firmware dir will be copied into
    them, including the duplicated firmware files for all installed kernel
    versions.

    The correct solution for this would IMO be to have kernel-package build a
    *separate* package for firmware which does not include the kernel version
    in its package name.

    IMO this is an RC bug in the new kernel-package.

    Cheers,
    FJP

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkj0HqsACgkQgm/Kwh6ICoQMegCgidSOLog0zaodfWxpy3TGqJR/
    1ioAn3M5RZBZfgRiSQsdxx4e2WcFjCDm
    =W++E
    -----END PGP SIGNATURE-----


  2. Re: Rejuvenated kernel-package uploaded to unstable, please test

    On Tue, Oct 14, 2008 at 12:23 PM, Frans Pop wrote:

    > Problem is that even though this may avoid package conflicts, it is *not*
    > correct given the way Debian currently looks for firmware. Also, it is
    > not the way upstream recommends to install firmware.
    >
    > All (non-free) Debian firmware packages install the firmware files
    > directly under /lib/firmware, not /lib/firmware/$kernel-version.
    >
    > And Debian's udev does not consider the kernel-version when looking for
    > firmware. /lib/udev/hotplug.functions has:
    > FIRMWARE_DIRS='/lib/firmware /usr/local/lib/firmware /usr/lib/hotplug/firmware'


    In contrast, the latest upstream udev (130) has this:

    FIRMWARE_DIRS="/lib/firmware/$(uname -r) /lib/firmware"

    --
    bye,
    pabs

    http://wiki.debian.org/PaulWise


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: Rejuvenated kernel-package uploaded to unstable, please test

    On Tue, Oct 14, 2008 at 2:38 PM, Manoj Srivastava wrote:

    > Seems like upstream udev firmware loader does look at
    > /lib/firmware/$(uname -r)/, which seems sane.
    >
    > Why was this removed?


    It wasn't removed, upstream added that after the version of udev in Debian.

    --
    bye,
    pabs

    http://wiki.debian.org/PaulWise


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: Rejuvenated kernel-package uploaded to unstable, please test

    Paul Wise wrote:
    > In contrast, the latest upstream udev (130) has this:
    > FIRMWARE_DIRS="/lib/firmware/$(uname -r) /lib/firmware"


    From what I've seen on lkml I suspect this has mainly been added because
    some distributions _do_ install firmware is versioned subdirs.

    Debian currently does not support versioned subdirs for firmware in its
    userland. Thus, for Lenny, we should not have tools which install it
    there.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkj0YAgACgkQgm/Kwh6ICoTrpACfQAx3sxtorOCJrw6AnnbwqOQU
    82UAnRaftHdilhKgzLofoYilDzUA6BL7
    =iM/w
    -----END PGP SIGNATURE-----


  5. Re: Rejuvenated kernel-package uploaded to unstable, please test

    Manoj Srivastava wrote:

    >> This means that if you start installing the same firmware file under
    >> versioned directories, udev will use the first one it finds. Which
    >> will be the one for some $random kernel version and not the one for
    >> the currently running kernel.

    >
    > This is not a sound argument.
    >
    > And if I have multiple kernels installed, and only one firmware,
    > theb the firmware on the machine will be the random firmware most
    > recently installed. By just reverting back to upstream behaviour, this
    > randomness in the face of versioned dirs disappears.


    Please hit me with the cluebat; apparently I'm not understanding anything. Why
    would I want to have more than one firmware installed? AIUI, the firmware is
    meant to be installed into the hardware and as such shouldn't be tied to the
    kernel version. In fact, I would expect the firmware to be the same across
    several kernel versions. A new firmware should not break the hardware-kernel
    interface in a backwards-incompatible manner. And I guess the kernel should
    ignore hardware features the firmware doesn't support. The worst case scenario
    I see is that when you have different kernel and firmware versions, there could
    be things your hardware can do, the kernel supports it, but the firmware
    doesn't or the other way around. In that case, I only care about having the
    latest firmware around.

    --

    Felipe Sateler


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: Rejuvenated kernel-package uploaded to unstable, please test

    On Tue, 14 Oct 2008, Felipe Sateler wrote:
    > Please hit me with the cluebat; apparently I'm not understanding
    > anything. Why would I want to have more than one firmware installed?
    > AIUI, the firmware is meant to be installed into the hardware and as
    > such shouldn't be tied to the kernel version.


    Except that it's not. Lots of firmware for whatever reason is specific
    to a specific set of kernel versions.


    Don Armstrong

    --
    One day I put instant coffee in my microwave oven and almost went back
    in time.
    -- Steven Wright

    http://www.donarmstrong.com http://rzlab.ucr.edu


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  7. Re: Rejuvenated kernel-package uploaded to unstable, please test

    On Tue, 14 Oct 2008, Felipe Sateler wrote:
    > Please hit me with the cluebat; apparently I'm not understanding anything. Why
    > would I want to have more than one firmware installed? AIUI, the firmware is


    The firmware has an ABI to the kernel driver. If it changes, both have to
    change. This has happened with, e.g., ipw2200 (which has out-of-tree
    firmware).

    I have no idea if this ever happened to one of the drivers with in-tree
    firmware. But it is a very rare event, that much I have to agree with the
    people who made this mess.

    > interface in a backwards-incompatible manner. And I guess the kernel should
    > ignore hardware features the firmware doesn't support. The worst case scenario


    That's not how it works. The way it works is that it can easily blow up in
    flames if it uses the wrong version of the firmware by mistake. Or (FAR
    more likely) it just doesn't enable the device at all because it cannot find
    the correct version of the firmware it wants (if everyone did their job
    right and changed the firmware name when they changed the firmware).

    --
    "One disk to rule them all, One disk to find them. One disk to bring
    them all and in the darkness grind them. In the Land of Redmond
    where the shadows lie." -- The Silicon Valley Tarot
    Henrique Holschuh


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Re: Rejuvenated kernel-package uploaded to unstable, please test

    On Tue, 14 Oct 2008, Paul Wise wrote:
    > On Tue, Oct 14, 2008 at 2:38 PM, Manoj Srivastava wrote:
    > > Seems like upstream udev firmware loader does look at
    > > /lib/firmware/$(uname -r)/, which seems sane.
    > >
    > > Why was this removed?

    >
    > It wasn't removed, upstream added that after the version of udev in Debian.


    Not Debian. Ubuntu. And it caused quite a fight in LKML, too, which I
    won't bother to repeat here.

    Basically, there are three choices:

    1. Package the firmware as the new kernel-package does (i.e. the Ubuntu way,
    which upstream udev now supports).

    2. Do not package firmware at all when doing kernel builds and packages.
    People will have to get it from a firmware package (that doesn't exist),
    which has a new upstream (that exists, but doesn't have all the firmware in
    it yet), etc.

    3. Add a new binary package to go along with the kernel-image, with the
    firmware for that kernel version. If you version the dirs, it is just (1)
    in a worse shape, so this calls for installing everything in /lib/firmware,
    and letting only one such binary package per system. Which has severe
    drawbacks if the firmware filenames are NOT versioned in the kernel code
    (they ARE supposed to be versioned, and it is a bug if they change without
    changing file name, except for bug fixes that are forward-and-backward
    compatible). Obviously, old versions of the firmware are not kept around
    forever inside the kernel tree, and it *will* cause issues with older
    kernels that wanted that old version of the firmware. This should happen
    *very* rarely (firmware really doesn't change much).

    The thruth is that this whole crap was *designed* with the agenda to make it
    as painful as possible for distros to distribute any in-kernel firmware, in
    order to force leverage to get all in-kernel firmware out of the kernel.

    --
    "One disk to rule them all, One disk to find them. One disk to bring
    them all and in the darkness grind them. In the Land of Redmond
    where the shadows lie." -- The Silicon Valley Tarot
    Henrique Holschuh


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread