Recent Debian kernels have the simplefb driver built-in on a few
architectures, except in cloud flavours. It handles 'simple-framebuffer'
devices registered from elsewhere: possibly in a device-tree fragment,
or from another driver like framebuffer_coreboot, or via SYSFB_SIMPLEFB.
The more modern alternative to it is simpledrm which also handles
the same 'simple-framebuffer' devices.
We haven't switched to simpledrm, but if we do it's possible we will
want it to be a module, since it depends on the drm subsystem and would
require that to be built-in otherwise. Regardless of what we choose for
Debian kernels, it's still possible for custom-built kernels to have
either/both of simplefb and simpledrm as modules instead of built-in.
Include these modules in initramfs unconditionally when MODULES=dep.
For MODULES=most, add the two drivers to the framebuffer modules list.
When MODULES=dep and these drives are (probed) modules, our check for
platform framebuffers always finds a "module" directory in the driver's
sysfs directory and incorrectly skips handling graphics modules, ignore
the false positive.
Unfortunately, these drivers sometimes do not get probed automatically.
One such case is efifb with SYSFB_SIMPLEFB=y, which is quite important.
Add a init-top script that tries to probe simpledrm, with a fallback to
simplefb. Explicitly try to probe these modules for break=top as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
If the busybox-static package is installed, the modprobe implementation
used will be the one from busybox, which behaves slightly differently.
Specifically, the busybox implementation does not support `install`
commands from modprobe.d conf files:
https://git.busybox.net/busybox/tree/modutils/modprobe.c?h=1_31_stable#n279
Since mkinitramfs already ensures that /sbin/modprobe is copied into
/sbin for the initrd, it is safe to fully-qualify the modprobe call and
never invoke the busybox version.
setupcon gained a --setup-dir option to support initramfs builders,
documented since console-setup 1.111. Use this to simplify our
own scripts.
Related-to: #620041
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Sometimes globbing and word splitting is wanted. Therefore explicitly
disable the check for these line.
Signed-off-by: Benjamin Drung <benjamin.drung@cloud.ionos.com>
shellcheck found more issues than SC1074. Address most of these issues.
You can check the shell code by running:
```
shellcheck -e SC1090,SC1091 -s dash hook-functions $(find * -type f
\( -executable ! -name rules -o -regex '.*\.\(post\|pre\).*'
-o -regex "^\(docs\|scripts\)/.*" ! -name '*.md' \))
```
Signed-off-by: Benjamin Drung <benjamin.drung@cloud.ionos.com>
fb should be loaded after initramfs by init to have a beautiful
userland. allows faster boot not to try parsing crazy things
with only posix sh at our hands.
this will need a README.DEBIAN section as noone is now currently
loading fbcon.
Signed-off-by: maximilian attems <maks@debian.org>
The i915 DRM module doubles as a framebuffer of sorts, at least in kernel
mode-setting setups; like its cousins intelfb and i810fb, it effectively
requires intel-agp despite not actually using any of its symbols. As
such, could you please arrange for scripts/init-top/framebuffer to give
it the same treatment, per the following patch?:
(closes: #533258)
Signed-off-by: maximilian attems <maks@debian.org>
After further experimentation, I discovered additional problems that my
first patch did not address, namely that
1) Some FB drivers need the AGP subsystem up and running before they
are loaded and
2) intelfb needs intel-agp.ko, but does not have a dependency on it.
intelfb does not actually *work* on my testsystem after this (it
crashes), but unlike with plain initramfs-tools, it loads (and prints
something useful if loaded with the probeonly option). I'll try to find
out why it fails to work tomorrow; it's probably an unrelated issue.
[ make the patch applyable, probably whitespace damaged, fix comments,
no need to pass -q to modprobe that is set globaly -maks ]
(closes: #416063, #455876)
Signed-off-by: maximilian attems <maks@debian.org>
udev isn't started at this point and therefore can't create framebuffer
devices. This causes usplash not to run on PS3.
set sane permissions will making the char files.
This reverts commit 0aec8b0c22b7622841c4ab7a3b492b4d2657456f.
Uvesafb framebuffer driver needs v86d userspace program
but when fb driver is modprobed at init-top stage of initrd,
/dev/zero and /dev/mem are missing because udev have not
been run yet.
thanks to Frans Pop <elendil@planet.nl> for report,
idea stolen from Ubuntu, adapted their boot script
same boot param.
closes: #485786
Signed-off-by: maximilian attems <maks@debian.org>
nuke fb device mknod creation as udev creates the fb device nodes.
suggested by waldi. positive test on qemu with usplash.
let's see if we get a bad interaction with usplash and vga=XXX boots.
* kick mdrun script
* update control for lenny + ubuntu
* add _all_ ide, block and drivers
* use MODPROBE_OPTIONS and kill any modprobed arg
* small doc + whitespace fixes
