Last week maybe I downloaded the latest image to use. Definitely lots of improvements but there is an issue that’s been causing me problems. It’s been automounting my USB HDDs ext3 partition and the swap partition(!) under /media with the partition UUIDs as the mount point name.
Is anyone else having this issue? How do I stop it? Having a mount point the swap partition especially is an issue because it breaks software that enumerates mount points.
How is your swap partition defined? Do you have an entry in /etc/fstab for it with the UUID as the identifier, or the device name? Reason I ask is becase /dev/hd* is not guaranteed to be the same (especially with USB), while a UUID will always work.
Your swap entry should probably look something like this:
UUID=d448e17a-5fbc-496f-a0ea-6fa2cb04d9ee none swap sw 0 0
…where the UUID is that of your swap partition. You can of course mount any other partition by uuid as well.
Initially no. I was just doing
sudo swapon /dev/sda2
after login, and the data partition was mounting under /media/UUID_of_the_partition, as was the swap partition.
I didn’t see this behaviour in a much older SD image.
A couple of days ago I added the swap partition and data partition to fstab like so.
UUID="2ee041b4-243f-494a-943a-ef3fea1621aa" none swap sw,nofail 0 0
UUID="48e6d8ff-9d41-4675-ade5-60e64d90f993" /media/spinner ext3 defaults,nofail 0 0
I use nofail in case I need to boot without the drive. This didn’t get rid of the mountpoints. I didn’t think it would, but it was worth a try. The fstab entries were only missing initially because I hadn’t bothered to put them in the new install.
With the much older image, the data partition used to mount under /media/$USER/spinner
I’m absolutely nonplussed by this. I’ve never seen this happen before and have no idea what’s mounting these partitions.
Those fstab entries look right. Nofail is certainly a good idea. I’m not sure the quotes matter around the UUID (mine has none). Does /media/spinner mount on boot with this fstab? is the swap visible when you run “free”? I can’t say I’ve ever experienced nautilus/whatever trying to mount my swap in /media/…
Yes and yes.
I haven’t seen this behaviour before either. I was hoping someone on here would know if it’s specific to a particular disc image here or something.
What struck me as really odd is after adding the fstab entries, spinner had two mountpoints. The weird UUID one and /media/spinner. Two mountpints for the same device is a little odd.
It’s totally possible to mount some things twice, and there are sometimes good reasons for it, but I don’t think it should be happening in this case. My experience has been when something is inside /etc/fstab, it’s ignored by the gui’s mount mechanics. I’d love to know exactly what is mounting it.
Can you post the full result of ‘mount’. Also what window manager are you using (default Unity Gnome, or something else). I will plug in a storage device into my Nano tomorrow and try to replicate. Anything else particular to your configuration?
The post was pulled for some reason.
Here’s the interesting lines
systemd-1 on /media/48e6d8ff-9d41-4675-ade5-60e64d90f993 type autofs (rw,relatime,fd=52,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
systemd-1 on /media/2ee041b4-243f-494a-943a-ef3fea1621aa type autofs (rw,relatime,fd=53,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
/dev/sda1 on /media/spinner type ext3 (rw,relatime,data=ordered)
/dev/sda1 on /media/48e6d8ff-9d41-4675-ade5-60e64d90f993 type ext3 (rw,relatime,data=ordered)
I’m installing XFCE and lightdm to see what happens. Plus I prefer them anyway.
Spotted the following in the update output. Weird.
update-initramfs: Generating /boot/initrd.img-4.9.140-tegra
Warning: couldn't identify filesystem type for fsck hook, ignoring.
I: The initramfs will attempt to resume from /dev/sda2
I: (UUID=2ee041b4-243f-494a-943a-ef3fea1621aa)
I: Set the RESUME variable to override this.
edit:
In XFCE in Thunar (using lightdm) spinner still appears in the UUID and label forms. The swap partition is still in /media/whatever as an unreadable mountpoint.
Unless anyone has any better ideas, I would suggest reflashing and starting from scratch. Something in your configuration is doing this and I’m not sure what. /etc/fstab can mount stuff. You can configure systemd to mount stuff. Various desktops do it. You could try searching journalctl for your uuids/partition names, but if there aren’t any clues, I am out of ideas.
Re: update-initramfs error message: I believe you can ignore that safely. My understanding is it just means it will ignore that partition for fsck on error. You got it after an apt upgrade, yes?
The “noauto” parameter would prevent automatic mount of the UUID, but would not prevent mount. Based on an earlier comment, maybe something like this:
UUID="2ee041b4-243f-494a-943a-ef3fea1621aa" none swap sw,nofail<b>,noauto</b> 0 0
UUID="48e6d8ff-9d41-4675-ade5-60e64d90f993" /media/spinner ext3 defaults,nofail<b>,noauto</b> 0 0
I’m not actually sure about the concept of “noauto” with a swap entry, but it might do the job. The ext3 mount would definitely then only mount if you tell it to mount.
I’m trying to avoid reflashing again. Even though nVidia releases the images, they still need a lot of the tools manually installed afterward. Especially if one wishes to use the nvdli-nano lessons with the desktop image. That image requires quite a few things which IMHO should be included in the desktop image.
The update-initramfs was part of an apt install. It caught my eye because it was trying to look at the mountpoint for the swap partition, which is a disaster for anything that attempts it.
linuxdev, that is an interesting idea. A band-aid, but it could do the job.
I’ve found a couple of instances in journalctl so far, but nothing that immediately tells me what’s going on. It’s all systemd related though.
Not really related, but the current default settings for xubuntu-desktop are really nice compared to what they were.
My understanding is experimentech does want to mount on startup, but some mechanism is mounting it twice. “noauto” will prevent mount on boot, so swap probably won’t mount properly, even if “spinner” does appear in /media/ by unknown means. Worth a shot to see what happens, however.
Re: systemd, it’s the usual scapegoat but my experience with it has been positive overall. Without it, boot would be much slower. Systemd generates a graph of what things depend on what and launch services in parallel where possible. Plus I personally prefer unit files to 100 different bad init scripts. Also Lennart Poettering is God, I’m pretty sure.
If it is the culprit, the answer should be in journalctl. I recall reading some recent news about some new mount abilities for systemd so it is totally possible. I don’t think those changes are in LTS yet, however, and you have to make .mount unit files, I think.
Did some Googling and I think Nautilus/gvfs may be the culprit.
https://askubuntu.com/questions/23033/mounted-drives-appearing-twice-in-lists
Would be interesting to see if XFCE solves the problem. If it does, it’s Nautilus for sure. Maybe something Canonical did. I run vanilla Gnome on my Desktop and haven’t had this happen.
It didn’t. I installed XFCE and lightdm just to be thorough. I think I commented that the current defaults for xubuntu-desktop look nicer than they used to.
To concur with the clarification, the two partitions are automounting and giving a path of /media/UUID essentially. These are the two partitions on a USB drive/ An ext3 and a swap partition. The swap partition shouldn’t even have a mountpoint.
I just want the ext3 partition mounted my way. ie /media/spinner. I have done that, and set up a normal swap mount, but the weird UUID partitions still persist/. I still need to finish digginng through journalctl. Because I don’t know what the culprit is I have to read it all. Haven’t had much time for that yet.
The more I see, the less I understand. This is from systemctrl. There are lots of similar entries.
09:20:17 astro systemd[1]: media-2ee041b4\x2d243f\x2d494a\x2d943a\x2def3fea1621aa.automount: Got automount request for /media/2ee041b4-243f-494a-943a-ef3fea1621aa, triggered by 22799 (umount)
Feb 24 09:20:17 astro systemd[1]: Mounting /media/2ee041b4-243f-494a-943a-ef3fea1621aa...
Feb 24 09:20:17 astro mount[22800]: mount: /media/2ee041b4-243f-494a-943a-ef3fea1621aa: unknown filesystem type 'swap'.
Feb 24 09:20:17 astro systemd[1]: media-2ee041b4\x2d243f\x2d494a\x2d943a\x2def3fea1621aa.mount: Mount process exited, code=exited status=32
Feb 24 09:20:17 astro systemd[1]: media-2ee041b4\x2d243f\x2d494a\x2d943a\x2def3fea1621aa.mount: Failed with result 'exit-code'.
Feb 24 09:20:17 astro systemd[1]: Failed to mount /media/2ee041b4-243f-494a-943a-ef3fea1621aa.
Feb 24 09:20:17 astro systemd[1]: media-2ee041b4\x2d243f\x2d494a\x2d943a\x2def3fea1621aa.automount: Got invalid poll event 16 on pipe (fd=47)
Feb 24 09:20:17 astro systemd[1]: media-2ee041b4\x2d243f\x2d494a\x2d943a\x2def3fea1621aa.automount: Failed with result 'resources'.