I’m getting a single, lonely error message at boot time:
nouveau 0000:02:00.0: disp: outp 02:0006:0242: no bios dp data
I’ve done a bit of googling but still can’t figure out what’s going on. I’ve gathered nouveau is an NVidia driver, and that ‘dp’ means “DisplayPort”? But every thread I’ve come across seems to be about someone seeing this message and not being able to boot at all. I can boot totally fine (though I don’t have a Mini DisplayPort adapter to test whether that’s working).
Any insight about what this message means and how to fix it would be highly appreciated.
Thanks. Should I operate on the expectation that I may see mysterious-but-otherwise-harmless error messages at boot time in Linux, then? Is there any way to tell the difference between a seemingly-harmless error message and a bite-me-in-the-ass-one-day error message? And if I see an error message that simply doesn’t apply to me at all (because, say, it relates to functionality that doesn’t exist in my hardware), might that be considered a bug?
There are no hard and fast answers here, most are just informational and some cryptic messages may more easily digested by kernel developers perhaps. (I assume similar happens in other OSs, but maybe hidden from the user?) I think you’d soon know if a boot-related error message was of critical/impacting nature. It’s often when there are apparent hardware issues that one might then examine the kernel messages that might be connected with it.
Definitely yes, especially when it comes to BIOS/ACPI. In (early) boot the kernel tries to figure out what is actually there and find out if everything is being announced and handled to “standard” expectations.
However, Firmware (BIOS/UEFI) and ACPI code is often written like **** and not obeying the standards, so the kernel tries to log such events in case something goes wrong later in the boot process.
And of course, there might also be a bug in the kernel itself, so logging all things in early boot that might cause a problem later makes sense for the cost of potentially confusing the user even (or especially) if the system still comes up fine.
Let me show you a small collection from the last boot of the machine I am just writing this posting on.
ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs.
mtrr: corrected configuration.
system 00:00: [mem 0xfed1c000-0xfed1ffff] has been reserved
system 00:00: [mem 0xfed10000-0xfed17fff] could not be reserved
Those are just a few messages from the first one or two seconds in early booting stage, the last one repeats about 5 to 6 times for different regions of memory and still the machine does not explode and starts up fine.
The first few ones are Problems/Bugs in ACPI and BIOS settings, which the kernel tries to correct and/or work around (sometimes simply by ignoring it), the last one is a typical “Let’s see what I can do for some function and if the machine actually supports it … OH, it doesn’t, well then let’s just not use that and carry on …”.
Even “worse”, here are some real error messages caused by the OS (the init system in this case) at a later stage (but still quite early in the boot process):
systemd[1]: Starting Apply Kernel Variables...
systemd-sysctl[250]: Couldn't write '1' to 'net/ipv6/conf/default/use_tempaddr', ignoring: No such file or directory
systemd-sysctl[250]: Couldn't write '0' to 'dev/cdrom/autoclose', ignoring: No such file or directory
systemd-sysctl[250]: Couldn't write '0' to 'net/bridge/bridge-nf-call-ip6tables', ignoring: No such file or directory
systemd-sysctl[250]: Couldn't write '0' to 'net/bridge/bridge-nf-call-iptables', ignoring: No such file or directory
systemd-udevd[310]: specified group 'trusted' unknown
systemd[1]: nss-lookup.target: Dependency Before=nss-lookup.target dropped
systemd[1]: Binding to IPv6 address not available since kernel does not support IPv6.
systemd[1]: [/usr/lib/systemd/system/rpcbind.socket:14] Failed to parse address value, ignoring: ::]:111
systemd[1]: Binding to IPv6 address not available since kernel does not support IPv6.
systemd[1]: [/usr/lib/systemd/system/rpcbind.socket:15] Failed to parse address value, ignoring: ::]:111
OMG, we’re all gonna DIE!!11111 …
But seriously, this looks horrible, why does it not have any visible negative effect?
As said before by deano_ferrari, there is no easy answer, for example all ipv6 related error messages in my example are easy to explain and harmless. The system starts with ipv6 disabled (on purpose and disabled by me adding the respective boot parameter), so all steps trying to use ipv6 addresses (in parallel to ipv4) will give you these error messages.
The message about “group trusted not found” is actually a bug, because udevd seems to load its rule set bevore having read /etc/passwd and/or /etc/group, but this (re)loading of udev happens multiple times during boot up, so it gives you this error in very early boot but runs again without problems a little later.
So you see, logging a lot of messages about everything during boot up might confuse the user but in the end makes sense to actually find out what is going wrong IF something is going wrong, but there is no easy answer and one has to find out on a case by case base.