Re: Cannot delete chroot

[Denis Glotov]

Hi devs!

I try to delete my old chroot and get the following error. In fact, any operations (enter, replace) lead to the same result. How could I help it (reboot didn't help)?

glotov@glotov-z600:~/chromiumos/src/scripts$ cros_sdk --chroot=/home/glotov/chromiumos/chroot.plain/ --delete

Traceback (most recent call last):

  File "/home/glotov/depot_tools/cros_sdk", line 101, in <module>

    sys.exit(main())

  File "/home/glotov/depot_tools/cros_sdk", line 97, in main

    return our_tool.main()

  File "/usr/local/google/home/glotov/chromiumos/chromite/bin/cros_sdk.py", line 316, in main

    with locking.FileLock(lock_path, 'chroot lock').read_lock() as lock:

  File "/usr/local/google/home/glotov/chromiumos/chromite/lib/locking.py", line 66, in read_lock

    self._enforce_lock(fcntl.LOCK_SH, message)

  File "/usr/local/google/home/glotov/chromiumos/chromite/lib/locking.py", line 44, in _enforce_lock

    fcntl.flock(self.fd, flags|fcntl.LOCK_NB)

  File "/usr/local/google/home/glotov/chromiumos/chromite/lib/locking.py", line 37, in fd

    fd = self._fd = os.open(self.path, os.R_OK|os.O_CREAT|cloexec)

OSError: [Errno 13] Permission denied: '/home/glotov/chromiumos/chroot.plain/.chroot_lock'

-- 
Thank you, 

Denis

[Alexander Potapenko]

Do you have enough permissions to access
/home/glotov/chromiumos/chroot.plain/.chroot_lock ?
Is it possible it's owned by the root?

> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

--
Alexander Potapenko
Software Engineer
Google Moscow

[Emmanuel Saint-loubert]

You can alway do a
sudo rm -rf
I know it is frowned up because you could have some mounted stuff (probably cleared by a reboot) But that works. I have done it many times.

[Denis Glotov]

/home/glotov/chromiumos/chroot.plain/.chroot_lock does not exist. But I have permissions to `sudo touch` it.

Yes, `sudo rm -rf` rocks :)

--
Thank you,
Denis

[Jonathan Kliegman]

First a sanity check - is the path pointed to (/home/glotov/chromeos/chroot.plain on nfs?  If so that could likely be causing problems (although how it got created on NFS in the first place seems odd)

Next I'd make sure you don't have any processes still in the chroot and then manually remove the single offending file (/home/glotov/chromeos/chroot.plain/.chroot_lock).  You can also run lsof against it to see what's going on.  

sudo rm -rf ...  can be very dangerous.  You should try rebotting first (and rerunning the delete command) before you run rm -rf . And only run rm -rf after a reboot unless you know what you're doing.

If you do think you know what you're doing, run mount and losetup to make sure you don't have anything in that tree already mounted.  

[Matt Tennant]

That looks like code that was recently adding to lock write access to
the chroot during creation/deletion and read access during otherwise.
See https://gerrit.chromium.org/gerrit/#change,15306.

My guess: was the /home/glotov/chromeos/chroot.plain directory owned
by sudo user? The unusual "chroot.plain" name implies that something
manual was done.

-Matt

[Zdenek Behan]

+ferringb

I saw a similar problem myself. Brian is doing some more tweaking with the locking, specifically concerning working with the --chroot option, which is your case.


Zdenek

[Brian Harring]

What are the permissions of /home/glotov/chromiumos/ ?

This code can only fail if you (your user) lacks write access to that directory... which would be very odd, and wouldn't be nfs related.

Also, I'm mildly curious why you're explicitly forcing a different name for the chroot?

Thanks-

~brian

[Denis Glotov]

On Tue, Feb 14, 2012 at 2:55 AM, Brian Harring <ferr...@google.com> wrote:

What are the permissions of /home/glotov/chromiumos/ ?

I have already deleted that chroot with 'mf -rf', but I have another one left. But cros_sdk works fine for it.

drwxr-xr-x 20 root root 4096 2012-02-08 17:29 /home/glotov/local/cros_release-R18-1660.B/chroot.instr/

This code can only fail if you (your user) lacks write access to that directory... which would be very odd, and wouldn't be nfs related.

I could manually `sudo touch /home/glotov/chromiumos/chroot.plain/.chroot_lock`.

 

Also, I'm mildly curious why you're explicitly forcing a different name for the chroot?

Because I work with 2 chroots simultaneously: One for regular build, and another for instrumented build (I instrument Chrome to track its execution and optimize later, more info here: https://sites.google.com/a/google.com/chrome-msk/dev/boot-speed-up-effort). 

--
Thank you,
Denis

[Brian Harring]

On Tue, Feb 14, 2012 at 4:46 AM, Denis Glotov <glo...@chromium.org> wrote:

On Tue, Feb 14, 2012 at 2:55 AM, Brian Harring <ferr...@google.com> wrote:

What are the permissions of /home/glotov/chromiumos/ ?

I have already deleted that chroot with 'mf -rf', but I have another one left. But cros_sdk works fine for it.

drwxr-xr-x 20 root root 4096 2012-02-08 17:29 /home/glotov/local/cros_release-R18-1660.B/chroot.instr/

This code can only fail if you (your user) lacks write access to that directory... which would be very odd, and wouldn't be nfs related.

I could manually `sudo touch /home/glotov/chromiumos/chroot.plain/.chroot_lock`.

Note the lock would be /home/glotov/chromiumos/.chroot.plain.lock ; it's stored in the same directory as the chroot.
 

Also, I'm mildly curious why you're explicitly forcing a different name for the chroot?

Because I work with 2 chroots simultaneously: One for regular build, and another for instrumented build (I instrument Chrome to track its execution and optimize later, more info here: https://sites.google.com/a/google.com/chrome-msk/dev/boot-speed-up-effort). 

Fair enough.

I landed some touch up code yesterday that should resolve any issues you've seen; if you encounter anymore weird locking/permission failures, etc, please file a ticket my way and I'll check into it.

Thanks-

~brian