Acceso a Anaconda
Introducción
Anaconda hace un seguimiento de todas sus actividades en las bitácoras. Esto incluye:
-
cambiar pasos de instalación (que corresponden aproximadamente a diferentes pantallas del instalador gráfico)
-
almacena detección y manipulación de dispositivos
-
detección de medios de instalación
-
inicialización de red
-
mensajes del kernel
-
invocaciones a métodos críticos dentro de anaconda
-
invocaciones a programas externos
Acceso al sistema instalado
Durante la instalación las bitácoras son almacenadas en el directorio /tmp
:
Archivos bitácora
/tmp/anaconda.log
-
la información de la instalación usual, particularmente los campos de paso.
/tmp/storage.log
-
análisis y manipulación de dispositivos de almacenaje (discos duros, particiones, LVM, RAID), particionado
/tmp/program.log
-
invoca a programas externos, sus salidas
/tmp/packaging.log
-
DNF mensajes de instalación de paquete
/tmp/syslog
-
mensajes del sistema relativos al hardware
Ciertos mensajes de bitácora son también escritos a los terminales:
Dispositivos TTL
/dev/tty3
-
los mensajes desde
anaconda.log
,storage.log
ypackaging.log
. /dev/tty4
-
lo mismo que
syslog
/dev/tty5
-
stdout y stderr desde programas externos
tty3
and 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
-
bitácora del proceso de instalación de paquete.
/mnt/sysimage/root/install.log.syslog
-
los mensajes desde chroot de instalación con bitácora realizada a través del syslog del sistema.
Principalmente información sobre usuarios y grupos creados durante la instalación de paquetes de dnf.
Formato de bitácora
En archivos el formato de mensajes de bitácora es como sigue:
H:M:S,ms LOGLEVEL facility:message
donde:
-
H:M:S
es la marca de tiempo del mensaje -
ms
es la parte en milisegundos de la marca de tiempo. No que esto usualmente se convertirá en una bitácora de sistema syslog remota. -
LOGLEVEL
is 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:-
DEBUG
-
INFO
-
WARN
-
ERR
-
CRIT
-
-
facility
is the program or component that created the message. Could be for instancekernel
,anaconda
,storage
or similar. -
message
es el mismo mensaje de la bitácora.
Para las bitácoras en ejecución en terminales, el formato simple es:
LOGLEVEL facility:message
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. |
Qué es acceder remotamente
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. All anaconda tracebacks (/tmp/anaconda-tb-xyz) are concatenated into a single file /tmp/anaconda-tb-all.log and then transferred. Also, /tmp/x.log is transferred.
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.
Configuración
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 /home/akozumpl/remote_inst/10.34.33.221/
, e.g. /home/akozumpl/remote_inst/10.34.33.221/anaconda.log
.
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.
* anaconda.log, storage.log
and program.log
have the name embedded in them as programname
.
* syslog
messages are coming in from kernel and daemon facilities, just like they do on the installed system
* install.log.syslog
made during package installation is logged as a special sysimage
hostname.
Run 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.
Bitácora remota por medio de 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.
Configuración de Bitácora Remota
Anaconda will be forwarding logs over virtio automatically if it is able to find the port /dev/virtio-ports/org.fedoraproject.anaconda.log.0"
. This is port is created using a libvirt XML directive that wires it to a TCP socket on the host’s side. It’s then possible to read the logs from there directly, or make an rsyslog instance to parse them and file them into respective files. See the ascii chart below for the whole ensemble:
Anaconda--->rsyslog(guest)--->virtio(guest char device)--->kvm hypervisor--->virtio(TCP socket) | v forwarded log files<---rsyslog(host)
Instrucciones paso a paso para establecer todo así:
-
Crea una máquina virtual de pruebas, p.e. utilizando Gestor Virtual </li>
-
Add the virtio-serial port to your virtual machine, direct it to the TCP port 6080 on the host. Start by editing the guest configuration:`virsh edit <machine name>`
-
In the guest editor, add following information into the
<devices>
section:
<channel type='tcp'> <source mode='connect' host='127.0.0.1' service='6080'/> <target type='virtio' name='org.fedoraproject.anaconda.log.0'/> </channel>
-
Start the listening rsyslogd process on the host, using the
analog
script described [[#Remote_logging_via_TCP|above]]:
eval `analog -p 6080 -o rsyslogd.conf -s /home/akozumpl/remote_inst`
-
Inicie la máquina virtual.
-
Continue with the installation. Immediately after the Anaconda greeting is displayed the log messages will appear in the directory given to
analog
script, in the127.0.0.1
subdirectory.
Known issues and troubleshooting
-
works in libvirt>=0.8.2
-
chroot syslog messages from
/mnt/sysimage/root/install.log.syslog
are not forwarded. -
it is not possible to start the machine unless something is listening on the TCP port where virtio-serial is connected.
-
if you want to test that the virtio connection is working, instead of using analog and rsyslog just let a netcat utility listen on the given port, e.g.
nc -l 0.0.0.0 6080
. You should start seeing raw logs in the terminal once the guest machine starts booting. -
if both remote TCP logging via
syslog=
and remote virtio logging viavirtiolog=
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.
Las bitácoras de Anaconda en el sistema en ejecución
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:
Nombre durante la instalación | Nombre en el destino del sistema |
---|---|
|
|
|
|
|
|
|
|
Logging tips
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 anaconda.log
, storage.log
and syslog
.
If you are on a KVM virtual machine and there’s no scp available (stage1), you can (after setting up the network if not up already) redirect to a special tcp file, on host:
$ nc -l 4444 > syslog.log
en invitado:
$ ifconfig eth0 10.0.2.10/24 up
$ grep "" /tmp/syslog > /dev/tcp/10.0.2.2/4444
Want to help? Learn how to contribute to Fedora Docs ›