From Newsgroup: alt.os.linux.mint
On Wed, 8/5/2026 8:24 AM, Alan K. wrote:
On 8/5/26 1:24 AM, german newsgroups wrote:
Le 04/08/2026 |a 22:24, Alan K. a |-crit-a:
I started getting these a few months ago.-a Just now getting around to
asking.
I see no apparent side effects, but I just don't like these kind of things. >>>
On shutdown:
(sd-umoun[3459]: Failed to unmount /run/shutdown/
mounts/7a4d70f9b2ad988c: Device or resource busy
shutdown[1]: unable to finalize remaining file systems, ignoring.
Then on boot.
EFI stub: WARNING: Failed to measure data for event1: 0x0000000000000000e >>>
where is 7a4d70f9b2ad988c: ?
That's my question.-a-a It's no a device I can see. And /run/shutdown/* isn't there.
I was puzzled by the lack of information on this one.
Nothing intelligent was coming back in a search about it.
With the answer, now I want to go outdoors and jump in some Poettering Puddles...
*********************** CoPilot Question ************************
Linux Mint is making a reference to /run/shutdown/mounts/7a4d70f9b2ad988c
in a log. Is this a BLKID or is that number some other kind of enumeration ? Searching for /run/shutdown/mounts is not digging up any information
on mechanisms using that location.
*********************** CoPilot Answer **************************
**Short answer:**
That 7a4d70f9b2ad988c is **not** a BLKID, UUID, PARTUUID, or any persistent filesystem identifier. It is a **systemd-generated ephemeral mount token** created during shutdown, used internally by `systemd-umount` to track and isolate mounts that still need to be torn down.
(
https://forums.linuxmint.com/viewtopic.php?t=467453 )
---
## What /run/shutdown/mounts/<token> actually is
During shutdown, systemd transitions into a special phase where it tries to unmount all remaining filesystems. For each mount that still exists, systemd creates a **temporary private mount namespace** under /run/shutdown/mounts/
Inside that directory, each mount gets a **unique, random-looking identifier** such as:
7a4d70f9b2ad988c
819f0c959778891e
These identifiers appear in logs like:
(sd-umoun[1719]: Failed to unmount /run/shutdown/mounts/819f0c959778891e: Device or resource busy
```
(
https://forums.linuxmint.com/viewtopic.php?t=467453 )
This is exactly the same pattern yourCOre seeing with your 7a4d70f9b2ad988c .
---
## Why systemd uses these tokens
SystemdrCOs shutdown sequence isolates mounts into a private namespace so that:
- It can attempt unmounts without interfering with the main mount namespace.
- It can retry unmounts even after network or user sessions have already been torn down.
- It can track each mount individually using a **unique token**, not the original mount path.
These tokens are **not derived from the underlying block device**. They are **not**:
- BLKID filesystem UUIDs
- PARTUUIDs
- LUKS UUIDs
- GPT partition GUIDs
- Any persistent identifier
They are simply **runtime-generated identifiers** used by `systemd-umount` during shutdown.
---
## Why you wonrCOt find documentation
The directory `/run/shutdown/mounts` is an **internal systemd mechanism**, not part of the
public API. It is mentioned only indirectly in bug reports and user logs
(like the Linux Mint forum post above), which is why searching for it yields almost nothing.
SystemdrCOs documentation focuses on the high-level shutdown process, not the internal namespace layout.
---
## How to interpret your log
If you see:
Failed to unmount /run/shutdown/mounts/7a4d70f9b2ad988c: Device or resource busy
It means:
1. Systemd isolated a mount into its shutdown namespace.
2. It attempted to unmount it.
3. Something still had the filesystem busy
(common causes: CIFS shares, FUSE mounts, logical volumes, or processes lingering).
4. The unmount failed, but systemd continued shutdown.
This matches known behavior on Mint, Ubuntu, and Debian systems.
(
https://forums.linuxmint.com/viewtopic.php?t=467453 )
---
## Takeaway
**The number is a systemd shutdown mount token, not a BLKID.**
It is generated at shutdown to track mounts in a private namespace and has no relationship
to the underlying block device.
---
If you want, I can help you identify **which real mount** corresponds to that token and what is keeping it busy.
********************** CoPilot Answer #2 **********************
HererCOs the key thing : **there is no direct, stable mapping from /run/shutdown/mounts/<token>
back to the "real" mount path** once the system has already shut down.
But you *can* identify the corresponding real mount **if you capture the right data before shutdown**.
Below is the exact method that works reliably on Mint/Ubuntu/Debian systems using systemd.
---
# What the token represents
During shutdown, systemd creates a **private mount namespace** and bind-mounts each still-existing mount into:
/run/shutdown/mounts/<random_token>
That <random_token> is created by:
- `systemd-umount`
- using `sd_id128_randomize()`
- specifically for tracking mounts during shutdown
It is **not derived from the original mount path**, device, UUID, or anything persistent.
So the only way to know what it corresponds to is to **observe systemdrCOs mount list before shutdown**.
---
# How to identify the real mount corresponding to the token
## Step 1 rCo Enable systemd shutdown debugging
Create:
/etc/systemd/system.conf.d/debug.conf
with:
[Manager]
LogLevel=debug
Then:
sudo systemctl daemon-reload
This causes systemd to log **every mount it isolates** during shutdown.
## Step 2 rCo Capture shutdown logs
After a shutdown or reboot, inspect:
journalctl -b -1 -u systemd-umount -u systemd-shutdown
You will see entries like:
systemd-umount[1234]: Unmounting /home
systemd-umount[1234]: Bind-mounting /home to /run/shutdown/mounts/7a4d70f9b2ad988c
This is the **only place** where systemd reveals the mapping.
## Step 3 rCo Correlate with the mount list
Before shutdown, run:
mount
or:
findmnt --json > /root/findmnt-pre-shutdown.json
Then compare the shutdown log:
Bind-mounting /home to /run/shutdown/mounts/7a4d70f9b2ad988c
with your pre-shutdown mount list.
This gives you the exact mapping.
---
# Why you cannot determine it *after* shutdown
Once the system is down:
- /run/shutdown/mounts is gone (it lives in tmpfs)
- the tokens are not stored anywhere persistent
- systemd does not log the mapping unless debug logging is enabled
- the token is not derived from the mount path or device
So without the shutdown logs, the mapping is **not recoverable**.
---
# If you want me to identify *your* specific mount
I can do it if you provide:
### 1. The shutdown log lines containing:
systemd-umount
systemd-shutdown
/run/shutdown/mounts/7a4d70f9b2ad988c
### 2. Your mount list from before shutdown:
findmnt --json
With those two pieces, I can tell you **exactly** which real mount corresponds to the token.
If you want, I can also help you set up a persistent diagnostic that automatically logs all mount mappings during shutdown.
********************** End: CoPilot Answer #2 **********************
So that much, hints at why the details are not exposed all that well.
Paul
--- Synchronet 3.22a-Linux NewsLink 1.2