-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Comments
For the time being, I'm going to try a workaround for my distro: I'll add |
hmm, yeah, this is broken in the generator logic. @keszybz you added this recentl. generators should really long without /tmp being around |
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
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. |
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
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
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
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)
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)
- CI | DietPi-Build: Attempt to fix systemd startup in container with systemd v253: systemd/systemd#27436
- CI | DietPi-Build: Attempt to fix systemd startup in container with systemd v253: systemd/systemd#27436
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... Welcome to NXP i.MX Release Distro 6.1-mickledore (mickledore)! [ 3.918824] systemd[1]: Hostname set to . |
Please open a new issue instead |
OK sure . |
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
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 /tmpUnexpected 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 bytmp.mount
or (if the unit is disabled) by tmpfiles. Neither of these have executed this early, so the overmounting failsSteps to reproduce the problem
Boot a system with
root=tmpfs
(in my case, w/usrhash=...
). When transitioning out of the initramfs, pid1 will crashAdditional program output to the terminal or log subsystem illustrating the issue
The text was updated successfully, but these errors were encountered: