GNU bug report logs -
#35584
CDs and DVDs aren't auto-mounted
Previous Next
To reply to this bug, email your comments to 35584 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Sun, 05 May 2019 16:54:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
sirgazil <sirgazil <at> zoho.com>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sun, 05 May 2019 16:54:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
I installed the GNU system in a real machine using the Guix 1.0 ISO installer (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz).
When I insert a CD or a DVD the drive light flashes for a moment, then turns off, but it seems the discs are never mounted. GNOME displays no messages, GNOME Files does not list the drive, I don't see anything related to DVD after running "findmnt", and running "lsblk" says:
```
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 750M 0 part /boot/efi
├─sda2 8:2 0 3,7G 0 part [SWAP]
└─sda3 8:3 0 927,1G 0 part /
sr0 11:0 1 1024M 0 rom
```
---
https://sirgazil.bitbucket.io/
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Sun, 05 May 2019 18:12:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 35584 <at> debbugs.gnu.org (full text, mbox):
On Sun, May 05, 2019 at 11:52:36AM -0500, sirgazil wrote:
> Hi,
>
> I installed the GNU system in a real machine using the Guix 1.0 ISO installer (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz).
>
> When I insert a CD or a DVD the drive light flashes for a moment, then turns off, but it seems the discs are never mounted. GNOME displays no messages, GNOME Files does not list the drive, I don't see anything related to DVD after running "findmnt", and running "lsblk" says:
>
> ```
> $ lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> sda 8:0 0 931,5G 0 disk
> ├─sda1 8:1 0 750M 0 part /boot/efi
> ├─sda2 8:2 0 3,7G 0 part [SWAP]
> └─sda3 8:3 0 927,1G 0 part /
> sr0 11:0 1 1024M 0 rom
> ```
I can confirm. So sr0 is visible. The same happens for me on an
internal and an external USB DVD drive when I insert a video DVD, but
I can play it with VLC and once I open the drive /dev/sr0 in VLC it
gets auto-mounted in Nautilus. Note that I have gvfs in my packages
field, if that makes a difference.
On Arch the DVD gets mounted by Nautilus immediately on insert.
I have no idea why that happens though.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Sun, 05 May 2019 20:18:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 35584 <at> debbugs.gnu.org (full text, mbox):
pelzflorian (Florian Pelz) <pelzflorian <at> pelzflorian.de> writes:
> On Sun, May 05, 2019 at 11:52:36AM -0500, sirgazil wrote:
>> Hi,
>>
>> I installed the GNU system in a real machine using the Guix 1.0 ISO installer (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz).
>>
>> When I insert a CD or a DVD the drive light flashes for a moment, then turns off, but it seems the discs are never mounted. GNOME displays no messages, GNOME Files does not list the drive, I don't see anything related to DVD after running "findmnt", and running "lsblk" says:
>>
>> ```
>> $ lsblk
>> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
>> sda 8:0 0 931,5G 0 disk
>> ├─sda1 8:1 0 750M 0 part /boot/efi
>> ├─sda2 8:2 0 3,7G 0 part [SWAP]
>> └─sda3 8:3 0 927,1G 0 part /
>> sr0 11:0 1 1024M 0 rom
>> ```
>
> I can confirm. So sr0 is visible. The same happens for me on an
> internal and an external USB DVD drive when I insert a video DVD, but
> I can play it with VLC and once I open the drive /dev/sr0 in VLC it
> gets auto-mounted in Nautilus. Note that I have gvfs in my packages
> field, if that makes a difference.
>
> On Arch the DVD gets mounted by Nautilus immediately on insert.
I cannot reproduce this with a slightly older system. On my workstation
CDs could always be mounted by Nautilus immediately. If this doesn’t
work any more it must be a regression.
--
Ricardo
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Sat, 11 May 2019 20:25:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 35584 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Not sure it's related, but it's awfully similar to the issue I'm having
with CDEmu: I can load images but nothing ever gets mounted.
--
Pierre Neidhardt
https://ambrevar.xyz/
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Mon, 04 Nov 2019 23:06:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 35584 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Just to add that the problem is still present today on:
$ LANG=C guix describe
Generation 5 Nov 04 2019 14:24:15 (current)
guix bf7b08c
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: bf7b08c4fe7d14c25a83bde99f19eca1119d88ff
Also, I was able to use the drive successfully from a Trisquel 8 Live USB stick. So, at least I know the drive works.
---
https://sirgazil.bitbucket.io/
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Wed, 29 Jul 2020 01:57:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 35584 <at> debbugs.gnu.org (full text, mbox):
This bug persist on the Guix version I'm using:
★★★★★★★★★★
$ guix describe
Generation 4 Jul 05 2020 13:40:24 (current)
guix 6ee7468
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 6ee7468758d7c043692ae8c0b5e130fa4eabe94c
★★★★★★★★★★
There is one thing I hadn't noticed before, though. If I insert a DVD while I'm in a GNOME session, it doesn't work (that's the bug), but if I reboot with the DVD still in, log in to GNOME and open Nautilus, the DVD is listed and it works correctly. After doing this, if I extract the DVD and insert it again, it still doesn't work.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Wed, 29 Jul 2020 13:19:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 35584 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
On Wed, 29 Jul 2020 00:15:39 +0000
Luis Felipe via Bug reports for GNU Guix <bug-guix <at> gnu.org> wrote:
> There is one thing I hadn't noticed before, though. If I insert a DVD while I'm in a GNOME session, it doesn't work (that's the bug), but if I reboot with the DVD still in, log in to GNOME and open Nautilus, the DVD is listed and it works correctly. After doing this, if I extract the DVD and insert it again, it still doesn't work.
Checking nautilus sources, it uses GVolumeMonitor which is part of glib (gio).
That uses GUnixMountMonitor, and that checks /proc/mounts and fstab.
fstab is found like this:
static char *
get_fstab_file (void)
{
#ifdef HAVE_LIBMOUNT
return (char *) mnt_get_fstab_path ();
#else
#if defined(HAVE_SYS_MNTCTL_H) && defined(HAVE_SYS_VMOUNT_H) && defined(HAVE_SYS_VFS_H)
/* AIX */
return "/etc/filesystems";
#elif defined(_PATH_MNTTAB)
return _PATH_MNTTAB;
#elif defined(VFSTAB)
return VFSTAB;
#else
return "/etc/fstab";
#endif
#endif
}
libmount is part of util-linux, which has:
/**
* mnt_get_fstab_path:
*
* Returns: path to /etc/fstab or $LIBMOUNT_FSTAB.
*/
const char *mnt_get_fstab_path(void)
{
const char *p = safe_getenv("LIBMOUNT_FSTAB");
return p ? : _PATH_MNTTAB;
}
In order to debug this problem, please try setting the environment variable
before starting nautilus, like this:
killall nautilus
export LIBMOUNT_FSTAB=/etc/fstab
nautilus
Then check whether detecting changes in CD/DVD state work fine like this.
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Wed, 29 Jul 2020 13:20:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Wed, 29 Jul 2020 13:43:02 GMT)
Full text and
rfc822 format available.
Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi, Danny.
> In order to debug this problem, please try setting the environment variable
> before starting nautilus, like this:
>
> killall nautilus
> export LIBMOUNT_FSTAB=/etc/fstab
> nautilus
>
> Then check whether detecting changes in CD/DVD state work fine like this.
>
Unfortunately not. I got this:
$ killall nautilus
nautilus: no process found
So I closed any visible instance of Nautilus instead, exported the LIBMOUNT_FSTAB variable, started nautilus, inserted a DVD, and it didn't work.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Wed, 29 Jul 2020 13:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Tue, 08 Dec 2020 15:57:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 35584 <at> debbugs.gnu.org (full text, mbox):
This bug persists in the Guix System version I'm using:
guix 08d8c2d
linux-libre 5.9.12-gnu
Changed bug title to 'CDs and DVDs aren't auto-mounted' from 'CD/DVD does not work'
Request was from
Tobias Geerinckx-Rice <me <at> tobias.gr>
to
control <at> debbugs.gnu.org
.
(Tue, 08 Dec 2020 17:13:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Thu, 25 Mar 2021 23:53:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 35584 <at> debbugs.gnu.org (full text, mbox):
This persists. System commit from about 1-2 weeks ago. (built from
private branch, so commit name wouldn't mean much)
Not sure how to investigate, because last time I tried looking into
GVFS issues it turned out to be a huge mess.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Mon, 24 Mar 2025 00:36:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 35584 <at> debbugs.gnu.org (full text, mbox):
Hi,
Luis Felipe <luis.felipe.la <at> protonmail.com> writes:
> Hi, Danny.
>
>> In order to debug this problem, please try setting the environment variable
>> before starting nautilus, like this:
>>
>> killall nautilus
>> export LIBMOUNT_FSTAB=/etc/fstab
>> nautilus
>>
>> Then check whether detecting changes in CD/DVD state work fine like this.
>>
>
> Unfortunately not. I got this:
>
> $ killall nautilus
> nautilus: no process found
>
> So I closed any visible instance of Nautilus instead, exported the
> LIBMOUNT_FSTAB variable, started nautilus, inserted a DVD, and it
> didn't work.
4 years later, the problem persists!
Here's how I've been trying to debug it further:
1. Generate a VM image of our GNOME desktop template:
./pre-inst-env guix system image --image-type=efi-raw
gnu/system/examples/desktop.tmpl
(note that to boot it you'll have to select the EFI firmware, and you'll
probably want bug#77110 applied to make this easier)
2. Copy it somewhere, e.g. /tmp/guix-gnome-desktop.raw
3. Make it writable: chmod +w /tmp/guix-home-desktop.raw
4. Install a new VM from this image in virt-manager. In my case I've
named it 'guix-gnome-desktop'. Make sure to turn
on 3D acceleration by selecting the virtio driver for the video device,
checking '3D acceleration' (otherwise, virtualized GNOME is barely
usable and frequently hangs for long bouts of time)
5. Add a CDROM storage device (SATA) via the virt-manager GUI
6. Start the VM, the fun can start!
7. Find the path to the CDROM drive via:
--8<---------------cut here---------------start------------->8---
virsh -c qemu:///system domblklist guix-gnome-desktop
Target Source
--------------------------------------
vda /tmp/guix-gnome-desktop.raw
sda -
--8<---------------cut here---------------end--------------->8---
As you can see the device name of the CDROM in my case is 'sda'. That
can also be seen in the XML of the device in the virt-manager GUI.
We'll now insert a virtual CDROM via virsh:
--8<---------------cut here---------------start------------->8---
virsh -c qemu:///system change-media guix-gnome-desktop sda \
--inject path/to/your-sample.iso
--8<---------------cut here---------------end--------------->8---
To eject:
--8<---------------cut here---------------start------------->8---
virsh -c qemu:///system change-media guix-gnome-desktop sda --eject
--8<---------------cut here---------------end--------------->8---
We can now debug this issue efficiently and without having an actual
CDROM drive. Except that currently 'udevadm monitor' doesn't seem to
print anything. Hm. Perhaps that's part of the problem? Or my
expectations of udevadm are wrong.
--
Thanks,
Maxim
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Wed, 30 Apr 2025 05:57:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 35584 <at> debbugs.gnu.org (full text, mbox):
Hi,
It looks like it's a udev configuration thing, as we have CDROM support
builtin the kernel (sr_mod), and the eudev of Void Linux, which is at
the same version as ours, report this when attaching a media to a
virtual CDROM in virt-manager:
--8<---------------cut here---------------start------------->8---
$ udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[2401.365251] change /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0 (block)
KERNEL[2401.450065] change /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0 (block)
UDEV [2401.527639] change /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0 (block)
UDEV [2401.567290] change /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0 (block)
KERNEL[2401.786096] change /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0 (block)
UDEV [2401.824286] change /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0 (block)
--8<---------------cut here---------------end--------------->8---
While on Guix System the same is quiet:
--8<---------------cut here---------------start------------->8---
$ udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
--8<---------------cut here---------------end--------------->8---
Fedora has these udev rules:
--8<---------------cut here---------------start------------->8---
$ sudo grep -irl -E '(cdrom|optic|dvd)' /usr/lib/udev/rules.d | sort
[sudo] password for user:
/usr/lib/udev/rules.d/50-udev-default.rules
/usr/lib/udev/rules.d/60-cdrom_id.rules
/usr/lib/udev/rules.d/60-persistent-storage.rules
/usr/lib/udev/rules.d/70-uaccess.rules
/usr/lib/udev/rules.d/80-pktsetup.rules
/usr/lib/udev/rules.d/80-udisks2.rules
--8<---------------cut here---------------end--------------->8---
While Void Linux (where it works) has the sames except for
80-pktsetup.rules, which is missing. On Guix System we have these:
--8<---------------cut here---------------start------------->8---
$ grep -iRl -E '(cdrom|optic|dvd)' /etc/udev/rules.d/ | sort
/etc/udev/rules.d/50-udev-default.rules
/etc/udev/rules.d/60-cdrom_id.rules
/etc/udev/rules.d/60-libsane.rules
/etc/udev/rules.d/60-persistent-storage.rules
/etc/udev/rules.d/70-uaccess.rules
/etc/udev/rules.d/80-udisks2.rules
--8<---------------cut here---------------end--------------->8---
60-libsane sticks out as something only we have; perhaps it 'eats' the
kernel event for itself and means udisks2.rules doesn't get to see it.
To be continued.
--
Thanks,
Maxim
Reply sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
:
You have taken responsibility.
(Sat, 03 May 2025 23:58:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
sirgazil <sirgazil <at> zoho.com>
:
bug acknowledged by developer.
(Sat, 03 May 2025 23:58:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 35584-done <at> debbugs.gnu.org (full text, mbox):
Hi,
This is finally fixed, see commit 670724edcfe ("gnu: eudev: Fix optical
discs detection/auto-mounting.")
Closing!
--
Thanks,
Maxim
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Sun, 04 May 2025 00:07:07 GMT)
Full text and
rfc822 format available.
Message #54 received at 35584-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 3/05/25 23:57, Maxim Cournoyer wrote:
> This is finally fixed, see commit 670724edcfe ("gnu: eudev: Fix optical
> discs detection/auto-mounting.")
>
> Closing!
Thank you Maxim :)
[OpenPGP_0x0AB0D067012F08C3.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 14 May 2025 01:02:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35584
; Package
guix
.
(Wed, 14 May 2025 01:10:03 GMT)
Full text and
rfc822 format available.
Message #59 received at 35584 <at> debbugs.gnu.org (full text, mbox):
reopen 35584
thanks
Hi,
> This is finally fixed, see commit 670724edcfe ("gnu: eudev: Fix optical
> discs detection/auto-mounting.")
While this is currently working, a discussion with systemd [0] revealed
that this the existing rule should work as-is, regardless of whether the
cdrom block driver is builtin the kernel or as a module. This means the
fix is really a workaround rather than something fixing the root issue;
I'm thus reopening the issue and will try to find a better solution for
it.
One extra check I've now made is locally revert the earlier fix (commit
670724), then build the cdrom block driver as a module like it is on
Void Linux (which to recall uses the same eudev version without this
problem) and tested: the problem persists.
In the systemd discussion, they pointed that potentially the problem has
to do with the 'udevadm trigger' that is run; perhaps it is done too
early still, despite waiting on the udevd unix socket (wait-for-udevd)
in the udev-shepherd-service. I'll investigate in this direction.
[0] https://github.com/systemd/systemd/pull/37336
--
Thanks,
Maxim
Reply sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
:
You have taken responsibility.
(Wed, 14 May 2025 13:32:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
sirgazil <sirgazil <at> zoho.com>
:
bug acknowledged by developer.
(Wed, 14 May 2025 13:32:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 35584-done <at> debbugs.gnu.org (full text, mbox):
Hi,
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> While this is currently working, a discussion with systemd [0] revealed
> that this the existing rule should work as-is, regardless of whether the
> cdrom block driver is builtin the kernel or as a module. This means the
> fix is really a workaround rather than something fixing the root issue;
> I'm thus reopening the issue and will try to find a better solution for
> it.
>
> One extra check I've now made is locally revert the earlier fix (commit
> 670724), then build the cdrom block driver as a module like it is on
> Void Linux (which to recall uses the same eudev version without this
> problem) and tested: the problem persists.
>
> In the systemd discussion, they pointed that potentially the problem has
> to do with the 'udevadm trigger' that is run; perhaps it is done too
> early still, despite waiting on the udevd unix socket (wait-for-udevd)
> in the udev-shepherd-service. I'll investigate in this direction.
>
> [0] https://github.com/systemd/systemd/pull/37336
In the end, the issue was that our udev-service-type was not running
"udevadm" "trigger" "--action=add" "--type=subsystems", which is needed
to create the subsystem nodes. Because they were missing, the udev
block rules was not running and there was no default polling value set
on block devices such as cdrom.
See commit 4acbceed261.
Closing for good!
--
Thanks,
Maxim
This bug report was last modified 27 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.