Is there any way with Yocto to turn down the log level of what’s outputted to the console? Trying to edit configs or do small tests can get frustrating quickly when you have dmesg suddenly deciding to drop a log message or two on your display
Do cat /proc/cmdline and see if console=tty… shows up.
Also you should disable the serial terminal services:
systemctl disable getty@ttyDevice
Regards to yocto, it depends what hardware platform you are using. cmdline.txt is used on raspberry pi to send kernel arguments. If you have that, check if console is specified there.
What i’m trying to do is turn the log level down to stop the flooding of messages in the console (apologies if that wasn’t made clear enough in the initial post), but I haven’t been able to find a way to do that in Yocto at the moment. I initially tried making a bbappend to the generator of the cmdline.txt file in meta-raspberrypi but that would end up stopping mender from generating its images and artifact files for some reason.
just do loglevel=x in cmdline.txt.
CMDLINE_SERIAL=“loglevel=x”
loglevel= All Kernel Messages with a loglevel smaller than the
console loglevel will be printed to the console. It can
also be changed with klogd or other programs. The
loglevels are defined as follows:
0 (KERN_EMERG) system is unusable
1 (KERN_ALERT) action must be taken immediately
2 (KERN_CRIT) critical conditions
3 (KERN_ERR) error conditions
4 (KERN_WARNING) warning conditions
5 (KERN_NOTICE) normal but significant condition
6 (KERN_INFO) informational
7 (KERN_DEBUG) debug-level messages
Yep, that’s what I tried initially, but that would end up stopping mender from generating its images and artifact files for some reason. Looking at meta-mender-raspberrypi it seems they have their own bbappend file for it doing rootfs allocation. Could it be cancelling each other out?
Depends what distro you are on. meta-mender from kirkstone does not mess with cmdline but dunfell does.
How does your CMDLINE look like? And where did you put it ? And what does the resulting cmdline.txt look like in your end? What yocto distro? What mender version? You need to provide some info man
I made a bbappend file for meta-raspberrypi/recipes-bsp/bootfiles/rpi-cmdline.bb in my own layer, which appends " loglevel=1 " to the full cmdline.txt that gets generated. This segment causes mender to stop producing its own artifact files and image, and bitbake will only produce a .wic file. The edit does however, show up when I inspect the cmdline.txt file it generates in the deploy folder.
It’s near enough thes tock cmdline.txt that gets generated , has /dev/mmcblk0p2 as the initial rootfs, doesn’t mention a console argument, has the rootfs type, etc. Don’t have it with me right now but that’s basically what it was. Add loglevel=1 to the end of that when I tried the .bbappend method, which would stop mender from doing its stuff.
The bbappend will always put it last. The issue is mender suddenly not wanting to make its images or artifacts anymore after I make that bbappend. When I get rid of it (and forcefully reimport my layer l) mender goes back to generating its images and artifacts again. I’ve also tried forcefully adding and removing it with the append there, but that still causes meta-mender not to make anything.
I don’t set it in a recipe, I set it in the machine. But that is CMDLINE_SERIAL.
Kinda hard to help if you don’t show me your layer or the error message + log.
The only references to CMDLINE are those, so it shouldn’t break because of mender…
So the best bet is to sneak in your loglevel in one of those variables. Then you can control where it is. I don’t think it’s a good idea to modify CMDLINE direcly unless you make a rpi-cmdline.bbapend.
Remember it’s just a string so either way it will be joined into a whole string as you see.
Just use CMDLINE_SERIAL or something. ?= means that it will set it only if it’s unset.