[SOLVED] Suspend irritation on all versions

business_kid · 06-15-2019, 04:38 AM

I have Current atm and this minor irritation in suspend. If I have a usb drive mounted when I hit suspend, it stays mounted as sdb1. When coming back from suspend, sdb1 is already taken, so it defaults to sdc1, which actually upsets a lot of things here.

I'm even irritated to contemplate using a UUID for sdb, but if it's not force unmounted, I don't know if it will solve anything.

Any ideas, or are there realities I have to work around?

Didier Spaier · 06-15-2019, 04:41 AM

Name it with its UUID.

w1k0 · 06-15-2019, 05:52 AM

Alternatively you may use suspend script to unmount and mount the device:

suspend

Code:

#!/bin/bash

# suspend: suspends the system to RAM

# check the present virtual terminal
FGCONSOLE=`fgconsole`

# switch to virtual terminal 12
chvt 12

### umount /mnt/sdb1

/sbin/hwclock --systohc

sync

# suspend-to-ram
echo -n mem > /sys/power/state

/sbin/hwclock --hctosys

### mount /mnt/sdb1

# switch back to virtual terminal running X
chvt $FGCONSOLE

***

Well, maybe I missed something but I just suspended the system with mounted USB drive using the above script without those umount and mount commands and when I resumed it USB drive was still mounted as /dev/sdb1.

Tonus · 06-15-2019, 12:33 PM

Just wondering : what does "hit suspend" mean?
I haven't experienced this but use dbus to hibernate (I do not suspend often), not the direct suspend with root privileges...

business_kid · 06-16-2019, 04:30 AM

Quote:

Originally Posted by Tonus

Just wondering : what does "hit suspend" mean?
I haven't experienced this but use dbus to hibernate (I do not suspend often), not the direct suspend with root privileges...

Usually just hit the 'suspend' option in in XFCE. I have also used slackware's 'pm-suspend, & 'echo mem > /sys/power/state' but didn't notice either fixing the problem.

business_kid · 06-16-2019, 04:47 AM

Quote:

Originally Posted by w1k0

Alternatively you may use suspend script to unmount and mount the device:
[SNIP]
Well, maybe I missed something but I just suspended the system with mounted USB drive using the above script without those umount and mount commands and when I resumed it USB drive was still mounted as /dev/sdb1.

Very nice thank you.
I'll probably stick in an 'if' condition to check if sdb1 is actually mounted to save it spewing 'sdb1 not mounted' errors

@Didier Spaier: I was trying to figure out what the box would do when sdb1 was firmly mounted and it came across sdc1 with an identical UUID

business_kid · 06-16-2019, 09:02 AM

Actually, now that I think of it, the script has a few niggles.

The 'umount' command will fail if anyone has cd'ed into the drive, or if any file is open.
Unless I change something internally, the resume side will never run. If it does run, it will mount sdb1 as root, so my luser cannot write to it.

There's a bit more work to go in here, checks, balances

business_kid · 06-16-2019, 09:51 AM

Hey, Didier, I put that single UUID into /etc/fstab as /mnt/hd. To make a long story short, I could not mount it as anyone for love or money. 'mount /mnt/hd' failed as luser or root.

Put sdb1 back in, and everything worked.

Tonus · 06-16-2019, 12:40 PM

Was it the device uuid or the partition's uuid? Made the mistake a few times here...

business_kid · 06-17-2019, 04:47 AM

Quote:

Originally Posted by Tonus

Was it the device uuid or the partition's uuid? Made the mistake a few times here...

Yeah, It's ease done. I did

Code:

bash-5.0$ ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Jun 17 10:26 28b17366-1d6e-4edf-80ae-9572932428d3 -> ../../sda6
lrwxrwxrwx 1 root root 10 Jun 17 10:26 31aa9e0e-fd75-4042-b6f6-e80eaf38c100 -> ../../sda5
lrwxrwxrwx 1 root root 10 Jun 17 10:29 348661f5-73b1-49de-bcf0-deb0d538e045 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jun 17 10:26 74d16e12-be9b-41cd-aa8f-5ca2bb28c8cc -> ../../sda3
lrwxrwxrwx 1 root root 10 Jun 17 10:29 7BFBBA3513627C8B -> ../../sdc1
lrwxrwxrwx 1 root root 10 Jun 17 10:26 82042242-a5d5-472c-92fb-ab8fc0cb7814 -> ../../sda7
lrwxrwxrwx 1 root root 10 Jun 17 10:26 b813280e-533f-49dd-8759-1677795b2e17 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jun 17 10:26 f06b152f-9794-4af2-91b1-7405848c16c8 -> ../../sda2

then I copied the "348661f5-73b1-49de-bcf0-deb0d538e045" bit with the mouse and pasted it. Was that wrong? I generally avoid UUIDs for the reason that they're a PITA.

Didier Spaier · 06-17-2019, 07:52 AM

It depends how you write the line in /etc/fstab.

For instance here:

Code:

didier[~]$ ls -l /dev/disk/by-uuid|grep /sdb3
lrwxrwxrwx 1 root root 10 Jun 17 08:34 b8d9d6ba-f993-466a-a243-04b63156485b -> ../../sdb3
didier[~]$ lsblk -l -o name,uuid|grep sdb3
sdb3 b8d9d6ba-f993-466a-a243-04b63156485b
didier[~]$ cat /etc/fstab|grep b8d9d6ba
UUID=b8d9d6ba-f993-466a-a243-04b63156485b /slint64 ext4 defaults 1 0
didier[~]$

Comments:

lsblk is easier to use in my opinion.
Here the uuid is the one of the file system. It will change if I create a new file system in the partition. So, better use parttuid instead (the UUID of the partition, not of the file system). For instance:
Code:
```
didier[/tmp]$ lsblk -l -o name,partuuid|grep sdb3
sdb3 91ca468c-03
didier[~]$ cat /etc/fstab |grep 91ca468c-03
PARTUUID=91ca468c-03 /slint64 ext4 defaults 1 0
```
The advantage is that if you reformat the /dev/sdb3 (without modifying the partition table) its partuuid won't change, hence no need to modify /etc/fstab.
As an aside, patches have been proposed to search partitions by partuuid in GRUB. Unfortunately probably too late to be applied in incoming version 2.04

business_kid · 06-17-2019, 12:45 PM

Code:

bash-5.0$ ls -l /dev/disk/by-uuid
total 0
…
lrwxrwxrwx 1 root root 10 Jun 17 16:06 348661f5-73b1-49de-bcf0-deb0d538e045 -> ../../sdb1

And in /etc/fstab

Code:

UUID=348661f5-73b1-49de-bcf0-deb0d538e045 	 /mnt/hd  	  auto	      noauto,relatime,diratime,user,exec,dev,suid,nofail     0   0

jostber · 06-20-2019, 04:29 AM

You can make a rule for your USB port and give it a persistent name with udevadm?

http://weng-blog.com/2017/05/udev-rule/

business_kid · 06-21-2019, 04:28 AM

Quote:

Originally Posted by jostber

You can make a rule for your USB port and give it a persistent name with udevadm?

http://weng-blog.com/2017/05/udev-rule/

Clever idea, and thanks for that. I read that link. It may solve the remounting half of the problem, but it doesn't get it unmounted before suspend. We also have the question of what error the system would throw on the remount of an already mounted device/uuid on an already used usb port. But permissions are fussy; I need a root force-unmount, and a user remount, so the user can write to it.

At this stage I'm convinced the user will have to change his habits. There's the guts of a working solution between the script in post #3 (un-mounting) and your idea re-mounting. Frankly, by the time I implement that, there's probably an update due anyhow. I was hoping for something simple, and it's not out there.

jostber · 06-21-2019, 06:09 AM

A bit more risky, but possibly useful?

USB-persist:

https://www.kernel.org/doc/html/late...b/persist.html

Check also disabling USB autosuspend:

https://wiki.archlinux.org/index.php...SB_autosuspend