FS#18046 - [initscripts] use bootlogd

Attached to Project: Arch Linux
Opened by david (djg1971) - Wednesday, 27 January 2010, 22:20 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 26 April 2011, 15:50 GMT
Task Type Feature Request
Category Arch Projects
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No

Details

Description:

This is not a request for a package per say (hopefully it's simpler):

What I am requesting is for someone to figure out how to enable a boot log file for Arch systems. This means a recorded text file which contains all of the messages echoed to the screen during the boot process -- the ones that usually go by too fast to make any use of and then are lost forever.

1) No, this functionality is not provided by dmesg.

2) Most distributions have such a feature (eg. redhat, debian, ubuntu...)

3) Some distros accomplish the task via a binary called "bootlogd." Arch (at least my arch64 system) has this already (/sbin/bootlogd), though I have not been able to make it work. I don't know if the issue is simply that I don't know where to place the call to the binary (though I know that inside /etc/rc.sysinit after the call to minilogd is *not* the right place), or something deeper. But still I think it is possible, maybe just by putting the call in the right spot in the right script.

4) The action that results from trying what I did in #3 above (putting /sbin/bootlogd in /etc/rc.sysinit after the call to minilogd) is: After boot-up one finds a zero-size log file in the default location (/var/log/boot). If you then remove the call to bootlogd from the sysinit script, reboot, and look in /var/log/ again, you find that the "boot" file is still there, only now it contains the shutdown informational messages (or at least some of them).

5) On a debian system I believe the feature is provided using bootlogd, however they clearly have some files in place that Arch does not, so I don't know how helpful the following might be: edit the contents of "/etc/default/bootlogd" to read:
# Run bootlogd at startup ?
#BOOTLOGD_ENABLE=No
BOOTLOGD_ENABLE=Yes

6) Regarding the man page "BUGS" section: Arch does have the new-style console device: "There is no standard way to find out the real console device if you have a new-style /dev/console device (major 5, minor 1)" however the behavior I describe in #4 above makes me think that it is still working, just needs to be called from precisely the right location.

Several people replied to my initial post(s) that this would be a desirable feature, so please help if you can.

--> BTW, just checked a debian64 system... /dev/console is exactly the same as on my arch64 system.




Additional info:

As I said, my arch64 system already has /sbin/bootlogd -- just can't seem to make it work.

Steps to reproduce:

See above.
This task depends upon

Closed by  Tom Gundersen (tomegun)
Tuesday, 26 April 2011, 15:50 GMT
Reason for closing:  Implemented
Additional comments about closing:  In git.
Comment by Thomas Bächler (brain0) - Thursday, 28 January 2010, 10:04 GMT
This is a good idea, and I never heard about bootlogd before. If you figure it out, tell me, I won't have time for it in the short-term future.
Comment by Jörg Kriegel (sokoban65) - Tuesday, 02 February 2010, 07:25 GMT
I made a little research on this topic. To make work you have to:

add static device nodes for /dev/ptmx and /dev/tty1 and maybe /dev/ttyS?
mount /dev/pts before running bootlogd. Best is to move it out of /etc/fstab into /etc/rc.sysinit along with the other mounts there after populating /dev with static nodes
start bootlogd as "/sbin/bootlogd -r". Can be done before minilogd is started
kill bootlogd when booting sequence has finished (single and normal)

The output is saved to /var/log/boot. It's no problem when this file is not accessible when bootlogd is started. One problem with the logfile is that they are garbled with bad escape sequence. See my attachment.
Comment by Thomas Bächler (brain0) - Tuesday, 02 February 2010, 08:50 GMT
I found out the same on the weekend. But it stopped logging in the middle of the process for some reason. And the escape sequences are relly annoying in color mode - if it would just pass them to the file as-is it would be fine, but it escapes them further, makes them human-readable.

The error messages are quite useless in bootlogd, so I had to read its source code to find out what was missing. Maybe there's a more advanced version of bootlogd - the current version is from sysvinit which is hardly developed and quite old.
Comment by Jörg Kriegel (sokoban65) - Wednesday, 03 February 2010, 07:25 GMT
For my tests I always stopped bootlogd by hand. So I think your partial log file could be a problem with flushing the buffer to the log file. It seems there is a newer upstream version of sysvinit (2.87dsf) atinitscripts-ng-devel@lists.alioth.debian.org/msg00602.html"> http://www.mail-archive.com/initscripts-ng-devel@lists.alioth.debian.org/msg00602.html. The link to the source is at the bottom. Most other linux distributions are now migrating to upstart or a combination of upstart and sysvinit. Upstart has its own daemon logd that works only in conjunction with the upstart applications. Fedora produces a nice boot log with contains/preserve ansi sequences with logd (you have to watch it with less -r ...).

My conclusions are:

- We should only work on bootlogd if there are no plans to migrate to upstart in the future.
- We can try to find a better version/patches for bootlogd
- We can modify/enhance it and try to submit it upstream with seem to be at Petter Reinholdtsen from debian.

A proper processing of the terminal output would be:

- Parse all ansi and other escapes.
- Drop any useless (color, bold,..) or unknown sequences.
- Process all positioning ansi escapes.
- Simulate terminal word wrapping by inserting line feeds.
- The boot log file would look exactly as archinux in no color mode, but has no escape secuences other than line feed in it.

I think that this would be great especially for headless installations. I am of course willing to help especially on searching/patching/coding on bootlogd itself.

Comment by Søren Poulsen (nikor) - Saturday, 19 February 2011, 20:54 GMT
Patch to initscripts that enables bootlogd during startup.
I have tested it with and without devtmpfs. But it really needs to be review..
Comment by Tom Gundersen (tomegun) - Sunday, 27 March 2011, 18:57 GMT
@Søren: Thanks for the patch. In principle I think this is a nice feature, and I'd like to get it merged. However, we need to sort something out first:

1) I really don't like the static device nodes. Can this somehow be avoided if we only start bootlogd if we are using devtmpfs (maybe just let it silently fail otherwise...)? I think this is a requirement to get it merged. I.e. drop all the mknod stuff.

2) I guess we need to create and mount /dev/pts before udev is started (so before udev can mount create/mount stuff for us), and this you do. This is fine by me, but I suggest we treat /dev/shm in the same way and proceed like this:
2.1) apply <https://github.com/teg/initscripts-arch/commit/b953a32ec16f9c6fc7883a62139f6768845694a4>
2.2) mount /dev/pts (and /dev/shm) as you suggested (maybe we can improve the mount options though to be "mode=620,gid=5,nosuid,noexec" and "mode=1777,nosuid,nodev" respectively)
2.3) if /dev/pts or /dev/shm are in /etc/fstab, then make sure the mount options in fstab take precedence over the default ones we set (maybe a remount will make this happen? I would need to look that up...).

If we can get this working, I suggest we run it by the udev maintainers just in case they have any objections (this should not make a difference for udev, but better safe than sorry).
Comment by Tom Gundersen (tomegun) - Wednesday, 13 April 2011, 09:44 GMT
I made some patches for this here: <https://github.com/teg/initscripts-arch/commits/bootlogd>. Itd be great if someone would try them out. Ill probably push them to the main repo after the next release.

Loading...