Bug 1001554

Actually, I will change the title of the bug. It turns out that every EXT4 device that I used had an entry in /etc/fstab. When I remove that entry, then I also could not umount the device using Files.

Hence, the bug is now related to every device that has not an entry in /etc/fstab. When I added the FAT32 USB stick to /etc/fstab, then I could umount it using Files.

Created attachment 694865 [details]
udiskctl dump

zaitor asked me to attach the log of `udiskctl dump`. In this case, the device I cannot unmount is /dev/sdb1

I see these messages in journald log every time I hit the eject button in Files (nautilus):

set 28 19:54:30 ronanarraes-osn tracker-extract[2639]: Unmount operation failed, adding back mount point...
set 28 19:54:30 ronanarraes-osn tracker-miner-f[2645]: Unmount operation failed, adding back mount point...

By the way, I can't even eject my DVD, because I can't unmount it. Now, I need to unmount as root, and then hit the eject button in nautilus.

Guys,

I found something really weird. I cannot use `umount` as user to unmount the device. However, if I run the following command as an user:

udisksctl unmount -b /dev/sdb1

then the device is unmounted properly.

(In reply to Ronan Chagas from comment #6)
> Guys,
> 
> I found something really weird. I cannot use `umount` as user to unmount the
> device. However, if I run the following command as an user:
> 
> udisksctl unmount -b /dev/sdb1
> 
> then the device is unmounted properly.

nothing weird - normal behavior; but udisk is what nautilus should fire off to do the umount too (well, through the dbus api)

I tested with nemo and I saw exactly the same error message.

I formatted my computer and installed Tumbleweed from the latest snapshot. I login in GNOME for the first time and tried to plug and unmount an USB stick. The same problem occurred.

I formatted again, but this time installing XFCE, and I also see the same problem. Hence, it should be something with gvfs I think.

Just one more information, in KDE it works perfectly. I can unmount the device using dolphin for example.

And now the things become really weird, I saw that I can unmount the USB devices using `gnome-disks`. I don't know why nautilus is using umount instead of udisks2 to unmount the devices.

Hi guys!

News, I think this is a Tumbleweed problem. Because if I download the Live CD of  Tumbleweed and test in a VM, then it is working perfectly. However, when I install Tumbleweed in the same VM, then it does not work anymore. Hence, it must be something related to the default configuration I think.

I also got same problem when I upgrade to Tumbleweed 20160927 (Gnome 3.20 to 3.22).
A user umount (or eject via Nautilus) the external device it not work, unless use gnome-disks or root user.
Today up to Tumbleweed 20161003, the problem persists.

Hi Kunigumi Yen,

Thanks! I was starting to think it was some local problem here.

I reported the issue to upstream also:

https://bugzilla.gnome.org/show_bug.cgi?id=772306

Can you please comment there? As of now, I do not know if it is an openSUSE bug or a GNOME bug triggered by a set of configurations in openSUSE.

Hi,

The things got more weird :)

If I install Tumbleweed from GNOME LiveCD, then I **do not** see the problem. However, if I install Tumbleweed from the Installation DVD, then I **see** the problem (http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-DVD-x86_64-Current.iso). Hence, it must be a configuration problem. However, I was not able to find what is different.

Does anyone have any idea what changes between the installation from the GNOME LiveCD and the DVD installation?

FOUND THE PROBLEM!

In my openSUSE installation and when I install openSUSE from the installation CD, the directory /var/run **is not** a symlink to /run

Otherwise, when I installed from LiveCD, the /var/run is indeed a symlink to /run

I needed to reboot in maintenance mode, unmount /var/run, remove it, symlink to /run

After a reboot, everything started to work again. Hence, it seems to be an openSUSE installation bug.

Nice debug work Ronan!

Now up to finding why this would go wrong.

filesystem does, it it's pre-install script:

if not posix.stat("/var/run") then
  posix.symlink("/run","/var/run")
end

Which can only mean that when the installation happened, /var/run existed already (otherwise it would have been symlinked)

So the big question will be to find what was evil enough to create this directory

zypper se --file-list /var/run

lists only two packages:
* filesystem (expected, it ghost own the directory)
* ntp (it should likely also use /run - it's the only cause I can find)

One way to possible test this would be to perform an installation from DVD and explicitly unselect / taboo 'ntp' during the installation.

If this problem disappears, we're sure it's NTP. If it doesn't disappear, we can not be sure it's not ntp (it could have been including data into installation-images already)

For the record, I did a fresh Tumbleweed installation in VirtualBox yesterday (default KDE install, with the NET ISO), and /var/run/ was a symlink to /run/.

And ntp was/is installed, so it's maybe not the culprit (or the problem has been fixed already...)

(In reply to Wolfgang Bauer from comment #19)
> For the record, I did a fresh Tumbleweed installation in VirtualBox
> yesterday (default KDE install, with the NET ISO), and /var/run/ was a
> symlink to /run/.
> 
> And ntp was/is installed, so it's maybe not the culprit (or the problem has
> been fixed already...)

Or the issue only happens with the DVD - installing from the live image means also using the NET installer - as Ronan said, then the problem does not appear; only when installing from the DVD

(In reply to Dominique Leuenberger from comment #20)
> Or the issue only happens with the DVD - installing from the live image
> means also using the NET installer - as Ronan said, then the problem does
> not appear; only when installing from the DVD

Right, I just wanted to mention it. (And I forgot about the fact that the LiveCD is using the NET installer nowadays... Sorry for that.)

May be related to the order in which the packages are installed too I suppose, might explain a difference between a KDE and a GNOME install.
But probably not between a GNOME install using the DVD or the NET ISO...

What may be a difference though is that the NET installer downloads the current versions from the online repos, while the DVD is fixed.
So maybe it would be a good idea to retry with the latest DVD?

(In reply to Dominique Leuenberger from comment #17)
> Nice debug work Ronan!
> 
> Now up to finding why this would go wrong.
> 
> filesystem does, it it's pre-install script:
> 
> if not posix.stat("/var/run") then
>   posix.symlink("/run","/var/run")
> end
> 
> Which can only mean that when the installation happened, /var/run existed
> already (otherwise it would have been symlinked)
> 
> So the big question will be to find what was evil enough to create this
> directory

Hi Dominique,

Thanks! I installed Tumbleweed again disabling NTP at installation (using the standard DVD) and the problem continues. Any new ideas?

(In reply to Wolfgang Bauer from comment #21)
> What may be a difference though is that the NET installer downloads the
> current versions from the online repos, while the DVD is fixed.
> So maybe it would be a good idea to retry with the latest DVD?

Hi!

I am already using the latest available Tumbleweed ISO.

One question for my clarification: when you talk about the 'GNOME Live CD' that us the 'Tumbleweed GNOME Live CD', same snapshot number as the DVD, right?

(In reply to Dominique Leuenberger from comment #24)
> One question for my clarification: when you talk about the 'GNOME Live CD'
> that us the 'Tumbleweed GNOME Live CD', same snapshot number as the DVD,
> right?

Exactly!

(In reply to Dominique Leuenberger from comment #18)
> * ntp (it should likely also use /run - it's the only cause I can find)
> 

ntp matches due to /var/lib/ntp/var/run so it cannot trigger /var/run creation. The worst case is if some script does "mkdir -p /var/run/foo" during installation. Not sure if there is feasible method to check it. Is it possible single-step installation? Then we could check after every package when /var/run appears.

I started the installation and begin to continuously type `ls` in the console. I figured out that the /var/run directory is created during the process of deploying GNOME image. Does it make any sense?

(In reply to Ronan Chagas from comment #27)
> I started the installation and begin to continuously type `ls` in the
> console. I figured out that the /var/run directory is created during the
> process of deploying GNOME image. Does it make any sense?

yes. this is pretty much where I started looking in already and what I expected...

from what I found in the images there is a stale zypp.pid in there for some reason.

https://build.opensuse.org/package/rdiff/openSUSE:Factory:Live/openSUSE-images?linkrev=base&rev=27

is an attempt to get this fixed already (I reverted the first - was not happy with the partial clenaup only) - the next snapshot will show it to be true/false

System:    Host: linux-s4s1 Kernel: 4.7.5-1-default x86_64 (64 bit gcc: 6.2.1)
           Desktop: Cinnamon 3.0.7  dm: sddm,sddm Distro: openSUSE Tumbleweed

found file with possible reference to symlink, not sure if it pertains, 

/usr/lib/dracut/modules.d/30convertfs/convertfs.sh
-rwxr-xr-x 1 root root 6035 Nov 25  2015 convertfs.sh

(In reply to Emanuel Castelo from comment #29)
> System:    Host: linux-s4s1 Kernel: 4.7.5-1-default x86_64 (64 bit gcc:
> 6.2.1)
>            Desktop: Cinnamon 3.0.7  dm: sddm,sddm Distro: openSUSE Tumbleweed
> 
> found file with possible reference to symlink, not sure if it pertains, 
> 
> /usr/lib/dracut/modules.d/30convertfs/convertfs.sh
> -rwxr-xr-x 1 root root 6035 Nov 25  2015 convertfs.sh

https://gist.github.com/anonymous/64e1fb32751bb9611522982148d348cd file content as found and snippet:


if [ ! -L $ROOT/var/run -a -e $ROOT/var/run ]; then
    echo "Converting /var/run to symlink"
    mv -f $ROOT/var/run $ROOT/var/run.runmove~
    ln -sfn ../run $ROOT/var/run
fi

Ronan,

Can you please test with the latest DVD (20161010) if this problem still exists or if my fix worked?

(In reply to Dominique Leuenberger from comment #31)
> Ronan,
> 
> Can you please test with the latest DVD (20161010) if this problem still
> exists or if my fix worked?

Sure! I'm downloading openSUSE-Tumbleweed-DVD-x86_64-Snapshot20161010-Media.iso right now to test.

Hi Dominique,

I can confirm that /var/run is now a symlink to /run if I use the lastest ISO to install Tumbleweed. Hence, unmounting USB devices as an user is working perfectly. Thus, we can consider this bug closed.

Just one more thing, by the way, can you provide a recipe so that users who installed Tumbleweed before this snapshot can fix their systems without reinstall?

What I did was:

1) Reboot in maintenance mode (INIT 1);
2) Unmount /var/run (I guess it is bind mounted to /run);
3) rm -rf /var/run
4) cd /var
5) ln -sf ./run ../run

Are those steps fine?

(In reply to Ronan Chagas from comment #33)
> 
> 1) Reboot in maintenance mode (INIT 1);
> 2) Unmount /var/run (I guess it is bind mounted to /run);
> 3) rm -rf /var/run
> 4) cd /var
> 5) ln -sf ./run ../run
> 

Is something like this really necessary? Shouldn't
https://git.gnome.org/browse/gvfs/commit/?id=be0c464
fix things (at least the issue with nautilus being unable to unmount) automatically?

(In reply to Atri Bhattacharya from comment #34)
> (In reply to Ronan Chagas from comment #33)
> > 
> > 1) Reboot in maintenance mode (INIT 1);
> > 2) Unmount /var/run (I guess it is bind mounted to /run);
> > 3) rm -rf /var/run
> > 4) cd /var
> > 5) ln -sf ./run ../run
> > 
> 
> Is something like this really necessary? Shouldn't
> https://git.gnome.org/browse/gvfs/commit/?id=be0c464
> fix things (at least the issue with nautilus being unable to unmount)
> automatically?

Yes, this should fix this problem. However, AFAIK, /var/run must be a symlink to /run nowadays. Hence, I think other bugs can occur if this is not fixed.

Guys, the new installations of Tumbleweed does not have this problem. We can close it.