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.

Sign up for GitHub

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

Jump to bottom

systemd:u-boot: /var/lock and /run/lock usage #3658

Closed
geissonator opened this issue May 4, 2020 · 6 comments
Closed

systemd:u-boot: /var/lock and /run/lock usage #3658

geissonator opened this issue May 4, 2020 · 6 comments

Comments

@geissonator
Copy link
Contributor

Need to look into an upstream change to u-boot that changes fw_setenv/fw_printenv to either create the /var/lock directory when it does not exist or look into alternatives when not available.

This commit was put in as a workaround:
https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/31860

systemd/systemd#15668 was the discussion with systemd on this. In general it seems like the usage of /var/lock should be deprecated.

Need to open up some discussion with upstream u-boot team.
@stale
Copy link

stale bot commented Nov 5, 2020

This issue has been automatically marked as stale because no activity has occurred in the last 6 months. It will be closed if no activity occurs in the next 30 days. If this issue should not be closed please add a comment. Thank you for your understanding and contributions.

@stale stale bot added the stale label Nov 5, 2020
@stale
Copy link

stale bot commented Dec 5, 2020

This issue has been closed because no activity has occurred in the last 7 months. Please reopen if this issue should not have been closed. Thank you for your contributions.

@stale stale bot closed this as completed Dec 5, 2020
@geissonator
Copy link
Contributor Author

This came up recently in discord because of https://gerrit.openbmc.org/c/openbmc/openbmc/+/57952, which removed /var/lock, and caused the original issue documented here. We still need a solution. Just create the directory in the u-boot-fw-utils-aspeed-sdk_2019.04.bb recipe?

@geissonator geissonator reopened this Dec 8, 2022
@stale stale bot removed stale labels Dec 8, 2022
geissonator pushed a commit that referenced this issue Feb 10, 2023
@williamspatrick
meta-phosphor: add phosphor-static-norootfs-init recipe
d91b4b3 
There are two existing recipes for early mounting procedures:
  * preinit-mounts - for obmc-ubi-fs
  * phosphor-mmc-init - for phosphor-mmc

Add one for the static-norootfs image type.  This one is similar to
the preinit-mounts, except for it mounts /var as an overlay to avoid
violating FHS expectations (See #3658 as an example of
why this is problematic).  I did not directly change preinit-mounts and
fix it because there are likely field upgrade issues in doing this for
existing users.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I62ab288c2d139cfecadeb191d576e2753120e123
jamin-aspeed pushed a commit to AspeedTech-BMC/openbmc that referenced this issue Jun 29, 2023
@williamspatrick @LeeTroy
meta-phosphor: add phosphor-static-norootfs-init recipe
d7b37a1 
There are two existing recipes for early mounting procedures:
  * preinit-mounts - for obmc-ubi-fs
  * phosphor-mmc-init - for phosphor-mmc

Add one for the static-norootfs image type.  This one is similar to
the preinit-mounts, except for it mounts /var as an overlay to avoid
violating FHS expectations (See openbmc#3658 as an example of
why this is problematic).  I did not directly change preinit-mounts and
fix it because there are likely field upgrade issues in doing this for
existing users.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I62ab288c2d139cfecadeb191d576e2753120e123
stefanberger pushed a commit to stefanberger/openbmc that referenced this issue Aug 1, 2023
@rfrandse
phosphor-led-manager: downstream srcrev bump 5d5fd051a8..2528508c86 (o…
b5c5890 
…penbmc#3658)

Reed Frandsen (1):
  Merge pull request openbmc#26 from PriyangaRamasamy/lamptest-false-print

Priyanga Ramasamy (2):
  meson:Update meson version to 0.58.0 and more
  Lamp test: Handle false trace getting printed

Change-Id: I62c7d3f355a5480267843581d5aadb9af0f71750
@geissonator
Copy link
Contributor Author

Our Witherspoon system appears to still be using u-boot packages from 2016 so it is not getting the fixes:

So after a dediprog or factory reset, a witherspoon system will not boot correctly with openbmc master. Need to figure out if we can update witherspoon to more recent u-boot.

@williamspatrick
Copy link
Member

@geissonator - Is there any plan here?

@geissonator
Copy link
Contributor Author

No, for now we just have it documented in our process that if you factory reset a witherspoon (running master), you have to manually create /var/lock (similar to what was done in 315698e for emmc). I don't think we're going to do anything else here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@williamspatrick @geissonator