External drives get 're-mounted' on wake-up from 'sleep'...

Using applications, configuring, problems
Post Reply
Message
Author
User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

External drives get 're-mounted' on wake-up from 'sleep'...

#1 Post by Mike Walsh »

Afternoon, everyone.

Got a bit of a 'poser' here for y'all, this time.

Following frenchiveruti's post here:-

http://www.murga-linux.com/puppy/viewto ... 994#978994

.....about how to put a desktop into 'suspend-to-RAM' mode (not a laptop), I've given the command a try:-

Code: Select all

echo -n mem > /sys/power/state
And it works beautifully. Press the power-on button to resume, and everything's restored, as was, within seconds. BUT.....there's a wee problem.

My Seagate external desktop drive is USB 3.0, plugged through a PCI-e 'adapter' card (which is not the issue; this works fine)...and is set to auto-mount its partitions at boot. Depending on the Pup, some mount this as sdc, some mount it as sdg. I have an elderly card-reader gizmo built-in, which invariably occupies mount points sdc, sdd, sde, sdf, or (sometimes) sdg. Some Pups see the Seagate before these, others see it after them.

Here's the problem. When I 'restore' the RAM state by use of the power button, all mounted partitions on the main internal drive are restored as they should be, on the same mount-points as when it went to sleep.

With the Seagate, if the partitions were mounted before 'suspend-to-RAM', upon power-up the previous mount-points are immediately replaced with the following pair of mount points. In other words, if it went to sleep as sdg1/2, it 'wakes-up' again as sdh1/2.

Which plays havoc with all my carefully set up sym-links!

If those 'new' mount-points are not mounted before 'suspend-to-RAM', it returns from 'sleep' with the same ones. So, I guess my main query is this:-

How can I make sure the external drive will 'wake-up' with the same mount-points as when it 'went to sleep'? In other words, what does Puppy do differently during the shut-down or boot processes that it doesn't do during 'suspend-to-RAM'/'waking-up' again?

I've tried modifying the script to first unmount, then remove the mount-points in question.....but this results in the old set of mount-points, plus a new set of mount-points, all showing up on the desktop as drive icons. The old ones no longer mount; the new ones will (of course), but the sym-links have to be manually re-established.....which is not what I want at all!

It currently looks like this:-

Code: Select all

#!/bin/sh
# Suspend Script
#
# To suspend Puppy's RAM state
#
#First, unmount remote drives
#
umount /mnt/sdc1
umount /mnt/sdc2
#
# Then, remove mount_points
#
rm /mnt/sdc1
rm /mnt/sdc2
#
# Finally, suspend to RAM
#
echo -n mem > /sys/power/state

Anybody got any ideas on this one?


Mike. :wink:

jafadmin
Posts: 1249
Joined: Thu 19 Mar 2009, 15:10

#2 Post by jafadmin »

I wonder if this might not have to do with the PCIe card not hibernating right. I know on some of my boxes I need to tell the BIOS that PnP hardware can hibernate ..

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#3 Post by Mike Walsh »

jafadmin wrote:I wonder if this might not have to do with the PCIe card not hibernating right. I know on some of my boxes I need to tell the BIOS that PnP hardware can hibernate ..
Mm. Yeah, I guess that's always possible.....but it still doesn't explain why Pup then creates another pair of mount-points for the Seagate's two partitions.

Why should it do that? Why not re-use the existing ones, after first checking to see if they're actually in use (or not, as the case might be...)

I'm making a wee bit of a 'stab in the dark' here, but I'm guessing this has something to do with the way the Puppy Event Manager works, and all the associated paraphernalia that tags along for the ride....yes??

This is where I start getting lost.....when talk turns to the aufs 'layered' file-system, and the 'dev-loops', and 'pup_ro_1', 'pup_ro_2', etc. It's an indecipherable alien language to me..... :lol:


Mike. :wink:

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#4 Post by Marv »

Hi Mike,

The stock /etc/acpi/actions/suspend.sh script in most pups will not suspend if USB drives are mounted but that was written many kernels ago and I just left that in my modded suspend.sh as it wasn't an issue for me. I do have a PCI-E USB 3.0 card on one machine so I played a bit doing the one line suspend with a USB flash drive mounted on it. I got the same 'mountpoint climbing' you see. By unmounting prior to suspend and forcing a mount to the desired mountpoint on waking up, I get stable mountpoints. The 4 second wait in there is on an i5 laptop and what is required to get a live USB varies widely wrt hardware. The following works for me. I don't have anything else on the USB so it is a bit brutish.. an example only. I don't specify the FS type on the mounts here, could use -t to be explicit there. Twas the minimum I could do to get stable mountpoints.

I'm running LxPupArtful with a 4.14.13 kernel at the moment.

Code: Select all

#!/bin/sh

#presuspend
umount /mnt/sdb*

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

#postsuspend

sleep 4
mkdir -p /mnt/sdb1; mount  /dev/sdb1 /mnt/sdb1 
mkdir -p /mnt/sdb2; mount  /dev/sdb2 /mnt/sdb2 

# a sequence I use to restart my PCI-E card when it shuts down due to hd startup current spike or ???
# you can use Pup-Sysinfo to get the bus and address for your card
#echo "1" > /sys/bus/pci/devices/0000\:03\:00.0/remove
#sleep 1
#echo "1" > /sys/bus/pci/rescan
Just playing,

Edit: If you set up mounts on boot using pmount, they are entered as lines in /etc/rc.d/rc.local. Might use those as examples..
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#5 Post by Mike Walsh »

Hiya, Marv.

Yah, I rather suspected this might involve some heavy-duty 'modding'! I can see this is gonna take me into what I've always considered to be Pup's 'black magic' side... :lol:

I'll take your script as a 'start-point', and see if I can't brush-up on my own rather meagre scripting skills.

One question.....if I may? If this is all part of one single script, what causes Pup to execute the other part of it when 'waking-up'? I'm guessing this is somehow held in RAM for the duration.....does it simply carry on from the

Code: Select all

echo -n mem > /sys/power/state
...point upon getting the 'wake-up call' from the power button?

All information gratefully received..! This is being attempted in Xenial 7.0.8.1 with the 4.9.13 kernel at present; I did a back-up prior to trying this for the first time earlier on; no point being thoughtless at this stage of 'the game'. :)

But I'll worry about that tomorrow. The Sandman, he's a-calling.....


Mike. :wink:

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#6 Post by Marv »

Mike Walsh wrote:
One question.....if I may? If this is all part of one single script, what causes Pup to execute the other part of it when 'waking-up'? I'm guessing this is somehow held in RAM for the duration.....does it simply carry on from the

Code: Select all

echo -n mem > /sys/power/state
...point upon getting the 'wake-up call' from the power button?
Yep, basically it does the very best it can to present you with the system in exactly the state it was prior to that line (running the script and all) and lets you carry on from that point. It's gotten better and better at that with newer kernels IMO. At this time I do nothing at all post suspend in the LXDE and JWM pups I run. I still need to do a restartwm in the XFCE pups to get a clean running system with correct touchpad button mapping etc. Since I only use the USB mounts for 'offline' storage I've not mucked with that. The LXDE pups all have a suspend option in the session/shutdown menu and I play a bit in the pre-suspend part of my script to clean up the visuals, nothing related to the function at all. Have a look at what pmount puts in rc.local. I think it's instructive...

Cheers,
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#7 Post by Mike Walsh »

Hiya, Marv.

Well, your 'rough script' does, with a wee bit of polishing, work nicely.

I've simply tidied it up, added some comments, and increased 'sleep' by 1 second. Looks like this:-

Code: Select all

#!/bin/sh
#
#'Suspend' script for Puppy : Mike Walsh @ 2018 (with grateful thanks to Marv for 
# the 'force-mount' suggestion)
#
#Pre-suspend. Modify/add here to unmount any mounted external drives.
#
umount /mnt/sdg*
#
#Suspend
#
echo -n mem > /sys/power/state
#
#Post-suspend. This will 'force-mount' your external drives back to their original mount-points. Modify to match your drive(s) from above; useful if you wish to maintain sym-links pointing to those drive(s).
# 
sleep 5
mkdir -p /mnt/sdg1; mount  /dev/sdg1 /mnt/sdg1
mkdir -p /mnt/sdg2; mount  /dev/sdg2 /mnt/sdg2
I'm in the 'classic' 570 today. In Xenial, yesterday, I modified /root/.jwmrc-tray to add a 'power-button' to the far right-hand end of the tray, and set to run /usr/sbin/suspend.sh. Which was okay, but not perhaps as tidy as I would have liked.

Today, I hit on the idea of modding the Log-out GUI that the newer Pups now have, instead of the menu's Shutdown 'submenu' which all older Pups used. 570 appears to have been one of the very first to feature this.....and I've always thought it was neater.

It now looks like this:-


Image


(I've simply modified the script for the 'Rebuild menus' button.....which runs 'fixmenus', followed by restarting 'X'. I always tend to do that manually, anyway.)

Wee bit tidier like this, I feel. And more nicely 'integrated'..!

Thanks again for the invaluable assistance. Cheers!


Mike. :wink:
Last edited by Mike Walsh on Sat 20 Jan 2018, 14:53, edited 2 times in total.

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#8 Post by Mike Walsh »

As a follow-on, I was trying to get the modern Puppy's 'LogoutGUI' running in some of the older Pups, which use the Shutdown sub-menu system.

I can get the GUI itself to show up without any problems at all.....but the problem seems to arise when assigning the exec actions to each button. It seems that successive generations of Pup have, unsurprisingly, used successively newer versions of Busybox.....and some of the commands have changed. Even substituting the existing Busybox commands into the newer LogoutGUI doesn't seem to work that well.....and produces some, er, shall we say, 'interesting' results!

Obviously I haven't yet got my head round the differing syntax used in the LogoutGUI; I've been using Slacko 570's as a template, since it seems to have been the very first 'mainline' Puppy to have offered this feature. Personally, I like it; I've never been that enamoured with digging through menus to find stuff.

The logoutGUI uses 'exit:*******' for all those commands assigned to each button, whereas the older Pups use 'exec ******' for each menu command in /etc/xdg/templates/_root_.jwmrc (which is where Pup regenerates the Menu from whenever you run 'fixmenus'.....and in fact the latter commands are exactly what I'd expect for exec actions.)

I've since modified the LogoutGUIs in Tahr 6.0.6, Xenial 7.0.8.1, and Tahr64 to offer the 'Suspend to RAM' feature.....a feature I'm now finding increasingly useful.

I'm going to keep plugging away at this, and hope eventually to be able to offer the new-style 'LogoutGUI' as an upgrade .pet for some of the older Pups.....for anyone else who likes the look of it.

----------------------------------------------

For now, I've modified the /etc/xdg/templates/_root_.jwmrc file in some of the older 5-series Pups to add the 'Suspend to RAM' command.....which looks like this:-


Image


.....and for now, gives me what I want.


Mike. :wink:

jafadmin
Posts: 1249
Joined: Thu 19 Mar 2009, 15:10

#9 Post by jafadmin »

Hey, Mike

I know you have this done & dusted, but sometime if you're curious take a look at this:
http://murga-linux.com/puppy/viewtopic.php?t=112558

This is how I always handle this problem.

jafa
Last edited by jafadmin on Thu 18 Jan 2018, 19:33, edited 1 time in total.

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#10 Post by Sailor Enceladus »

I've noticed a different problem when returning from suspend: if I set my max CPU frequency to 1333MHz in Menu -> System -> CPU Frequency Tool it works, but then on resume from suspend it often clears my change and is able to go back up to 1866MHz. I have also noticed on occasion that "Tap to click" on trackpad magically turns on even though I always keep it off too, though not sure yet if that one is related to suspend/sleep or if it somehow gets modified by something else.

Your "Suspend to RAM" button on the logout GUI looks nice. :)

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#11 Post by Marv »

Sailor Enceladus wrote:I've noticed a different problem when returning from suspend: if I set my max CPU frequency to 1333MHz in Menu -> System -> CPU Frequency Tool it works, but then on resume from suspend it often clears my change and is able to go back up to 1866MHz. I have also noticed on occasion that "Tap to click" on trackpad magically turns on even though I always keep it off too, though not sure yet if that one is related to suspend/sleep or if it somehow gets modified by something else.

Your "Suspend to RAM" button on the logout GUI looks nice. :)
What pup/kernel are you running? On most of the older pups and kernels (pre 4.9.x I'd guess) I added a line to the post-suspend processing to reset the touchpad settings

Code: Select all

flsynclient -s
In Mikes script above as an example it would go after the 5 second pause in the post-suspend stuff. I've never seen the cpu governor change but you could try adding the following line in the same place:

Code: Select all

/etc/init.d/wcpufreq
My suspend script has gotten much slimmer over time which pleases me. I keep up with it because I maintain 6 or 7 laptops and a lappie with a closed lid is much tougher than one left open :)
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#12 Post by Mike Walsh »

Hi, Sailor.
Sailor Enceladus wrote:Your "Suspend to RAM" button on the logout GUI looks nice. :)
Well, now; that's one I found on t'internet after 5 minutes or so searching. I've also made up this one (just last night), using Vectr - the SVG editor I discovered last year.....which is a modification of the power-off button. I'm not sure as I like it, though.....

It's a terrible thing to say for a graphic design nut, I know.....but I cannot get the hang of Inkscape!

Whadd'ya think?


Mike. :wink:
Attachments
suspend-1.png
Alternative 'suspend' icon...
(20.6 KiB) Downloaded 161 times

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#13 Post by Mike Walsh »

Y'know, I really cannot figure this out.....at all.

The above suspend script works beautifully on any Pup up to and including Tahrpup. But in Xenial (where I started this experiment), it still produces that 'nextstep up' set of mount points, and insists on re-mounting the external partitions to these, despite being explicitly told to mount to the 'old' mount-points.

I've tried removing the mount-points both pre- and post-suspend. I've tried using the UUID for the drives. Nothing.....and I mean NOTHING....will prevent Xenial from creating a brand new set of mount points....and mounting the partitions to these.

So what's going on here?

I'm guessing that something else in Pup is taking precedence here, or overwriting something I've chosen with something else that Pup decides should take priority instead. I could be wrong here, but I've always got the impression that a whole bunch of things got changed, altered or modified when Phil was putting Xenial (and the later 606 version of Tahrpup) together.

Let me ask a question here. Could this have anything to do with the fact that these two Pups both employ the combined, 'auto-selected' MBR/UEFI stuff? Is that anything to do with it? Actually, I doubt it, 'cos that's 'boot' stuff.....and Xenial has no problems firing up. /Mnt is part of the file-system.....which at that point is yet to be loaded.

And yet the script works well for Tahr 6.0.6 (uefi) itself. So.....hell, I don't know what's happening here. Unless I can't see the wood for the trees, and am 'over-thinking' this.....

Any takers?


Mike. :wink:

jafadmin
Posts: 1249
Joined: Thu 19 Mar 2009, 15:10

#14 Post by jafadmin »

Mike Walsh wrote: Any takers?


Mike. :wink:
This was solved many years ago by the Unix/Linux folks. They created the solution when plug-n-play was created.

See my 2nd post in this tread ..

jafa

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#15 Post by Mike Walsh »

Hi, jafa.

Well, I gave that a try. I'd heard about 'udev-rules' and such like quite some time ago, but never really knew what it was.

I hate to 'burst your bubble' (and I'm not saying this doesn't normally work), but after 3 successive suspend/resume cycles, starting from sdg 1/2, Xenial still merrily proceeded to re-mount as first sdh 1/2, then sdi 1/2, followed by sdj 1/2.

'MyUSB1' and 'MyUSB2' were doing exactly what they were supposed to do.....but Xenial had somehow transferred the mount-point away from the 'udev-rule'..... How is that even possible? As I understand it, that shouldn't be able to happen, once the 'rule' is set-up; the only thing I can think of is that my Xenial install is somehow 'corrupted', somewhere along the line (although 'e2fsck' gives a clean bill of health - but that only checks the partition file-system. It doesn't check the save-file.....but the boot-time check says it's good).

If I re-run 'trigger-udev' in /root/Startup, it then 'transfers' MyUSB1/MyUSB2 across to the 'new' mount-points.....but that still defeats the object of the exercise, since the sym-links all have to be 're-set' again.

Either that, or this is a 'bug' somewhere in Xenial. I wouldn't like to say, 'cos this Xenial install has done some slightly weird shit from day one (like it's the only Pup I've ever come across that insists on showing the 'extended partition' on my drive as an actual drive icon..?!)

Aside from sundry items of weirdness, everything works as expected.....and it's actually one of the best Pups I run. Suspend/resume works on the other 9 Pups in the kennels.....I think I'll live without it in Xenial.

Thanks for the help, though.


Mike. :wink:

jafadmin
Posts: 1249
Joined: Thu 19 Mar 2009, 15:10

#16 Post by jafadmin »

Mike, the kernel controls the "sd?" device descriptors however it wants. The user has no control over it, and assignments by the kernel are always arbitrary.

What udev does is make sure that regardless of what descriptor the kernel is using for your device, the udev rule will create your persistent descriptor in addition to the kernel descriptor. If you go look in /dev you will find the device descriptors MyUSB1, MyUSB2, etc, created by the udev rule.

At that point you can ignore the system descriptors and just use your own, since they will remain constant regardless.

FYI, I tested this on a Xenial ISO session, and it worked flawlessly.

Puppy is the only Linux I've found that uses the system kernel descriptors directly for USB. Most other Linux's create "friendly name" links to them.


Better yet ..
Below is an improvement in the form of a wizard. It is for folks that are juggling several USB disks and want each to mount by a "friendly" name.

In this implementation you put the wizard files in "/root/udev" which you will need to create.

Now just open a console in /root/udev and run: "./mkrule /dev/sd? FriendlyName"
where "FriendlyName" is frequently the model name, i.e.: "WD-Mybook"

That's all you do. Now you can run it for each USB disk and you will have mountpoints for them in "/", i.e.: /WD-Mybook, etc ..
Attachments
udev-wizard.tar.gz
(1.79 KiB) Downloaded 71 times

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#17 Post by Mike Walsh »

From what I can see of it, the 'suspend/resume-remount' script as thrashed out above only seems to work correctly for the Slackware-based Pups. Using it in the 'buntu-based Pups always results in the 'step-climbing' of the mount-points.....plus a distinct build-up of old & now un-used drive icons that have to be manually cleared out of the way.

This leads me to believe that Canonical & Slackware must be treating the power 'states' in a distinctly different way. jafadmin's suggestion to use the 'udev-rules' does work (after a fashion); extraneous mount-points still get created, but after a manual re-scan of '/root/Startup/trigger-udev'', the mount-points are back at 'MyUSB1/MyUSB2' (as labelled in the script provided.)

So the conclusion I bring away from these 'experiments' is this; that there cannot be one 'universal' suspend script for all Puppies running on a desktop, because of the way the power states are treated in different Pups. Well; there probably could be......but not with my terrible scripting skills. :roll: :oops:

The actual suspend/resume works flawlessly (at least with my hardware it does). It's what the different Pups do with mount-points after resuming from 'sleep' that seems to be the sticking-point.....

I'll get there eventually..!


Mike. :wink:

Post Reply