[systemd-devel] Preventing automatic driver loading on live boot disk

Pascal patatetom at gmail.com
Thu Nov 17 08:09:03 UTC 2022


an udev specific rule may be...

Le mer. 16 nov. 2022 à 10:41, Andrei Borzenkov <arvidjaar at gmail.com> a
écrit :

> On Wed, Nov 16, 2022 at 12:25 PM Vadim Lebedev <vadiml1024 at gmail.com>
> wrote:
> >
> > I'm preparing ubuntu-based live boot disk. It works fine mostly, but on
> some machines equipped with Nvidia Quadro cards the default nouveau driver
> causes problems (temporary freezes). I've determined that buy blacklisting
> nouveau driver (in /etc/modprobe.d/blacklist.conf) I can fix the problem.
> However this approach inhibits nouveau driver for every nvidia equipped
> machine which is an overkill. Of course, i can detect the presence of the
> Quadro card after the boot, blacklist it, do update-initramfs -u and reboot
> but this approach modifies live boot disk and I would like to avoid that. I
> wonder if there is a way to detect the presence of nvidia Quadro somewhere
> very early in the boot sequence and prevent loading of the offending driver
> and fall back to standard VESA driver.
> >
> > I've tried too create a service file:
> > [Unit]
> > Description=Disable Nouveau driver
> > DefaultDependencies=no
> > Before=kmod.service
> >
>
> Drivers for devices are usually loaded dynamically by udev. What does
> kmod.service do? I would guess you rather want
> Before=systemd-udevd.service.
>
> >
> > [Service]
> > Type=oneshot
> > ExecStart=/usr/bin/ocd-blacklist-nouveau.sh
> >
> > ========================
> > and the shell script
> > #!/bin/bash
> > set -x
> > if /usr/bin/lspci | /usr/bin/grep Quadro >/dev/null; then
> >    /usr/bin/logger Found Nvidia Quadro device. Disabling Nouveau driver
> >    echo blacklist nouveau >/etc/modprobe.d/blacklist-nouveau.conf
> > else
> >    rm -f /etc/modprobe.d/blacklist-nouveau.conf
> > fi
> >
> > But it seems that the service is not executed...
> >
>
> For service to be executed something needs to cause this service to be
> executed - other unit dependency or explicit request to start. The
> mere presence of unit definition on disk does not mean systemd will
> try to activate it. You can manually create links of use usual install
> section
>
> [Install]
> WantedBy=default.target
>
> followed by "systemctl enable your.service".
>
> Or you could create a generator that runs before systemd begins
> activating any service.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20221117/6cb5ad36/attachment.htm>


More information about the systemd-devel mailing list