[arch-general] Where can I find the "boot" log to find out what failed on boot?
Listmates,
Seems like a simple question, but I've searched /var/log and can't find a file that contains the boot history showing all the "fail" messages during boot. For some reason after the latest update, my i686 box showed a half dozen or so "fail" messages. I need to find the log of what died.
The upside to this? This was my i686 box that would no longer start kde after the next-previous set of updates. Now kde4 starts fine again.
Whatever failed can't be that critical because the box is functioning fine, but I still want to find out what failed. If the file is in /var/log, then I just flat missed it. I thought it would be daemons.log, but I found no fail messages.
On Sat, Jul 25, 2009 at 4:49 PM, David C. Rankindrankinatty@suddenlinkmail.com wrote:
Listmates,
Seems like a simple question, but I've searched /var/log and can't find a file that contains the boot history showing all the "fail" messages during boot. For some reason after the latest update, my i686 box showed a half dozen or so "fail" messages. I need to find the log of what died.
The upside to this? This was my i686 box that would no longer start kde after the next-previous set of updates. Now kde4 starts fine again.
Whatever failed can't be that critical because the box is functioning fine, but I still want to find out what failed. If the file is in /var/log, then I just flat missed it. I thought it would be daemons.log, but I found no fail messages.
This might not actually be logged anywhere now that I think about it. To devs- am I wrong, or maybe we should add some syslog foo in here so this stuff is more easily traceable?
I personally disable the VC on tty1 in inittab on all machines so that no console overwrites the boot screen.
-Dan
On Sat, Jul 25, 2009 at 05:29:31PM -0500, Dan McGee wrote:
On Sat, Jul 25, 2009 at 4:49 PM, David C. Rankindrankinatty@suddenlinkmail.com wrote:
Listmates,
Seems like a simple question, but I've searched /var/log and can't find a file that contains the boot history showing all the "fail" messages during boot. For some reason after the latest update, my i686 box showed a half dozen or so "fail" messages. I need to find the log of what died.
The upside to this? This was my i686 box that would no longer start kde after the next-previous set of updates. Now kde4 starts fine again.
Whatever failed can't be that critical because the box is functioning fine, but I still want to find out what failed. If the file is in /var/log, then I just flat missed it. I thought it would be daemons.log, but I found no fail messages.
This might not actually be logged anywhere now that I think about it. To devs- am I wrong, or maybe we should add some syslog foo in here so this stuff is more easily traceable?
I personally disable the VC on tty1 in inittab on all machines so that no console overwrites the boot screen.
-Dan
That's an interesting way to handle that Dan. Personally if I'm troubleshooting this, I add something like "read KEY" to the end of /etc/rc.local so that the boot pauses for a keypress. After I see what I want, I just comment out or remove that line from /etc/rc.local.
Another way would be to remove the string escape that clears the screen from /etc/issue, but IMHO that is quite ugly.
On Sat, Jul 25, 2009 at 5:37 PM, Randy Morrisrandy.morris@archlinux.us wrote:
On Sat, Jul 25, 2009 at 05:29:31PM -0500, Dan McGee wrote:
On Sat, Jul 25, 2009 at 4:49 PM, David C. Rankindrankinatty@suddenlinkmail.com wrote:
Listmates,
Seems like a simple question, but I've searched /var/log and can't find a file that contains the boot history showing all the "fail" messages during boot. For some reason after the latest update, my i686 box showed a half dozen or so "fail" messages. I need to find the log of what died.
The upside to this? This was my i686 box that would no longer start kde after the next-previous set of updates. Now kde4 starts fine again.
Whatever failed can't be that critical because the box is functioning fine, but I still want to find out what failed. If the file is in /var/log, then I just flat missed it. I thought it would be daemons.log, but I found no fail messages.
This might not actually be logged anywhere now that I think about it. To devs- am I wrong, or maybe we should add some syslog foo in here so this stuff is more easily traceable?
I personally disable the VC on tty1 in inittab on all machines so that no console overwrites the boot screen.
-Dan
That's an interesting way to handle that Dan. Personally if I'm troubleshooting this, I add something like "read KEY" to the end of /etc/rc.local so that the boot pauses for a keypress. After I see what I want, I just comment out or remove that line from /etc/rc.local.
Another way would be to remove the string escape that clears the screen from /etc/issue, but IMHO that is quite ugly.
I disable vc/1 on all my machines in inittab as well, and have been doing for over a year now on all my arch installs. It is one of the first things I do after installing, and I just leave it disabled.
On Sat, Jul 25, 2009 at 3:29 PM, Dan McGeedpmcgee@gmail.com wrote:
On Sat, Jul 25, 2009 at 4:49 PM, David C. Rankindrankinatty@suddenlinkmail.com wrote:
Listmates,
Seems like a simple question, but I've searched /var/log and can't find a file that contains the boot history showing all the "fail" messages during boot. For some reason after the latest update, my i686 box showed a half dozen or so "fail" messages. I need to find the log of what died.
The upside to this? This was my i686 box that would no longer start kde after the next-previous set of updates. Now kde4 starts fine again.
Whatever failed can't be that critical because the box is functioning fine, but I still want to find out what failed. If the file is in /var/log, then I just flat missed it. I thought it would be daemons.log, but I found no fail messages.
This might not actually be logged anywhere now that I think about it. To devs- am I wrong, or maybe we should add some syslog foo in here so this stuff is more easily traceable?
I personally disable the VC on tty1 in inittab on all machines so that no console overwrites the boot screen.
Nope, not logged anywhere. Those messages, however, are arch messages. The daemon itself that fails should write its output somewhere.
If you just want a list of what isn't running, you can always look in... hmm whatever the dir is... /var/run/daemons I think, and compare that to rc.conf.
syslogging this is acceptable if someone wants to supply a patch
On Saturday 25 July 2009 08:33:01 pm Aaron Griffin wrote:
On Sat, Jul 25, 2009 at 3:29 PM, Dan McGeedpmcgee@gmail.com wrote:
On Sat, Jul 25, 2009 at 4:49 PM, David C. Rankindrankinatty@suddenlinkmail.com wrote:
Listmates,
Seems like a simple question, but I've searched /var/log and can't find a file that contains the boot history showing all the "fail" messages during boot. For some reason after the latest update, my i686 box showed a half dozen or so "fail" messages. I need to find the log of what died. The upside to this? This was my i686 box that would no longer start kde after the next-previous set of updates. Now kde4 starts fine again. Whatever failed can't be that critical because the box is functioning fine, but I still want to find out what failed. If the file is in /var/log, then I just flat missed it. I thought it would be daemons.log, but I found no fail messages.This might not actually be logged anywhere now that I think about it. To devs- am I wrong, or maybe we should add some syslog foo in here so this stuff is more easily traceable?
I personally disable the VC on tty1 in inittab on all machines so that no console overwrites the boot screen.
Nope, not logged anywhere. Those messages, however, are arch messages. The daemon itself that fails should write its output somewhere.
If you just want a list of what isn't running, you can always look in... hmm whatever the dir is... /var/run/daemons I think, and compare that to rc.conf.
syslogging this is acceptable if someone wants to supply a patch
Thanks all,
I found it. For some reason kdm was crapping out. Really strange. Weeks ago, I learned that kdm doesn't belong in the DAEMONS LINE and moved it to inittab. Then for some reason something changed with the 7/22 updates that caused X to respawn too fast. After the last update, the failed messages were from kdm.
After working on it a bit more, I finally arrived at:
x:5:respawn:/opt/kde/bin/kdm -nodaemon
and all seems to be working well now. I need to use kdm for kde3 so I maintain my kdemod3 login capability from the greeter. So far so good with this setup. Anybody else have a better way?
David C. Rankin wrote:
Weeks ago, I learned that kdm doesn't belong in the DAEMONS LINE and moved it to inittab.
? That's always worked fine for me. (At least with both kdm3 and slim.)
Can you elaborate? What's the issue?
DR
On Mon, Jul 27, 2009 at 5:56 PM, David Rosenstrauchdarose@darose.net wrote:
David C. Rankin wrote:
Weeks ago, I learned that kdm doesn't belong in the DAEMONS LINE and moved it to inittab.
? That's always worked fine for me. (At least with both kdm3 and slim.)
Can you elaborate? What's the issue?
DR
archwiki is your friend : http://wiki.archlinux.org/index.php/Adding_a_login_manager_%28KDM,_GDM,_or_X...
Xavier wrote:
On Mon, Jul 27, 2009 at 5:56 PM, David Rosenstrauchdarose@darose.net wrote:
David C. Rankin wrote:
Weeks ago, I learned that kdm doesn't belong in the DAEMONS LINE and moved it to inittab.
? That's always worked fine for me. (At least with both kdm3 and slim.)
Can you elaborate? What's the issue?
DR
archwiki is your friend : http://wiki.archlinux.org/index.php/Adding_a_login_manager_%28KDM,_GDM,_or_X...
"The inittab method is recommended for various reasons, one being that it will allow you to boot directly into framebuffer mode from GRUB. This is an advantage should the graphics driver crash in X, for example, you would not be forced to fix your system from a live cd or through other needlessly complex means.
With the inittab method all you would have to do is to press 'e' for edit at the GRUB prompt and just add:
3
to the end of the 'kernel' line to boot directly into framebuffer mode in order to fix your system/X (This is also described more thoroughly & descriptive below.)"
Hmmm ... still not sure I get what the problem is. Any time I've ever run into a situation where either X or the DM crashes, it leaves me at a console login prompt. So I can just login to the console and fix things from there - no live CD needed.
Incorrect/misleading Wiki page, methinks ...
DR
2009/7/27 David Rosenstrauch darose@darose.net:
With the inittab method all you would have to do is to press 'e' for edit at the GRUB prompt and just add:
Is that pretty much the same as adding "single" to the kernel line? Least that's how I normally do it.
On Mon, Jul 27, 2009 at 19:07, David Rosenstrauchdarose@darose.net wrote:
Xavier wrote:
On Mon, Jul 27, 2009 at 5:56 PM, David Rosenstrauchdarose@darose.net wrote:
David C. Rankin wrote:
Weeks ago, I learned that kdm doesn't belong in the DAEMONS LINE and moved it to inittab.
? That's always worked fine for me. (At least with both kdm3 and slim.)
Can you elaborate? What's the issue?
DR
archwiki is your friend :
http://wiki.archlinux.org/index.php/Adding_a_login_manager_%28KDM,_GDM,_or_X...
"The inittab method is recommended for various reasons, one being that it will allow you to boot directly into framebuffer mode from GRUB. This is an advantage should the graphics driver crash in X, for example, you would not be forced to fix your system from a live cd or through other needlessly complex means.
With the inittab method all you would have to do is to press 'e' for edit at the GRUB prompt and just add:
3
to the end of the 'kernel' line to boot directly into framebuffer mode in order to fix your system/X (This is also described more thoroughly & descriptive below.)"
Hmmm ... still not sure I get what the problem is. Any time I've ever run into a situation where either X or the DM crashes, it leaves me at a console login prompt. So I can just login to the console and fix things from there
- no live CD needed.
Incorrect/misleading Wiki page, methinks ...
Yep, the wiki gives wrong reasoning.
The only advantage of inittab over DAEMONS may be http://wiki.archlinux.org/index.php/Start_X_at_boot#Starting_X_as_preferred_... but some login managers allow automatic login as well (at least GDM does).
On Montag, 27. Juli 2009 18:10 Damien Churchill wrote:
Is that pretty much the same as adding "single" to the kernel line? Least that's how I normally do it.
Runlevel 3 is Multi-User Mode with Networking and do start daemons. See this for a first overview:
http://en.wikipedia.org/wiki/Runlevel
See you, Attila
P.S.: Do you like your keyboard or why do you don't use '1' instead of 'single'.-)
participants (10)
-
Aaron Griffin
-
Attila
-
Damien Churchill
-
Dan McGee
-
David C. Rankin
-
David Rosenstrauch
-
Dwight Schauer
-
Randy Morris
-
Roman Kyrylych
-
Xavier