Bug 151238 - boot.log is empty
Summary: boot.log is empty
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
: 163461 (view as bug list)
Depends On:
Blocks: F10Target 523532
TreeView+ depends on / blocked
Reported: 2005-03-16 10:23 UTC by Need Real Name
Modified: 2014-03-17 02:52 UTC (History)
31 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 523532 (view as bug list)
Last Closed: 2008-08-21 00:25:58 UTC
Type: ---

Attachments (Terms of Use)
the patch that removed it (5.42 KB, patch)
2005-07-18 04:57 UTC, Bill Nottingham
no flags Details | Diff
copy of /var/log/boot.log (1.41 KB, text/plain)
2007-06-20 03:53 UTC, Casual J. Programmer
no flags Details
copy of /var/log/boot.log.1 (1.97 KB, application/octet-stream)
2007-06-20 03:54 UTC, Casual J. Programmer
no flags Details

Description Need Real Name 2005-03-16 10:23:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 Epiphany/1.4.4

Description of problem:
I get errors from two of the initscripts when booting, but cannot post them here because boot.log is empty..

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual Results:  boot.log is empty

Expected Results:  boot.log should contain messages

Additional info:

Comment 1 Bill Nottingham 2005-03-16 17:54:41 UTC
This is a result of the removal of initlog; this should probably be relnoted.

Comment 2 Need Real Name 2005-03-16 23:13:52 UTC
Oh. How do I get the error to log the bug then?

Comment 3 Bill Nottingham 2005-03-17 04:26:02 UTC
No way ATM. initlog was removed as we're planning on moving to something more
flexible and sane, but the code isn't there yet.

Comment 4 David Balažic 2005-04-22 13:41:34 UTC
Shouldn't this big be left open until the new solution is in place ?

Also why not leaving initlog installed until then ?

I also have several failures in initscripts and it is a pain to get the messages
with an empty boot.log

Comment 5 Need Real Name 2005-04-22 14:17:01 UTC
To add to that, I remember a rawhide changelog that specifically stated that
boot.log was coming back until a new solution was put in place.

Comment 6 Bill Nottingham 2005-04-22 14:18:49 UTC
initlog is included; it is not called by default, however, so boot.log will
still be empty.

Comment 7 Need Real Name 2005-04-22 15:26:30 UTC
I see - I think this will surprise a lot of people when FC4 is released.

Is there a reason for it not being called by default?

Comment 8 Need Real Name 2005-07-01 20:06:09 UTC
Obsolete now we have auditd? Can /var/log/boot.log be removed?

Comment 9 Bill Nottingham 2005-07-01 20:15:33 UTC
auditd isn't really a replacement.

Comment 10 Need Real Name 2005-07-01 20:17:31 UTC
Oh okay. Let's keep it open then! :)

Comment 11 Jim Cornette 2005-07-18 02:57:41 UTC
The missing boot.log is getting some discussion on FC list now that people
upgraded and installed FC4. Any way to activate initlog now?

Comment 12 Bill Nottingham 2005-07-18 04:57:44 UTC
Created attachment 116856 [details]
the patch that removed it

Here's a patch of the removals of the initlog support. Patching it with -R
should put it back, modulo any interim changes.

Comment 13 Rahul Sundaram 2005-07-18 21:22:28 UTC
Changing priority to high since patch is included.

Setting release to FC4 from FC4test1

Comment 14 Bill Nottingham 2005-07-18 21:49:34 UTC
Um, *no*. The patch isn't getting added back.

Closing as WONTFIX; this won't be solved in this way, this will be solved with
the new init stuff.

Comment 15 Jeffrey Hutzelman 2007-04-11 16:39:28 UTC
This is idiotic.  Here we are a year and three releases later, and this is
_still_ broken in F7 test3.  Please, if it's not broken, don't break it, and
certainly don't break it with the justification "we think we might want to fix
it another way someday".

Please _FIX_ this bug by restoring the functionality you broke, instead of
asserting that you won't fix it because your new vaporware will be so much
cooler than the working code that was already deployed.

Comment 16 Need Real Name 2007-04-18 17:57:24 UTC
>(In reply to comment #15)
> This is idiotic.
I agree.

Bill Nottingham - this was a HIGH PRIORITY item for FC4.
The promised "something better" never appeared. The boot.log is *needed* for
diagnosing problems. Can you make it work again?

Comment 17 Bill Nottingham 2007-04-18 18:08:53 UTC
Not for F7 at this point in the cycle, no.

Comment 18 brian wood 2007-05-15 22:55:39 UTC
I would like to second that something needs to be put in place to resolve this
issue. It's baffling to me that something like logging boot messages has been
disabled? After all this isn't software from Redmond; the needs of the users
should be met with expedience, not promises of something down the road (which at
this point is nearly a year later!). 

Just my 2 cents

Comment 19 Casual J. Programmer 2007-06-20 03:50:37 UTC
Bug 163461 seems to be a duplicate of this bug.

On Fedora 7 boot.log is not empty, but it only contains one message repeatedly:

Jun 19 00:08:45 workstation6l NET[3751]: /sbin/dhclient-script : updated

How about the rest of the messages ? As this has been first reported on
2005-03-16 05 and it seems to be still not working in Fedora 7 something should
probably be done to fix it.

Comment 20 Casual J. Programmer 2007-06-20 03:53:38 UTC
Created attachment 157440 [details]
copy of /var/log/boot.log

Comment 21 Casual J. Programmer 2007-06-20 03:54:45 UTC
Created attachment 157441 [details]
copy of /var/log/boot.log.1

Comment 22 Need Real Name 2007-08-09 10:26:05 UTC
This was reported FOUR releases ago.

The promised replacement turned out to be snake oil, so let's have boot.log back
until the magic replacement returns.

Comment 23 Mumrel 2007-10-07 12:09:54 UTC
> so let's have boot.log back
> until the magic replacement returns.

Full ACK!

Comment 24 Need Real Name 2007-10-09 16:43:58 UTC
Adding a comment, so that someone from RH can wake up.

Comment 25 Will Woods 2007-10-17 16:21:32 UTC
*** Bug 163461 has been marked as a duplicate of this bug. ***

Comment 26 Jeffrey Hutzelman 2007-10-17 20:22:37 UTC
Um, why was this removed from the F8 blocker list?
This needs to be fixed.  It needed to be fixed several releases ago.

"I've ignored it so long that now it will be hard to fix" really isn't a reason
to decide not to fix a longstanding bug that is causing headaches for a lot of

Comment 27 Adrin Jalali 2007-11-06 09:39:43 UTC
So you mean there is no way in F8 yet too ?

Comment 28 alien_life_form 2007-12-17 09:54:34 UTC
I can hardly believe what I just read...

Comment 29 Mike Hudson 2007-12-18 13:16:33 UTC

I really need this to figure out what is going wrong.

Comment 30 Brian L Scipioni 2008-01-25 09:30:52 UTC
Could the person(s) responsible for this bug please explain the status of this
bug? What is the technical reason?

Comment 31 Casual J. Programmer 2008-01-25 09:47:33 UTC
What is the status for other distributions ? There seems to be a boot log in
openSuSE. If they can do it, why can't RedHat/Fedora ?

Actually https://bugzilla.redhat.com/show_bug.cgi?id=163461 describes how to get
boot log back to work. 

Comment 32 Bill Nottingham 2008-01-25 21:08:09 UTC
(In reply to comment #30)
> Could the person(s) responsible for this bug please explain the status of this
> bug? What is the technical reason?

Status is simply:

- The old code (which did not work well to begin with) now works even worse due
to interim changes.
- As such, it's not a simple reapply-and-go
- There is no workable new code *right now*
- When there is something that works, the bug will be updated, etc.
- In the meantime, as always, taking patches

Comment 33 Fahad Alduraibi 2008-03-04 04:46:10 UTC
>  "initlog was removed as we're planning on moving to something more
flexible and sane".

Can't we have the "insane" for the time being until the sane is ready??

This bug was first created in 2005 and now it is 2008 and still no solution!!!!

Comment 34 Mumrel 2008-05-14 19:41:09 UTC
Are there any news regarding Fedora 9?

Comment 35 Wayne Pollock 2008-05-15 02:52:29 UTC
I was told today that RHEL does have a working boot log.  From the little
information I know, and assuming that is true, it seems to me that RH purposely
refuses to fix the boot log in Fedora in order to encourage sales of RHEL.  So I
doubt this bug will ever be fixed.

I'd love to be convinced this is wrong by someone at Red Hat.  But for now I
plan to move my organization away from all Red Hat products at our next refresh
since there is no reason to stay with a company that uses such tactics.

Comment 36 Adrin Jalali 2008-05-15 04:45:32 UTC
Is there anybody here outside redhat who can fix this problem and place it as a
patch somewhere for public use?

Not only boot.log is empty in fedora 9 but also those few lines in previous
versions are not present

Comment 37 Casual J. Programmer 2008-05-15 06:36:08 UTC
You people missed Bug 163461, which is a duplicate and contains advice on
getting back to the status quo ante

Comment 38 Adrin Jalali 2008-05-15 07:35:48 UTC
Some time ago bug triage system (BugZappers) started to check all the bugs, many
bugs where checked, but this bug is still unchecked and no one is listening to us.

Seems redhat marked this bug as a DANGEROUS one for bugzappers and told them not
to answer or make any attention to it.

You remember this? https://bugzilla.redhat.com/show_bug.cgi?id=163461#c22
I made this suggestion to a kernel driver developer.  Here was
his response (10/2/2007):
"Greg KH" <greg> wrote:
> The kernel already supports this, Red Hat just turns
> it off in their builds.  If you don't like that, don't
> use their kernels :)

I think it's better for redhat to mark this bug as CLOSED, WONT FIX and maybe
close THE WHOLE FEDORA PROJECT and make us sure to switch to another distro.

I think 3 YEARS of remaining such a sucking bug is not acceptable at all.

Comment 39 Casual J. Programmer 2008-05-15 08:10:18 UTC
http://download.opensuse.org/distribution is where I switched to long time ago..

Comment 40 alien_life_form 2008-05-15 08:38:48 UTC
Why, so WE missed, and someone obviously missed the "mark as duplicate" button. 

Comment 41 Casual J. Programmer 2008-05-15 08:49:10 UTC
It's been marked duplicate in Comment #25 and advertised by me in Comment #31 as
well as Comment #37

Comment 42 Bill Nottingham 2008-05-19 21:59:42 UTC
Re: comment #37 - that doesn't actually log anything aside from startup/failure,
which is not what the people want here.

Re: the kernel patch mentioned in #38 - it doesn't actually solve the problem,
*as already commented in this bug*.

Yes, this is still not fixed. Yes, it sucks. Yes, I'm probably to blame. Once we
get a solution that:
- doesn't slow down boot excessively
- doesn't cause issues with SELinux
- actually works sanely
it will be fixed (and the bug will be updated.)

FYI, fixing this with upstart's logging was investigated during Fedora
9, but that was even *more* broken.

Comment 43 Need Real Name 2008-08-18 18:25:16 UTC
I have a non-empty boot.log in rawhide.. fixed?

Comment 44 Bill Nottingham 2008-08-21 00:25:58 UTC
For rawhide, yes. Needs some other minor fixes to make sure it's always on, etc. It's solved with plymouth.

Comment 45 Justin Moninger 2009-02-12 20:46:29 UTC
When will this make it into RHEL5. Its not in 5.3 as far as I can tell and it is still a MAJOR hurdle when debugging a failed start up.

Comment 46 Philippe Latulippe 2009-03-20 18:05:42 UTC
Here's an angry-frustrated quickfix for someone who saw an error message flash by while services were starting:
1) [if using a GUI] On the first console, go into runlevel 3 by doing telinit 3.  
2) Use shift+up/down to scroll through the output.
3) It's likely that the message you saw disappeared.  That's because the log-in prompt eats the last screenful of output.  To work around that, create a bash script that outputs a screen full of whatever to be run as the last thing when you enter runlevel 3, and place it in /etc/rc.3/ as S99vomit, or anything that starts with S99. 
That would be:

echo -e "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"

Don't forget to set execute permissions on it.

Comment 47 Mark Scarton 2010-02-18 08:22:04 UTC
Absolutely unacceptable. I support millions of users a day on RHEL. I can't go and manually poke at servers to see why services aren't starting properly. We're required to run 5.1 due to concurrent platform release requirements, but I run 5.4 on my personal server and this _still_ isn't fixed. It's been five and a half years, folks. If you aren't going to fix this, then declare it so and go lie in your coffin. We have businesses to run.

Comment 48 Bill Nottingham 2010-02-18 16:26:44 UTC
Mark, Justin... this is a Fedora bug, not a RHEL bug.

Comment 49 Robin R. Price II 2010-04-22 16:21:35 UTC
Putting in a workaround for anyone who is curious:

* You need to edit /etc/init.d/functions file. There are 4 points: success, failure, passed, warning.

* before:

# Log that something succeeded
success() {
  #if [ -z "${IN_INITLOG:-}" ]; then
  #   initlog $INITLOG_ARGS -n $0 -s "$1" -e 1
  [ "$BOOTUP" != "verbose" -a -z "${LSB:-}" ] && echo_success
  return 0

* after:

# Log that something succeeded
success() {
  if [ -z "${IN_INITLOG:-}" ]; then
     initlog $INITLOG_ARGS -n $0 -s "$1" -e 1
  [ "$BOOTUP" != "verbose" -a -z "${LSB:-}" ] && echo_success
  return 0

Do this to all four functions.  Note:  Your console will be flooded by each service echoing out: "WARNING: initlog is deprecated and will be removed in a future release" but /var/log/boot.log will be populated.

-- Robin

Comment 50 Need Real Name 2010-04-22 18:04:02 UTC
(In reply to comment #48)
> Mark, Justin... this is a Fedora bug, not a RHEL bug.    

Is this a RHEL6 bug now too? If yes I will open a support ticket.

(In reply to comment #49)
> Putting in a workaround for anyone who is curious:

Thanks for this.

Comment 51 Unix Systems 2010-12-01 05:24:38 UTC
I can see that users has been complaining for last so many years!

Perhaps a simple solution is "NOT to clear the screen" after all services are started during system start-up! Just because of clearing of screen, users simply can't find out which services were started OK & which FAILED...


Comment 52 Mark Scarton 2010-12-01 09:01:39 UTC
Maybe we just need the folks changing the system to *listen* to their customers. It's been almost six years, still no viable solution, and initlog is still spewing these error messages. Imagine: a server OS that won't log messages written to the console during boot. How sad.

Frankly, I'm just sick of it. So I'm voting with my feet and with my pocketbook.

In the long tradition of Unix and Linux, I'll just recreate initlog myself and replace RHEL's version with my own. And next time that my team of engineers needs to choose an OS, I'll consider an alternative to RedHat that is more open to community dialog and input.

Comment 53 Need Real Name 2010-12-01 16:06:23 UTC
Erm guys, this bug is fixed now:

[root@box ~]# ls -l /var/log/boot.log
-rw-r--r--. 1 root root 2554 Dec  1 14:59 /var/log/boot.log
[root@box ~]# tail /var/log/boot.log
Starting HAL daemon:                                       [  OK  ]
Retrigger failed udev events                               [  OK  ]
Starting PC/SC smart card daemon (pcscd):                  [  OK  ]
Starting sshd:                                             [  OK  ]
Starting ntpd:                                             [  OK  ]
Starting sendmail:                                         [  OK  ]
Starting sm-client:                                        [  OK  ]
Starting abrt daemon:                                      [  OK  ]
Starting crond:                                            [  OK  ]
Starting atd:                                              [  OK  ]

If this isn't in RHEL6 then we can complain (I didn't check yet).

Comment 54 Unix Systems 2010-12-01 22:20:42 UTC
It doesn't work on RHEL 5.5 we are running currently... Thanks.

Comment 55 Craig Sayler 2011-02-22 17:38:25 UTC
The problem is back in RHEL 5.6...

-- Craig

Comment 56 Craig Sayler 2011-02-22 17:55:39 UTC
To be exact, The problem still is present in:
Linux xxx 2.6.18-238.1.1.el5 #1 SMP Tue Jan 4 13:32:19 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

-- Craig

Comment 57 Dimitrios Gerasimatos 2011-10-07 01:14:05 UTC
I just want to say that this is still broken in RHEL 5.7.

It is ridiculous that services fail to start and there is no way to tell which ones after the fact (or remotely)!

At least the workaround works, despite the annoying messages.

Note You need to log in before you can comment on or make changes to this bug.