The goal of this post is to demonstrate debugging techniques in Debian/Ubuntu related to "finding the source" in the system configuration file.
Test example: after long trials with the tar.gz copy of the installed OS and after its recovery and updates, we receive the message:
update-initramfs: Generating /boot/initrd.img-4.15.0-54-generic
W: initramfs-tools configuration sets RESUME=/dev/mapper/U1563304817I0-swap
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/foobar-swap)
I: Set the RESUME variable to override this.Goal: to understand where this value (U1563304817I0) came from and how to change it properly. This is the first random example, not particularly interesting in itself, but convenient for demonstrating practical methods in Linux..
Step number 1: Where did RESUME come from?
# cd /etc
# grep -r RESUME
initramfs-tools/conf.d/resume:RESUME=/dev/mapper/U1563304817I0-swapWe recursively (-r) search for mentions of this variable in the /etc directory (where most configs are located). We find a conf.d snippet that is explicitly used by the initramfs-tools package.
Where did this snippet come from?
There are three possibilities:
- A magical artifact (someone placed it and forgot about it)
- Configuration from the package
- Configuration generated by some script from system packages
Checking option #2 (as the simplest):
dpkg -S initramfs-tools/conf.d/resume
dpkg-query: no path found matching pattern *initramfs-tools/conf.d/resume*dpkg -S allows us to search through the database of installed files and find out to which package the file belongs. Here is an example of a successful search:
dpkg -S resolv.conf
manpages: /usr/share/man/man5/resolv.conf.5.gz
systemd: /lib/systemd/resolv.confReturning to our task: the file initramfs-tools/conf.d/resume is not installed in the system from the package. Could it be generated in the postinst/preinst script of the package? Let's check version #3.
# cd /var/lib/dpkg/info/
# grep -r initramfs-tools/conf.d/resume *
initramfs-tools-core.postrm: rm -f /etc/initramfs-tools/conf.d/resumeIn the directory /var/lib/dpkg/info/ contains unpacked versions of all "metafiles" of packages (installation/removal scripts, package descriptions, etc.). Surprisingly, this file is removed in postrm (during the removal) of the initramfs-tools-core package. Let's look at the content of its postinst... Nothing related to the conf.d directory.
Let's take a look at the files included in the package initramfs-tools-core.
# dpkg -L initramfs-tools-core
...
/usr/share/initramfs-tools/hooks/resume
...The command dpkg -L allows us to see all the files that exist in the system from the specified package. I highlighted an interesting file for study. Examining the file shows how this variable is used, but does not answer where it comes from.
debconf
It turns out this is someone's artifact. Whose? Before diving into the installer, let's take a look at another important Debian infrastructure — the answers to questions. Every time a package asks a question, and in many cases when it does not ask but uses the default option, both the question and answer are recorded in a special database in Debian called debconf. We can look at the answer database (and even set them before installing the package — debconf-set-selections), for this we will need the utility debconf-get-selections from the debconf-utils. Unfortunately, nothing interesting was found: (debconf-get-selections | grep -i resume returned empty).
debian-installer
The installer has its own answer database: /var/log/installer/cdebconf/questions.dat. Unfortunately, there is also not a word about our resume.
However, nearby there are logs, including syslog, where the entire installation log is recorded. It mentions the package base-installer, and at its we can see a link to the sources.
Inside, we easily find the answer to our question:
resume="$(mapdevfs "$resume_devfs")"; then
...
if [ "$do_initrd" = yes ]; then
...
resumeconf=$IT_CONFDIR/resume
....
echo "RESUME=$resume" >> $resumeconfmapdevfs is a utility with a clear purpose, and the function of interest to us is get_resume_partition, which reads /proc/swaps and selects the largest one. The swap comes from partman.
The answer to our test task: the file is created by the installer in /target at the time of installation, i.e., we are talking about a well-known but still an artifact. In the existing packages in the system, there is no one and nothing that changes this file.
In summary
- dpkg and debconf are the main methods for finding file suppliers.
- searching in /var/lib/dpkg/info allows you to see operations on files at the installation stage.
- The installer can create artifact files that are never changed by anyone (except for the user), and this can be seen in the installer's code.
Source: habr.com
