Re: [arch-general] Where can I find the boot log to find out what failed on boot?

[Randy Morris]

On Sat, Jul 25, 2009 at 05:29:31PM -0500, Dan McGee wrote:
 On Sat, Jul 25, 2009 at 4:49 PM, David C.
 Rankindrankina...@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.

Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition

[Randy Morris]

FWIW, I subscribe to this list and have read every post in this thread,
and my system was killed because I didn't fix the file before a reboot
out of my own laziness.  It took me all of 2 minutes to fix my system.
Could it have been prevented? Yes.  Do I really give a shit that I had
to fix it?  No, because it was my own fault.  Had this been one of the
remote machines that I administer I would have been more careful when
doing the upgrade and this wouldn't have happened.

I think of out all the options here, copying the current inittab to
.pacsave and installing a new, working inittab makes the most sense.
Then a user would at least have a chance to boot and read their logs to
see what happened if they even notice there is a problem.