Chroot setup stalls indefinitely |
|||||
Issue descriptionOS: Glinux Rodete I created a copy of the chromiumos repo tree, per go/lab-tools, to run some scripting tests (for crbug:746067). While running the instructions, I found that the $ lab-tools/setup_lab_tools script hangs indefinitely (did not complete over a long weekend). I narrowed it down to this call within lab-tools/finish-update: $ "${CROS_SDK}" --enter -- sudo "${emerge_cmd[@]}" "$@" Output from running cros_sdk --debug: >13:14:52: DEBUG: Cache dir lookup. >13:14:52: DEBUG: Configured cache_dir to '/usr/local/google/home/jkop/shadow_cros/.cache' >13:14:53: DEBUG: Configured cache_dir to '/usr/local/google/home/jkop/shadow_cros/.cache' >13:14:53: DEBUG: Checking if existing chroot image can be mounted. >13:14:53: DEBUG: Used existing device /dev/loop7 for /usr/local/google/home/jkop/shadow_cros/chroot.img >13:14:53: DEBUG: Loopback device is /dev/loop7
,
Sep 7 2017
,
Sep 7 2017
Does the lab-tools setup do anything different from a regular chroot? The chroot setup normally works fine on rodete.
,
Sep 7 2017
I saw this mentioned on the email thread as well, but doing cros_sdk --replace --nouse-image will probably get you a working chroot (unless the lab tools are replacing the chroot themselves).
,
Sep 7 2017
Like mentioned above, after seeing the problem I ran a standard cros_sdk --debug and it had the same problem, so I don't *think* it is something about how lab_tools runs it. cros_sdk --debug --nouse-image ran fine, and the lab_tools command ran correctly after that.
,
Sep 7 2017
I tried to set up lab tools. I wasn't able to get past building matplotlib, but the chroot setup worked fine. Seeing it choose loop7 is also somewhat unusual. Could you paste the output of these commands to see if something is tangled up with the chroot? You'll need to run them with sudo. losetup -a pvs vgs lvs
,
Sep 7 2017
losetup -a /dev/loop1: [65026]:2884320 (/home/jkop/chromiumos/chroot.img (deleted)) /dev/loop6: [65026]:2639361 (/usr/local/google/home/jkop/shadow_cros/chroot.img (deleted)) /dev/loop4: [65025]:1443679 (/tmp/chromite.run_tests.mdmg6i/chromite.testVyFgRy/chroot.img (deleted)) /dev/loop2: [65025]:1443869 (/tmp/chromite.run_tests.Th7fLj/chromite.testfM7PM1/chroot.img (deleted)) /dev/loop0: [65025]:1443667 (/tmp/chromite.run_tests.RTTISD/chromite.testY55i4W/chroot.img (deleted)) /dev/loop7: [65026]:2891217 (/usr/local/google/home/jkop/shadow_cros/chroot.img) /dev/loop5: [65025]:1443665 (/tmp/chromite.run_tests.6LgIhJ/chromite.testY9rDrY/chroot.img) /dev/loop3: [65025]:1443668 (/tmp/chromite.run_tests.Hfdjf4/chromite.test8WM5JC/chroot.img (deleted)) The other three all give me the same message: WARNING: Reading VG cros_tmp+chromite.run_tests.Th7fLj+chromite.testfM7PM1+chroot_000 from disk because lvmetad metadata is invalid. and then they hang there. (I also can't get past building matplotlib, but I assume that is a separate bug and I'm investigating it separately.)
,
Sep 7 2017
,
Oct 2 2017
,
May 25 2018
We've had a fair number of cleanups to the chroot loopback handling that have probably fixed this. In addition, crrev.com/i/557738 deleted the code that called cros_sdk, so it shouldn't matter now, anyway. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by jrbarnette@chromium.org
, Sep 7 2017