Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pid1 fails to start if /tmp doesn't exist #27436

Closed
AdrianVovk opened this issue Apr 27, 2023 · 6 comments · Fixed by #27468
Closed

pid1 fails to start if /tmp doesn't exist #27436

AdrianVovk opened this issue Apr 27, 2023 · 6 comments · Fixed by #27468
Labels
pid1 regression ⚠️ A bug in something that used to work correctly and broke through some recent commit
Milestone

Comments

@AdrianVovk
Copy link
Contributor

systemd version the issue has been seen with

v253.1-0-g6c327d74aa0d350482e82a247d7018559699798d

Used distribution

carbonOS (WIP A/B updates branch)

Linux kernel version used

v6.2.10-0-gcb9384f7deb195360e7cb2a1aee2a31792c4106c

CPU architectures issue was seen on

x86_64

Component

systemd

Expected behaviour you didn't see

  1. systemd should be able to boot with root=tmpfs passed in. w/ v252 this did work, but after upgrading to v253 it stopped. This is because systemd itself started depending on the existence of /tmp during early boot, contrary to the documentation: Safely using /tmp

Both /tmp/ and /var/tmp/ are not necessarily available during early boot, or — if they are available early — are not writable. This means software that is intended to run during early boot (i.e. before basic.target — or more specifically local-fs.target — is up) should not attempt to make use of either

  1. The documentation about generators should be updated to indicate that generators can now rely on having a private /tmp directory (and are sandboxed in general). As far as I can tell, the current documentation does not mention the changes introduced in v253

Unexpected behaviour you saw

When attempting to set up the sandbox for generators, systemd will try to overmount /tmp (so that generators can have a private /tmp directory, as documented in this changelog). However, in this root=tmpfs situation, /tmp does not exist: it's supposed to be created by tmp.mount or (if the unit is disabled) by tmpfiles. Neither of these have executed this early, so the overmounting fails

Steps to reproduce the problem

Boot a system with root=tmpfs (in my case, w/ usrhash=...). When transitioning out of the initramfs, pid1 will crash

Additional program output to the terminal or log subsystem illustrating the issue

systemd[1]: Successfully forked off '(sd-gens)' as PID 455.
(sd-gens)[455]: Failed to overmount /tmp/: No such file or directory
systemd[1]: (sd-gens) failed with exit status 1.
systemd[1]: Failed to fork off sandboxing environment for executing generators: Protocol error
<snip>
[!!!!!!] Failed to start up manager.
@AdrianVovk AdrianVovk added the bug 🐛 Programming errors, that need preferential fixing label Apr 27, 2023
@github-actions github-actions bot added the pid1 label Apr 27, 2023
@AdrianVovk
Copy link
Contributor Author

For the time being, I'm going to try a workaround for my distro: I'll add /tmp to base-filesystem so that it gets created during the transition out of the initramfs. However, I think that this is probably a bad solution to be upstreamed: in the event that tmp.mount is disabled/masked, systemd-tmpfiles would create /tmp as a btrfs subvolume. With my change to base-filesystem, tmp will always exist as a directory before tmpfiles gets to run, and so tmpfiles will never be able to make a subvolume

@poettering
Copy link
Member

hmm, yeah, this is broken in the generator logic.

@keszybz you added this recentl. generators should really long without /tmp being around

@mrc0mmand mrc0mmand added this to the v254 milestone Apr 28, 2023
@mrc0mmand mrc0mmand added regression ⚠️ A bug in something that used to work correctly and broke through some recent commit and removed bug 🐛 Programming errors, that need preferential fixing labels Apr 28, 2023
bluca added a commit to bluca/systemd that referenced this issue Apr 30, 2023
When spawning generators within a sandbox we want a private /tmp, but it
might not exist. Try to create it.
If we can't because the FS is r/o, then gracefully bail out.

Fixes systemd#27436
@bluca
Copy link
Member

bluca commented Apr 30, 2023

The generator logic is fine without the tmpfs around, but it needs the mount point. I guess we can try to create it, and fail gracefully if we can't.

bluca added a commit to bluca/systemd that referenced this issue Apr 30, 2023
When spawning generators within a sandbox we want a private /tmp, but it
might not exist, and on some systems we might be unable to create it
because users want a BTRFS subvolume instead.

Fixes systemd#27436
bluca added a commit to bluca/systemd that referenced this issue May 1, 2023
When spawning generators within a sandbox we want a private /tmp, but it
might not exist, and on some systems we might be unable to create it
because users want a BTRFS subvolume instead.

Fixes systemd#27436
poettering pushed a commit that referenced this issue May 2, 2023
When spawning generators within a sandbox we want a private /tmp, but it
might not exist, and on some systems we might be unable to create it
because users want a BTRFS subvolume instead.

Fixes #27436
bluca added a commit to bluca/systemd-stable that referenced this issue May 2, 2023
When spawning generators within a sandbox we want a private /tmp, but it
might not exist, and on some systems we might be unable to create it
because users want a BTRFS subvolume instead.

Fixes systemd/systemd#27436

(cherry picked from commit b8fba0c)
bluca added a commit to systemd/systemd-stable that referenced this issue May 2, 2023
When spawning generators within a sandbox we want a private /tmp, but it
might not exist, and on some systems we might be unable to create it
because users want a BTRFS subvolume instead.

Fixes systemd/systemd#27436

(cherry picked from commit b8fba0c)
MichaIng added a commit to MichaIng/DietPi that referenced this issue Jun 25, 2023
- CI | DietPi-Build: Attempt to fix systemd startup in container with systemd v253: systemd/systemd#27436
MichaIng added a commit to MichaIng/DietPi that referenced this issue Jun 25, 2023
- CI | DietPi-Build: Attempt to fix systemd startup in container with systemd v253: systemd/systemd#27436
@arief-ametek
Copy link

Hi, I am facing a similar error but not /tmp dir missing, please see the log below and give your suggestions for a fix.

[ 3.288858] Waiting for root device /dev/mmcblk1p2...
[ 3.369812] mmc1: host does not support reading read-only switch, assuming write-enable
[ 3.402548] mmc1: new ultra high speed SDR104 SDHC card at address aaaa
[ 3.409611] mmcblk1: mmc1:aaaa SC16G 14.8 GiB
[ 3.418639] mmcblk1: p1 p2 p3 p4
[ 3.527885] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Quota mode: none.
[ 3.536499] VFS: Mounted root (ext4 filesystem) on device 179:98.
[ 3.545527] devtmpfs: mounted
[ 3.549517] Freeing unused kernel memory: 3328K
[ 3.554156] Run /sbin/init as init process
[ 3.769457] systemd[1]: System time before build time, advancing clock.
[ 3.810635] systemd[1]: systemd 253.1^ running in system mode (+PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK +SECCOMP -GCRYPT -GNUTLS -OPENSSL +ACL +BLKID -CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC +KMOD -)
[ 3.842422] systemd[1]: Detected architecture arm64.

Welcome to NXP i.MX Release Distro 6.1-mickledore (mickledore)!

[ 3.918824] systemd[1]: Hostname set to .
[ 3.933326] systemd[1]: Initializing machine ID from random generator.
[ 3.989534] systemd[1]: Failed to fork off sandboxing environment for executing generators: Protocol error
[!!!!!!] Failed to start up manager.
[ 4.034825] systemd[1]: Freezing execution.
[ 13.283830] platform sound-bt-sco: deferred probe pending
[ 105.990445] random: crng init done
[ 121.826785] imx-sdma 30bd0000.dma-controller: external firmware not found, using ROM firmware
[ 121.835390] imx-sdma 30e10000.dma-controller: external firmware not found, using ROM firmware

@DaanDeMeyer
Copy link
Contributor

Please open a new issue instead

@arief-ametek
Copy link

OK sure .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pid1 regression ⚠️ A bug in something that used to work correctly and broke through some recent commit
Development

Successfully merging a pull request may close this issue.

6 participants