You are not logged in.
Hi, I do understand that when a pacnew file is created, you compare it with the old file and merge the differences. In the latest system upgrade I did, a new rc.conf.pacnew file was created where the main difference was that the line below was removed.
VERBOSE='3'
Pacman told me to add the quiet option to the kernel command line. However I am not sure which file to edit to add that option?
Do I edit the /boot/grub/menu.lst and add the quiet option to the arch kernel as shown below?
# (0) Arch Linux
title Arch Linux
root (hd0,4)
kernel /vmlinuz26 root=/dev/sda6 ro quite
initrd /kernel26.img
Is this correct?
Last edited by krnekhelesh (2011-07-31 11:58:04)
Offline
Yes, apart from the spelling.
Offline
# (0) Arch Linux title Arch Linux root (hd0,4) kernel /vmlinuz26 root=/dev/sda6 ro quite initrd /kernel26.img
My bad...changed it to quiet
Offline
Just a quick question, should quiet also be added to the fallback kernel as well?
Offline
if you want.
if you like seeing the boot process scroll by, then let it be, else add quiet. Its all your preference.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Just a quick question, should quiet also be added to the fallback kernel as well?
Just give it a shot w/ and w/o the 'quiet' boot parameter.
Offline
Thank you Inxsible much appreciated.
Offline
Hi
This doesn't quite work the way I would like it to anymore. q
On two recently updated systems, I am seeing verbose USB connect/disconnect messages being displayed to the console. This is annoying because if I'm editing a file with nano the text appears on the screen. Setting quiet as a kernel parameter isn't appropriate for me so I'd like to keep arch's original behaviour before this initscrip change has been made. USB messages are still displayed with quiet on the kernel command line.
My kernel is rolled with this messages turned off e.g USB_ANNOUNCE_VERBOSE so that I don't see them on the console. I'm happy for them to be logged to dmesg so how can I turn the console messages off? Can I use VERBOSE="X" in rc.conf and what's the value that dmesg -nX used to use? That would work for me.
BTW, I use syslog-ng
Cheers
GregW
Last edited by GregW (2011-08-19 09:23:44)
Offline
you can try loglevel=3 in the kernel line and see if that helps.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
you can try loglevel=3 in the kernel line and see if that helps.
Hey Inxsible. That certainly stops the usb announce messages, thanks. I'll try other integers as it also turns off the kernel decompression messages as well
Thanks again
GregW
Offline
I am assuming that you still want the kernel decompression messages to be seen? if so, that might involve changing some code because the loglevels are basically setup in the code. So if the developer set usb announce and kernel decompression at the same loglevel then you either get both or neither. You know what I mean? it just depends on how much logging you want.
P.S : I haven't looked into the code to know for sure if the usb announce and kernel decompression are at the same loglevel or not. I was just trying to illustrate my point. If they are set at different loglevels, then trying 2,4,5 might yield different results.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
I am assuming that you still want the kernel decompression messages to be seen? if so, that might involve changing some code because the loglevels are basically setup in the code. So if the developer set usb announce and kernel decompression at the same loglevel then you either get both or neither. You know what I mean? it just depends on how much logging you want..
I'm happy(ish) to trade off the lack of kernel decompression messages to prevent the USB announce appearing and based on trials 3 gives this balance.
P.S : I haven't looked into the code to know for sure if the usb announce and kernel decompression are at the same loglevel or not. I was just trying to illustrate my point. If they are set at different loglevels, then trying 2,4,5 might yield different results
I'm using the same kernel so there's no changes there. The changes must be related to the initscript changes or syslog-ng conf changes. I don't know enough to look at the code or confs so I'll leave it as is on the 'affected systems' and use logging on the last system I need to update later tonight.
Thanks again for the help and guidance Inxsible
Cheers
GregW
Offline