apt-get update failed in kvm-flavor stage1 #1917
Comments
|
Hmm, looks like this bug: https://bugs.launchpad.net/qemu/+bug/1336794 |
Upgrade lkvm to current master branch to fix a 9pfs bug. Bug details: rkt#1917 Signed-off-by: Arthur Chunqi Li <[email protected]>
|
Hi jonboulle, I dived deep into the lkvm code and found that this bug was fixed by lkvm patch 6d7eeb7a1328fcce82b5783d9e4605bf5e4737dd "kvmtool: set 9p caching mode to support writable mmaps". This patch adds "cache=loose" mount param to 9pfs, which maintains the cache inner Linux VFS. Actually this is just a alternative and trade-off, but according to v9fs official document: I think it's just fit for rkt environment since the rootfs of stage-2 is only used by one pod. Here attached my patch: xelatex@1f145e8 Thanks. |
Upgrade lkvm to current master branch to fix a 9pfs bug. Bug details: rkt#1917 Signed-off-by: Arthur Chunqi Li <[email protected]>
Upgrade lkvm to current master branch to fix a 9pfs bug. Bug details: rkt#1917 Signed-off-by: Arthur Chunqi Li <[email protected]>
Upgrade lkvm to current master branch to fix a 9pfs bug. Bug details: rkt#1917 Signed-off-by: Arthur Chunqi Li <[email protected]>
|
I'm still seeing this: It's not limited to Debian Environment |
|
@jonboulle can you confirm this should be fixed as of CoreOS 1032.0.0, as per details above? This is going to be a blocker for me moving from Docker to rkt, so I'm rather committed to helping diagnose the problem if it has reappeared. |
|
I can reproduce. |
|
In near future we plant to add support for hanging hypervisors (adding qemu) and will look forward on this issue. |
|
sorry, I don't quite follow - is that somehow related or are you just On Fri, May 6, 2016 at 7:57 PM, Piotr Skamruk [email protected]
|
|
Yes, I don't have a time for this at the moment and we want to if this issue show also still under qemu. |
|
Needs more investigation. Moving... |
|
I am also facing this issue when using rkt |
|
Please try kvm flavor from branch proposed in this PR. |
|
I'm bumping this to next release, but I think this would need some further assessment. @jellonek can you please re-target this to a reasonable ETA and find an owner? |
|
This should be resolved by moving to hypervisors barnch, which defaults to qemu. |
|
@jellonek so we don't want to track down the root cause here and see if it can be fixed on lkvm? |
|
@lucab: There is no one longer interested in lkvm. Using qemu solves a lot of pain and adds further possibilities. |
|
@coreos/rkt-kvm-maintainers can anybody of you confirm that this is actually fixed in the QEMU-based stage1-kvm flavor that we plan to transition to? |
|
@lucab No, it's not fixed in QEMU. |
|
@lucab @coreos/rkt-kvm-maintainers of all the KVM bugs, this is the biggest one preventing me from using KVM. I want KVM so I can run user code, and I want package installation available for those users. It's also a pain point when submitting examples for other rkt KVM bugs, because I can't do on-the-fly package installation with Fedora/Debian containers to get the utilities required to show problems. At the moment I can use Alpine with Can we put this on a milestone? |
|
@tjdett @lucab Looking for the previous comments and found the source of the problem. After changing 9p mount caching mode from "mmap" to "loose" problem disappears. For LKVM, there is a patch to set this mode. |
|
could this be related : http://www.spinics.net/lists/stable/msg140096.html ? |
|
Hi. And, I think there is probably more than one 9pfs bug in this area. In intel/cc-oci-runtime#152 you can see we believe there is another related, but subtly different, instance where it is an unlink/ftruncate bug, rather than an unlink/fstat bug - same type of bug (using the name of a file that has been unlinked instead of the handle to that file), but I think through a different code path. |
|
Quick update. It looks like just the qemu patch from qemu-lite as referenced above is enough to fix apt-get. Currently the qemu.mk does not have the ability to apply patches, so I'll graft that into the build system and do significantly more testing. |
|
@grahamwhaley I've added you to the org |
Even though a uid/gid pair are passed over the protocol, they were not being used for chmod'ing files or dirs being created. This surfaced inside /tmp with the S_ISVTX 'sticky' bit set, where all files ended up being owned by root. Fix it by chmod'ing after creation. Fixes rkt#2576 As a side effect, it also seems to solve the remaining problems with 'apt-get update' in lkvk, so also: Fixes rkt#1917
Even though a uid/gid pair are passed over the protocol, they were not being used for chmod'ing files or dirs being created. This surfaced inside /tmp with the S_ISVTX 'sticky' bit set, where all files ended up being owned by root. Fix it by chmod'ing after creation. Fixes rkt#2576 As a side effect, it also seems to solve the remaining problems with 'apt-get update' in lkvk, so also: Fixes rkt#1917
Even though a uid/gid pair are passed over the protocol, they were not being used for chmod'ing files or dirs being created. This surfaced inside /tmp with the S_ISVTX 'sticky' bit set, where all files ended up being owned by root. Fix it by chmod'ing after creation. Fixes rkt#2576 As a side effect, it also seems to solve the remaining problems with 'apt-get update' in lkvm, so also: Fixes rkt#1917
This allows me to use rkt to test ebpf-kprobes without impacting the host kernel. The KVM flavor currently include the kernel version 4.8.6rkt-v1, which is enough for my current needs. tracefs is normally available in /sys/kernel/debug/tracing/ and is necessary for kprobe support. I could test in the following way: ``` sudo ./build-rkt-1.21.0+git/target/bin/rkt \ run --interactive \ --insecure-options=image,all-run \ --dns=8.8.8.8 \ --stage1-path=./build-rkt-1.21.0+git/target/bin/stage1-kvm.aci \ --volume=ebpf,kind=host,source=$GOPATH/src/github.com/kinvolk/gobpf-elf-loader/ \ docker://debian \ --mount=volume=ebpf,target=/ebpf ``` And inside rkt: ``` mount -t tmpfs tmpfs /tmp # workaround rkt#1917 mount -t debugfs debugfs /sys/kernel/debug/ cd /ebpf ./gobpf-elf-loader ./ebpf.o ``` This patch increases the size of stage1-kvm.aci by 5MB (from 43MB to 48MB). Is it acceptable?
This allows me to use rkt to test ebpf-kprobes without impacting the host kernel. The KVM flavor currently includes the kernel version 4.8.6rkt-v1, which is enough for my current needs. tracefs is normally available in /sys/kernel/debug/tracing/ and is necessary for kprobe support. I could test in the following way: ``` sudo ./build-rkt-1.21.0+git/target/bin/rkt \ run --interactive \ --insecure-options=image,all-run \ --dns=8.8.8.8 \ --stage1-path=./build-rkt-1.21.0+git/target/bin/stage1-kvm.aci \ --volume=ebpf,kind=host,source=$GOPATH/src/github.com/kinvolk/gobpf-elf-loader/ \ docker://debian \ --mount=volume=ebpf,target=/ebpf ``` And inside rkt: ``` mount -t tmpfs tmpfs /tmp # workaround rkt#1917 mount -t debugfs debugfs /sys/kernel/debug/ cd /ebpf ./gobpf-elf-loader ./ebpf.o ``` This patch increases the size of stage1-kvm.aci by 5MB (from 43MB to 48MB). Is it acceptable?
This allows me to use rkt to test ebpf-kprobes without impacting the host kernel. The KVM flavor currently includes the kernel version 4.8.6rkt-v1, which is enough for my current needs. tracefs is normally available in /sys/kernel/debug/tracing/ and is necessary for kprobe support. I could test in the following way: ``` sudo ./build-rkt-1.21.0+git/target/bin/rkt \ run --interactive \ --insecure-options=image,all-run \ --dns=8.8.8.8 \ --stage1-path=./build-rkt-1.21.0+git/target/bin/stage1-kvm.aci \ --volume=ebpf,kind=host,source=$GOPATH/src/github.com/kinvolk/gobpf-elf-loader/ \ docker://debian \ --mount=volume=ebpf,target=/ebpf ``` And inside rkt: ``` mount -t tmpfs tmpfs /tmp # workaround rkt#1917 mount -t debugfs debugfs /sys/kernel/debug/ cd /ebpf ./gobpf-elf-loader ./ebpf.o ``` This patch increases the size of stage1-kvm.aci by 5MB (from 43MB to 48MB). Is it acceptable?
|
yay!
…On Thu, Jan 12, 2017 at 5:05 PM Luca Bruno ***@***.***> wrote:
Closed #1917 <#1917> via #3485
<#3485>.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#1917 (comment)>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/ACewNzENf9ft65FeFPGi0QCMwaNKCchvks5rRk6ZgaJpZM4G7AJt>
.
|
Hi there,
I use docker://ubuntu image with stage1-kvm.aci to run a pod. But when I execute "apt-get update" inside, something goes wrong as follows:
Is this a bug? Or I miss some configurations?
Thanks.
The text was updated successfully, but these errors were encountered: