You are not logged in.
Pages: 1
Hi, I'm running Arch on a Toshiba laptop with an built-in Broadcom network card. I've installed the correct driver and it works fine after booting, but it displays some error messages during the initial startup. The problem I've having is that it prints them to the console after the screen clears, often when I am in the middle of typing in my username. Here is a picture (sorry for the bad quality and giant size) of how it interrupts the login screen.
http://i.imgur.com/g4Z5Nke.jpg
I am basically looking for a way to redirect the error output so that it doesn't display on the login screen (though if anybody else has a Broadcom network card and found a way to fix the "errors" I would love to hear about it!)
I'm not sure what the relevant configs to post are, here's some related info:
* kernel version 4.12.8-2-ARCH, as seen above
* I'm not using any display manager, just launching startx from my .bashrc file on login. The error is being printed before logging in, so probably not related.
* Here's what is throwing the errors (per "lspci -k"):
07:00.0 Network controller: Broadcom Limited BCM43142 802.11b/g/n (rev 01)
Subsystem: Lite-On Communications Inc Device 6655
Kernel driver in use: wl
Kernel modules: wlI'm using the broadcom-wl-dkms package from the official repository for the driver.
Last edited by timourf (2017-08-27 14:55:03)
Offline
Please don't embed large images into your posts, use thumbnails and/or links.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Ahh thanks, I don't know what I was thinking. Forgot that hyperlinks are a thing ![]()
Offline
This might be a good place to start.
Offline
Thanks! It took some more research, but here's the solution I ended up with (for posterity):
*Edit or create the file /etc/rc.local with the following contents
#!/bin/sh
sudo dmesg -n 1*make it executable
$ sudo chmod+x /etc/rc.local*systemd does not read rc.local files by default, so create a service to run it on startup by creating the file /usr/lib/systemd/system/rc-local.service with the contents
[Unit]
Description=/etc/rc.local Compatibility
ConditionPathExists=/etc/rc.local
[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty1
RemainAfterExit=yes
SysVStartPriority=99
[Install]
WantedBy=multi-user.target*create a link to it
$ sudo ln -s /usr/lib/systemd/system/rc-local.service /etc/systemd/system/multi-user.target.wants/rc-local.service*enable it with systemd
$ sudo systemctl enable rc-local.serviceOffline
A few issues with your post...
You don't need sudo in your rc.local script as it's already being run as root.
The symlinking step isn't needed, this is exactly what systemctl enable does.
However, all of this is irrelevant as the correct solution is to instead add the proper loglevel to your kernel parameters...
https://wiki.archlinux.org/index.php/Silent_boot
Last edited by Slithery (2017-08-27 15:12:08)
Offline
It's always good to have more solutions (thanks for your input!), but I fail to see why using kernel parameters is the correct one. Perhaps you could explain? The implementation of the second solution is dependent on what bootloader you use to load the kernel, whereas the first one is more general because it only relies on using systemd.
Offline
OK, maybe correct was a bit to strong a word.
My main issue is that you are resurrecting the rc.local file, which has been depreciated on Arch for several years now. You could have just put dmesg -n 1 as the Exec= line in your service file.
Editing the kernel parameters requires far less editing of system files, therefore IMHO is more KISS than your approach.
Offline
Great, thanks for the info! I guess that's the downside of referencing forum posts from 2012. I'll try out the kernel parameter approach later for fun, it does sound much simpler.
Offline
One more point - Because of the parallel nature of systemd there is no guarantee that your script will be run before the agetty service spawns your TTY. By using kernel parameters you are assured that the loglevel is set correctly before systemd even starts.
Last edited by Slithery (2017-08-27 15:36:20)
Offline
Pages: 1