ArunNetworkingPro
😴

Linux+ Break Room · Case 06

The server that won't wake up

It takes forever to wake, and when it does, things are only half there.

Something happened while the server was installing things. A package is stuck halfway, too scared to finish. A harmless network module has been banned from ever loading. Every boot, something sleepwalks for 25 seconds before anyone else may start. And the boot menu stares at you for half a minute before it even begins. Wake it up properly.

Case 06 of 10System managementTroubleshootingNeeds sudo

⚠️ This case needs sudo

Get the case

Rule 4: read it before you run it, less breakroom-mission-06.sh. The top of the file lists everything it creates and how --clean removes it.

curl -O https://arunnetworkingpro.com/labs/breakroom-mission-06.sh
sudo bash breakroom-mission-06.sh

At any point, ask the house how many ghosts are left:

sudo bash breakroom-mission-06.sh --check

Part A: the half-installed package

A1

Find what's stuck

Which package isn't fully installed, and what does its status say?

Hint

dpkg -l lists packages; healthy ones start with ii. dpkg -l | grep -v '^ii' shows the odd ones out. sudo dpkg --audit explains what's wrong with them.

A2

Let it finish

Make the package finish installing, and find out what it installed.

Hint

While it's stuck, apt install of anything else will complain too: that's part of the haunting. sudo dpkg --configure -a retries every half-configured package and shows why it fails. The error names a missing file: create it (anything inside). Then dpkg -L breakroom-lantern lists its files, and dpkg -S /usr/bin/breakroom-lantern goes the other way: which package owns this file?

Part B: the banned module

B1

It won't load

sudo modprobe dummy

Find who banned it and lift the ban. Then load it and prove it's in the kernel.

Hint

modprobe reads rules from /etc/modprobe.d/. grep -r dummy /etc/modprobe.d/. blacklist stops automatic loading; install dummy /bin/false replaces the load with a command that always fails, so even a manual modprobe is refused. Afterwards: lsmod | grep dummy and modinfo dummy.

Part C: the slow wake-up

C1

Reboot and gather evidence

sudo reboot

Watch the boot. Once you're back in, find out how long startup took, and who made it slow.

Hint

systemd-analyze gives the total. systemd-analyze blame ranks units by how long they took. systemd-analyze critical-chain shows who waited for whom.

C2

Send the sleepwalker back to bed

Stop the slow service from running at boot.

Hint

It's at the top of blame. systemctl cat shows what it does, and sudo systemctl disable keeps it out of the boot.

C3

The staring boot menu

Why does the GRUB menu wait 30 seconds? Get rid of the 30-second setting. (Machines without GRUB skip this.)

Hint

GRUB settings live in /etc/default/grub and /etc/default/grub.d/*.cfg, read in order, so later files win. grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/. Changes only take effect after sudo update-grub rebuilds /boot/grub/grub.cfg.

✅ How you know you won

sudo bash breakroom-mission-06.sh --check says Verdict: 5/5. It wasn't a curse, just Linux. The server is awake. Case closed.

Answer key (no peeking until you've tried)

A1: breakroom-lantern, status iF (installed, half-configured). A2: its postinst needs /etc/breakroom-06/lantern.conf: sudo mkdir -p /etc/breakroom-06, create the file, sudo dpkg --configure -a. B1: /etc/modprobe.d/breakroom-06.conf has blacklist dummy and install dummy /bin/false. Delete it, then sudo modprobe dummy. C1: systemd-analyze blame puts breakroom-06-sleepwalker.service at the top with about 25 s. C2: sudo systemctl disable breakroom-06-sleepwalker. C3: /etc/default/grub.d/99-breakroom-06.cfg sets GRUB_TIMEOUT=30. Delete the file (or set a small number), then sudo update-grub.

💥 Let it haunt you again

Run the script again. The haunting starts over, fresh:

sudo bash breakroom-mission-06.sh

Now do it without the hints. And when you're done for good: sudo bash breakroom-mission-06.sh --clean.

🧠 The ghost, explained

Verdict: not a ghost. The half-asleep server was a package script that failed, a modprobe rule, a slow unit and a GRUB drop-in.

Packages install in two steps. First the files are unpacked, then the package's own scripts configure it. If a script fails, the files are there but the package is "half-configured" (iF), and dpkg keeps retrying it. Fix the cause, then dpkg --configure -a. On Red Hat, rpm -qa and dnf do the same job as dpkg -l and apt.

Kernel modules are drivers you can load and unload. lsmod lists what's loaded, modinfo describes one, modprobe loads it with its dependencies. Files in /etc/modprobe.d/ can pass options, blacklist a module, or replace the load command entirely.

systemd keeps a stopwatch on every boot. systemd-analyze blame is the quickest way to find the slow part, and critical-chain tells you if it actually delayed anything.

GRUB reads a recipe, not your settings. /etc/default/grub and its grub.d drop-ins are only ingredients. update-grub (on Red Hat: grub2-mkconfig -o /boot/grub2/grub.cfg) cooks them into the real grub.cfg. Forgetting that step is why "I changed it and nothing happened".

← Case 05 · All cases · Case 07 → · Stuck, or found a better way? Email me

🎉 Got it, thank you!

Your comment just landed in my inbox. I read every one, and I'll reply by email.

🤔 That didn't go through

Something in the form looked off. Check your name, email and comment and try again, or just email me.

🐢 Whoa, slow down

That's a lot of comments in a short time, so the box is taking a breather. Try again later, or email me.

😴 The comment box is napping

My server is taking a quick break, so your comment couldn't be sent. Sorry! Please email me instead.

💬 Leave a comment

Stuck, found a better way, or just built it and want to brag? Tell me. It comes straight to my inbox (nothing is posted publicly), and I'll reply by email.

Your email is only used to reply to you. Never shared, never added to any list.