Bug 151238

This is a result of the removal of initlog; this should probably be relnoted.

Oh. How do I get the error to log the bug then?

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.

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

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.
Reopening.

initlog is included; it is not called by default, however, so boot.log will
still be empty.

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?

Obsolete now we have auditd? Can /var/log/boot.log be removed?

auditd isn't really a replacement.

Oh okay. Let's keep it open then! :)

The missing boot.log is getting some discussion on FC list now that people
upgraded and installed FC4. Any way to activate initlog now?

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.

Changing priority to high since patch is included.

Setting release to FC4 from FC4test1

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.

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.

>(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?

Not for F7 at this point in the cycle, no.

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

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
/etc/resolv.conf

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.

Created attachment 157440 [details]
copy of /var/log/boot.log

Created attachment 157441 [details]
copy of /var/log/boot.log.1

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.

> so let's have boot.log back
> until the magic replacement returns.

Full ACK!

Adding a comment, so that someone from RH can wake up.

*** Bug 163461 has been marked as a duplicate of this bug. ***

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
people.

So you mean there is no way in F8 yet too ?

*THIS NEEDS FIXING*
I can hardly believe what I just read...

Ditto.

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

Could the person(s) responsible for this bug please explain the status of this
bug? What is the technical reason?

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. 

(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

>  "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!!!!

Are there any news regarding Fedora 9?

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
cycle,
since there is no reason to stay with a company that uses such tactics.

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

You people missed Bug 163461, which is a duplicate and contains advice on
getting back to the status quo ante
https://bugzilla.redhat.com/show_bug.cgi?id=163461#c5

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.

http://download.opensuse.org/distribution is where I switched to long time ago..

Why, so WE missed, and someone obviously missed the "mark as duplicate" button. 

It's been marked duplicate in Comment #25 and advertised by me in Comment #31 as
well as Comment #37

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.

I have a non-empty boot.log in rawhide.. fixed?

For rawhide, yes. Needs some other minor fixes to make sure it's always on, etc. It's solved with plymouth.

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.

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:

#!/bin/bash
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.

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.

Mark, Justin... this is a Fedora bug, not a RHEL bug.

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
  #fi
  [ "$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
  fi
  [ "$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

(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.

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...

Thanks.

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.

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).

It doesn't work on RHEL 5.5 we are running currently... Thanks.

The problem is back in RHEL 5.6...

-- Craig

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

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.