-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Move root filesystem from rootfs to tmpfs #5133
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afbjorklund The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Looks good to me. :) |
@@ -0,0 +1,11 @@ | |||
#!/bin/sh | |||
mkdir /sysroot | |||
mount -t tmpfs -o size=90% tmpfs /sysroot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a comment explaining how you arrived at 90% being the correct choice here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That’s easy, I stole it from tinycore (and boot2docker). 😀
I think it needs some space left, so using 100% won’t work. But we could probably get away with 95% since our VM is twice as big ? Can experiment with it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine. Just mention that you have copied the number from elsewhere then. I was afraid it might have some magical principle to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll stick with 90%, until I know better. Will leave a reference to the original
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! Minor nits, but please feel free to merge once you feel it is ready.
@@ -0,0 +1,11 @@ | |||
#!/bin/sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For future archeologists, do you mind adding a quick comment describing why this file exists, and what it's intent is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
future archeologists hahaha ! love it ! hello future archeologists from 2019 !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Explaining init(1) ?
Or maybe what is the difference between this init and the normal one would be more appropriate. It doesn’t really help that the final /sbin/init
is actually not init but just Lennart (systemd) posing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I for one didn't realize this took the place of the system init, though it makes sense given the location.
It'd be nice to have an explanation of why data is being copied from one directory to another before exec'ing out to another init. =)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Settled for adding a reference to switch_root(8)
DESCRIPTION
switch_root moves already mounted /proc, /dev, /sys and /run to newroot and makes newroot the new root filesystem and starts init process.WARNING: switch_root removes recursively all files and directories on the current root filesystem.
This should also close #4072. Thanks! |
Travis tests have failedHey @afbjorklund, 1st Buildmake test
TravisBuddy Request Identifier: 0cc8f740-c50b-11e9-8712-75d78f9b457f |
@TravisBuddy : Build failed due to #5176 |
Looks like the travis fix may be merged. |
@TravisBuddy sorry it was my fault ! should had pulled upstream |
The docker configuration is determined at runtime, so make it work with both old rootfs and new tmpfs.
It is only intended for compatibility with the old rootfs ISO, and not needed with the new tmpfs ISO.
PR looks good, but I'm concerned about the apparently reliable Gvisor failure:
We'll need to confirm if this issue occurs at master without this PR. UPDATE: opened #5191 |
What's the target release for this? Thanks |
v1.4.0 |
This moves the root filesystem of the ISO, from rootfs to tmpfs.
This allows us to stop having to use
--no-pivot
flag withrunc
.The Docker configuration is flexible enough to work with both...
Thanks to @kfox1111 for suggesting a much easier way to do it.
Issue #3512