Linux Installation and Package Management practice questions

The package version number is not higher than the installed version

Why it fails: Version 2.0 > 1.0.

The local apt cache needs to be cleared with 'apt-get clean'

Why it fails: clean removes .deb files, not the package index.

The 'apt-get update' command did not run successfully due to network issues

Why it fails: Network issues would produce an error message.

apt-get check

Why it fails: Checks for broken dependencies.

apt-cache showpkg

Why it fails: Shows package details, not a list.

dpkg --get-selections

Why it fails: Lists packages with selection state, but can be used; however, not as direct as dpkg -l.

alien -i package.deb

Why it fails: Alien converts to .rpm first.

rpm -i package.deb

Why it fails: rpm does not handle .deb files.

The package is unpacked but not yet configured

Why it fails: 'iU' would indicate unpacked.

The package has been completely purged

Why it fails: 'pn' would indicate purged.

The package is installed and configured

Why it fails: 'ii' would indicate installed and configured.

Download the RPM and install it locally with 'rpm -Uvh monitor-app-2.0.el7.x86_64.rpm'

Why it fails: This bypasses the repository and dependency resolution.

Check the version number in the repository using 'yum info monitor-app' and compare with installed version

Why it fails: If the package is not found, info will also fail.

Run 'yum clean all' and then 'yum update monitor-app' again

Why it fails: Cleaning cache may help if metadata is stale, but the package is not found.

The package was updated to a newer version that no longer includes this file.

Why it fails: An rpm -V 'missing' line means the file recorded in the package database is absent from disk, not that a newer package dropped it; an upgrade would change the package version and typically show a different verification result. It is tempting because upgrades do remove files, but that would appear as a version change, not a missing file.

The file /etc/security/passwd was modified after installation.

Why it fails: Modification changes a file's content, size or checksum, which rpm -V reports with an 'M' or 'S' flag, not 'missing'. The 'missing' flag specifically means the file no longer exists on disk. Modification is tempting because rpm -V exists to detect tampering, but tampering yields different flags.

The package was not installed completely.

Why it fails: An rpm -V 'missing' flag means a file recorded in the package manifest is absent from disk, not that installation failed. Incomplete installation would instead show packages absent from rpm -qa entirely. It tempts because missing files can result from interrupted installs, but the flag itself only reports file-level absence.

Add the universe repository to sources.list and run 'apt update'.

Why it fails: The package already exists in an enabled repository, since apt-cache policy shows a candidate version; adding universe would not raise that candidate to 2.4.41-4ubuntu3.7. It is tempting because universe holds many community packages, and enabling it is a common fix when a package is entirely absent from the configured sources.

Use 'apt dist-upgrade' instead of 'apt upgrade'.

Why it fails: dist-upgrade changes dependency resolution and kernel handling, not which candidate version apt selects; with candidate equal to installed, it offers the same 2.4.41-4ubuntu3.6. It is tempting because dist-upgrade is the standard remedy when held-back packages block an upgrade, which is a different failure mode from a stale candidate.

Run 'apt install <package>' which will force the upgrade.

Why it fails: apt install resolves to the same candidate version shown by apt-cache policy, so it cannot pull 2.4.41-4ubuntu3.7; it would merely report the package as already newest. It is tempting because explicitly naming a package sometimes overrides holds, but here the candidate itself is stale, not the install request.

user: Defines the set of roles that can be accessed

Why it fails: Incorrect — the user component identifies the SELinux user identity, not the set of roles. The role component defines roles.

role: Defines the domain for processes

Why it fails: Incorrect — the role component defines roles, not the domain. The type component defines the domain for processes.

/etc/apt/preferences

Why it fails: /etc/apt/preferences sets package pinning priorities, not repository locations. The repositories themselves are declared in /etc/apt/sources.list and /etc/apt/sources.list.d/. Pinning is tempting because it also lives under /etc/apt and controls which versions APT selects, so it would be the right file when forcing a specific package version.

/etc/apt/sources.list.d/

Why it fails: /etc/apt/sources.list.d/ is a directory holding additional .list files, not the primary file itself; the question asks which file defines repositories. It is tempting because drop-in repository files live there, but the canonical definition is /etc/apt/sources.list, with this directory supplementing it.

/etc/apt/apt.conf

Why it fails: /etc/apt/apt.conf holds APT configuration directives such as proxy settings and caching behaviour, not repository locations, so it cannot define where packages come from. It is tempting because it is APT's main configuration file, and it would be the right place to set options like Acquire::http::Proxy for a system behind a proxy.

yum deplist

Why it fails: This shows dependencies but requires the package to be in a repository, not a local file.

rpm -qlp

Why it fails: This lists files in a package.

rpm -qa

Why it fails: This lists all installed packages.

normal

Why it fails: This is not a valid GRUB command.

linux

Why it fails: This command loads a kernel, but does not boot it; 'boot' is needed after.

initrd

Why it fails: This loads the initial ramdisk, but does not boot.

dpkg -i --force-depends

Why it fails: dpkg -i --force-depends installs a named .deb while ignoring dependency failures, leaving packages unpacked rather than configuring them. It suits forcing a single stubborn package, not repairing the whole system; apt-get -f install is what configures unpacked packages and resolves dependencies.

apt-get autoremove

Why it fails: apt-get autoremove deletes packages installed as dependencies that are no longer required, which can worsen a partial installation by removing needed libraries. It suits routine cleanup after upgrades, not repairing dependencies; apt-get -f install is the command that configures unpacked packages.

apt-get clean

Why it fails: apt-get clean only deletes cached .deb files from /var/cache/apt/archives, freeing disk space; it never touches package state. It is the right choice when the cache is corrupt or full, but it cannot configure unpacked packages or resolve broken dependencies.

/dev/sda3

Why it fails: No such partition exists.

A new partition must be created.

Why it fails: There is already a suitable partition.

/dev/sda1

Why it fails: This is a boot partition, not LVM type, and too small for root.

apt-get hold package

Why it fails: apt-get provides no hold subcommand; holds are managed by dpkg selections or apt-mark, so this fails with an unrecognised command. It is tempting because apt-get is the familiar high-level upgrade tool, and apt-mark hold is the correct modern equivalent for pinning a package against routine upgrades.

dpkg --hold package

Why it fails: dpkg has no --hold flag; holding is set through the selection state, so this command errors rather than marking anything. It is tempting because dpkg is the low-level package tool, and its --set-selections and --get-selections options genuinely manage hold states, but no direct hold switch exists.

echo 'package hold' | dpkg --set-selections

Why it fails: The selection line must read 'package hold' with the package name first; here the literal word 'package' is piped, so dpkg marks a nonexistent package and the real one stays upgradable. It is tempting because piping into dpkg --set-selections is the genuine mechanism for setting hold status.

yum erase apache2

Why it fails: Same as remove, deletes config files.

yum remove apache2

Why it fails: Removes config files as well.

rpm -F apache2

Why it fails: Freshen/upgrade, not removal.

apt-get upgrade apache2

Why it fails: Upgrades to newest, not downgrade.

apt-get --reinstall install apache2

Why it fails: Reinstalls current version.

apt-cache showpkg apache2

Why it fails: Shows versions but does not install.

Use `dpkg --force-depends -i foo.deb` to force installation.

Why it fails: Forcing installation can leave the system with broken packages.

Run `apt-get update` and retry the installation.

Why it fails: Updating the package list does not fix dependency issues.

Manually download `libbar.so.2` and install it using `dpkg -i`.

Why it fails: Manual installation may not resolve all dependencies and is not recommended.

`dpkg --purge apache2`

Why it fails: dpkg --purge deletes the package and its configuration files, directly contradicting the requirement to retain them. It tempts because dpkg operates at the low level and purge is its counterpart to remove, but the correct behaviour here is plain removal, which keeps conffiles.

`apt-get purge apache2`

Why it fails: Purge removes the package together with its configuration files, which is the opposite of what is required. It tempts because purge is the standard command when an administrator wants a completely clean removal with no residual configuration, typically before reinstalling from scratch.

`apt-get autoremove apache2`

Why it fails: Autoremove deletes packages installed automatically as dependencies and are no longer needed; it does not target apache2 itself. It tempts because it tidies orphaned dependencies after a removal, but it leaves the named package and its configuration untouched.

`dpkg --get-selections | grep kernel`

Why it fails: Lists all packages, but grep may match package status lines too, not solely names.

`apt-cache search kernel`

Why it fails: Searches descriptions and names, not just installed packages.

`rpm -qa | grep kernel`

Why it fails: RPM is not used on Debian.

Restore the entire system from a backup taken before the upgrade.

Why it fails: Too drastic and time-consuming; a targeted fix is better.

Downgrade the library to the previous version using 'apt-get install <package>=<oldversion>'.

Why it fails: Downgrading a shared library may cause other updated packages to fail.

Use 'dpkg --force-depends -i' to force installation of the old database binary against the new library.

Why it fails: Force-installing may lead to runtime crashes.