Anaconda tracks all of its activities in logs. This includes:
- changing installation steps (that roughly correspond to different screens in the graphical installer)
- storage devices detection and manipulation
- installation media detection
- network initialization
- kernel messages
- calls to critical methods within anaconda
- calls to external programs
Logging on the installed system
During the installation the logs are stored in the
/tmp/anaconda.log, the general installation information, particularly the step changes.
/tmp/storage.log, storage devices scan and manipulation (hard drives, partitions, LVM, RAID), partitioning
/tmp/program.log, calls to external programs, their output
/tmp/syslog, messages from kernel and external programs (Network Manager)
/tmp/yum.log, yum's internal log
Certain log messages are also written to the terminals:
/dev/tty3, messages from
/dev/tty4, same as
/dev/tty5, stdout and stderr from external programs
tty4 reflect certain log files. Log files always contain messages from all the loglevels, including debug, but the minimal loglevel on the terminals can be controlled with the
loglevel command line option.
There are two other log files created on the target filesystem, in the
/root directory, also accessible at
/mnt/sysimage/root during the installation:
/mnt/sysimage/root/install.log, log of the package installation process.
/mnt/sysimage/root/install.log.syslog, messages from installation chroot logged through the system's syslog. Mostly information about users and groups created during yum's package installation.
In files the format of the log messages is as follows:
H:M:S,ms LOGLEVEL facility:message
H:M:Sis the message timestamp
msis the millisecond part of timestamp. Note that this will usually become zero on a remote syslog.
LOGLEVELis the message loglevel. In theory, because kernel messages are part of anaconda logs, all loglevels that are defined in rsyslog can appear in the logfiles. Anaconda itself will however log only at the following loglevels:
facilityis the program or component that created the message. Could be for instance
messageis the log message itself.
For the logs running in terminals, the format simply is:
Remote logging via TCP
Anaconda supports remote logging handled through the rsyslog daemon running on the installed system. It can be configured to forward its logs through TCP to an arbitrary machine in network that is also running a syslog daemon. This is controlled with the
syslog command line option. Do not forget to enable the port you are running your local syslog daemon on in your firewall.
What is logged remotely
Everything that is logged directly by anaconda should also appear in the remote logs. This includes messages emitted by the loader and the storage subsystem. Log files used by external programs (x.org.log) are currently not transferred to the remote.
The remote logging only works when the installer initializes network. Once network is up, it takes a couple of minutes for rsyslogd to realize this. Rsyslog has a queue for messages that couldn't be forwarded because of inaccessible network and it eventually forwards all of them, in the correct order.
It's up to you how the remote logging daemon is configured, you can for instance log all incoming messages into one file or sort them into directories according to the IP address of the remote system.
The anaconda RPM provides the
analog script, which generates a suitable rsyslogd configuration file based on a couple of install parameters. It is also able to generate a bash command to launch rsyslogd with the generated configuration. Thus you can do from a shell:
$ eval `scripts/analog -p 6080 -s -o ./someconf /home/akozumpl/remote_inst`
This starts an rsyslog daemon that will listen on port 6080. The logs from the remote machine with IP 10.34.33.221 will be stored under
The remote syslog configuration exploits several log message characteristics to be able to sort them into the correct files:
- the IP of the message sender to know which machine generated the message and thud what directory does the message belong to.
program.loghave the name embedded in them as
syslog/code> messages are coming in from kernel and daemon facilities, just like they do on the installed system
- <code>install.log.syslog made during package installation is logged as a special
analog without the
-o option to see how exactly does a fitting configuration file look like. Also notice that it uses the same message format for remote logging as anaconda does, but you can of course modify this to specify any format you want.
- Rsyslog documentation
Remote logging via virtio
QEMU/KVM in Fedora 13 and onwards allows one to create virtual machines with multiple virtio char devices exposed to the guest machine. One such device can be used to forward anaconda logs to the host machine. In that way we can get logs forwarded in real time, as soon the anaconda logging subsystem is initialized (early) and not need to wait for the network to come up. Also, it's the only way to forward the logs in a no-network setup.
In theory it should be enough to start a KVM instance with a serial virtio port, tell anaconda about it and then just read logs from the other end of the channel on the host side with another rsyslogd instance. Unfortunately while qemu conveniently creates a
SOCK_STREAM unix socket on the host's side, the receiving rsyslogd can only accept connections from
SOCK_DGRAM. One possible way to deal with this is to start a socat instance that reads from the virtio endpoint and forwards data to a newly created socket of the correct type. See the lame ascii chart below for the whole ensemble:
Anaconda---->rsyslog(guest)--->virtio(guest char device)--->kvm hypervisor--->virtio(SOCK_STREAM host unix socket) | v forwarded log files<---rsyslog(host)<---SOCK_DGRAM unix socket<---socat
Step by step instructions to set everything up follow:
- start the listening rsyslogd process on the host. The
analogscript described above has a
-uparameter to specify a unix socket:
$ eval `scripts/analog -u /home/akozumpl/virt/socket_rsyslog -s -o ./someconf /home/akozumpl/virt/logs`
- set up a socat to forward between the two socket types:
socat -u UNIX-LISTEN:/home/akozumpl/virt/socket UNIX-SENDTO:/home/akozumpl/virt/socket_rsyslog &
- start the kvm machine with virtio serial setup (details here). The command should include parameters similar to the following:
-device virtio-serial \ -chardev socket,path=/home/akozumpl/virt/socket,id=foo \ -device virtserialport,chardev=foo,name=syslog_forward_port
- pass the name of the port we created to anaconda using the kernel command line
- continue with the installation. Almost immediately after the Anaconda greeting appears the log messages will be appearing in the directory given to
/home/akozumpl/virt/logsin this case).
Known issues and caveats
- messages for
install.log.syslogare not recognized (the hostname information gets lost when forwarding over a socket).
- sometimes messages longer than 1024 characters are split up in two, with the second one not being recognized by the host rsyslogd as the header is missing. This is probably due to the
SOCK_DGRAMsocket type rsyslog requires to read messages from (i.e. there's no way for it to tell how to combine the messages back into one).
- it's unknown whether it's possible to do the virtio chardev configuration of the virt machine through the virt-manager gui. Anyone?
- if both remote TCP logging via
syslog=and remote virtio logging via
virtiolog=are specified on the command line, one has to setup two rsyslogd instances on the server/host to listen to both the connections otherwise the sending rsyslog's queues get full and the forwarding stops.
Anaconda logs on the running system
After every successful installation, anaconda logs are copied into
/var/log on the system you just installed. To avoid name clashes with other log files there, the anaconda logs are renamed:
|Name during installation||Name on the target system|
If you are asked to provide logs for a bugzilla, your best option is switching from the anaconda GUI to tty2 and then use scp to copy the files to your computer, e.g.:
cd /tmp scp anaconda.log aklap:/home/akozumpl/
It is also possible to make a complete dump of a state of running anaconda process (the same dump that is compiled automatically if an unhandled exception occurs). To do this send the main anaconda process SIGUSR2:
kill -USR2 `cat /var/run/anaconda.pid``
This builds a file
/tmp/anaconda-tb-????? that also contains