Puppy Linux Discussion Forum

fredx181 wrote: ↑Thu Mar 10, 2022 8:20 pm

To hurt your grey cells just a little more : About the kernel panic (starts with switch_root message), it's happening for me when booting from FAT32 and with w_changes=RAM2
Probably has to do with save to folder not supported on FAT, would be nice if there's a message e.g. "not supported" and it can continue in RAM0, perhaps not easy as it needs some checking if FAT32 or if savefolder is supported or not.

Ok... easy enough to detect. I'll think about it, but will also check why it crashes anyway.

@wiak,

I swapped in initrd_v503-rc1.gz and w_init_503-rc1.sh into a beta5 test platform and it booted fine and everything works it seems. Running very smooth and is very responsive.

Also added the loop.cfg changes to /boot/grub

beta5 will have the 5.16.12-RE kernel, initrd_v503-rc1.gz plus update upgrade and will soon be available.

rockedge wrote: ↑Fri Mar 11, 2022 1:23 am

@wiak,

I swapped in initrd_v503-rc1.gz and w_init_503-rc1.sh into a beta5 test platform and it booted fine and everything works it seems. Running very smooth and is very responsive.

Also added the loop.cfg changes to /boot/grub

beta5 will have the 5.16.12-RE kernel, initrd_v503-rc1.gz plus update upgrade and will soon be available.

That's good, will give a better test of initrd_v503, which needs a thorough checking though I'm hopeful it will be fine and it is certainly better in terms of dealing with booting from iso. I'm about to look into the kernel crash that occurs when trying to boot from FAT32 with RAM2 mode - not that a person should be using that mode with FAT32 anyway really, but nice to understand and default to RAM0 rather than crash it's true. No hurry on it though - looking at it now but for a later release.

Clarity wrote: ↑Thu Mar 10, 2022 10:44 pm

BTW: My above post is NOT in support of SG2D. But if our discussion leads to an improved manner to make it all-too-easy for any user to step into this KLV, that is a bonus for KLV expansion and increased use.

We're not addressing this for SG2D, rather we addressing this for direct ISO booting (which it does) and maintaining session files after desktop emerges. ... I think.

I would not deny that SG2D is itself a useful idea (though I don't find its menu very user-friendly at all), and personally I much prefer using it to Ventoy (though maybe I simply don't understand Ventoy). Certainly the new WDL initrd developments are useful for iso boot generally so that's the main reason they are worth doing. My problem with SG2D is primarily that it uses older version of grub2 now, its sole author keeps suspending its development (which is no use for any system to be universally adopted) and also SG2D requires grub2 compiled with lua support (Lua is not part of official grub and therefore not in main upstream repos grub2 releases). I have no doubt lua is a great scripting language for use with grub2, but for various reasons it is not in official releases.

Don't know if it is possible, but it would be nice if we could do our own SG2D-like boot system that uses official grub2 internal scripting language (if sufficiently powerful):
https://www.gnu.org/software/grub/manua ... pting.html

grub.cfg is written in GRUB’s built-in scripting language, which has a syntax quite similar to that of GNU Bash and other Bourne shell derivatives.

Oh well, dreaming... back on topic.

*see below

wiak wrote: ↑Fri Mar 11, 2022 1:37 am

rockedge wrote: ↑Fri Mar 11, 2022 1:23 am

@wiak,
That's good, will give a better test of initrd_v503, which needs a thorough checking though I'm hopeful it will be fine and it is certainly better in terms of dealing with booting from iso. I'm about to look into the kernel crash that occurs when trying to boot from FAT32 with RAM2 mode - not that a person should be using that mode with FAT32 anyway really, but nice to understand and default to RAM0 rather than crash it's true. No hurry on it though - looking at it now but for a later release.

You know I'm looking at where you guys went with this after I brought up booting from SG2D, and it's pretty amazing, because the funny thing is I only booted SG2D because I ran into kernel panic on a regular USB frugal install -- a problem that I didn't experience when using the same approach with KLV.beta-1/2. However, I'm not, and haven't been using a fat32 partition, it's ext4, and I'm not sure what was different this last go-round. Since you're already at beta-5. I'm not going to try too hard to figure it out, though I might give beta-4 another try as a frugal-copy-the-files-and-run-grub4dos USB install. Just to see if I was doing something different. I think the thing that might have been different is that grub4dos wrote menu1st entries with UUIDs. And I'm not sure why exactly. I tried swapping in other boot commands, but with no luck. I believe when I ran grub4dos on beta-1, I didn't include any of the iso's boot files. On beta-4 I tried including them and also excluding them with no joy. So I might take another stab at it for my own educational purposes.

SG2D has it's merits, but it's no panacea, and I personally run frugal internal HD installs on ext4 partitions with any system I really like. SG2D allows for testing though, in that it's easy to copy an iso to a stick and just boot, that is if the loopback filesystem actually plays nice that way. That is beyond my scope, as when I look at those system directories that say pup_ro4 and such, I immediately get out of there before I screw something up by accidentally dragging or clicking. In other words, they look pretty scary, and recursively ominous.

I'm just kind of tagging along for the fun. I'm the layman tester.

Just confirming that w_init can be placed externally also under BOOTISOS/ directory with SG2D boots. That's very useful in many ways. For one, makes debugging the boot very easy indeed... But also means more advanced users of the system can easily tweak the w_init for extra functionality (extra sfs addons and whatever).

But main thing is ease of debugging. Don't need to make video of boot on my phone to see what's going on (always misses key frames that method anyway...).
Turns out RAM2 mode fails on mounting overlay to merged when uc_ro is a FAT32 layer - not overlay surprising (pun). Thereafter, successfully gets to the switch_root end line in w_init but since the overlay mount didn't work you get the kernel crash at that point.

Working on best reaction per Fred's request, but going out for pizza now (what a life...)

Okay! I finally got the straight up frugal USB install to work. I didn't run grub4dos, instead I included the iso boot folder on the USB stick, and moved grld & menu.1st to the top directory. I also edited the menu.1st lines by taking out sr0 and replacing them with sdb1.

That booted and gave me the snappy looking KLV-Airedale boot screen, and I chose the top entry which is RAM0. It booted successfully, HOWEVER, I saw something quite confusing, and I still need to check it out., What I saw was a contorted version of my Fossapup desktop (which is on sda1 - SSD) until KLV fully booted. It was as if the Fossa desktop was still in RAM or something. But that did go away and the normal KLV desktop became available. Then, I rebooted to see if it would happen again, and it did not. So a strange and flukey thing that was. I was afraid my savefile merged or something.

KLV beta-4 seems to be running normally after the above adjustments were made to the boot stick.

Now I will check and see how my Fossapup install is doing.

EDIT: Fossapup's tail is still waggin'

New save2flash v1.1_0 , it does some more checking now if correctly setup for save changes on demand (e.g. if /mnt/layers/uc_ro exists and added also check for possibly booted with option w_changes1=RAM2) and should give message if it cannot save the changes.
EDIT: Info e.g. about usage: viewtopic.php?p=50707#p50707

EDIT: @rockedge one thing I wanted to say earlier but forgot:
the package contains /etc/rc.shutdown , i.e. will overwrite existing, which is not what I really like, tried initially to make it a runit service (shutdown save) but couldn't make it work correctly. If you have a problem with that, we could try to do it different way perhaps.

@rockedge Hi Erik, regarding the problem you wrote about that it's not possible to login/logout from console, to be able to login as e.g. user weedog; don't know if you seen this post about a workaround: https://www.reddit.com/r/voidlinux/comm ... just_once/

I went through the steps and initially couldn't make it work, but found that the 'conf' file needs editing too (and wanted to prevent autologin on all tty's) so modified my own way that I thought would be easiest to accomplish in KLV, and should work OK, here's how:

- Extract autologin-fix.tar.gz

- Copy 'conf' (and overwrite existing) to /etc/sv/agetty-autologin-tty1/
- Copy 'run' (and overwrite existing) to /etc/sv/agetty-generic/
- Reboot (probably required, not sure though)

EDIT: But if you follow the exact procedure from the reddit post, it may work too, it's advice there is to create a separate "agetty-autologin-tty1' (not linked to agetty-generic).
EDIT2; FYI, to login as e.g. weedog : login weedog I say this because I'm used to just type login first, but that's apparently not the way in Void.

I have installed and logged out and back in as spot and then logged out again to return to root.

When I am logging out via Logout button it drops to console where I type logout to get to the login prompt.

I have to try out the reedit method as well. But your mod is working. I did reboot after initially installing the changes

UPDATE: @fredx181 Fantastic stuff!!! Working really well using this modification. I am posting this as spot. This is now using a true multi-user approach and very much increases KLV-Airedale's versatility.

rockedge wrote:

UPDATE: @fredx181 Fantastic stuff!!! Working really well using this modification. I am posting this as spot. This is now using a true multi-user approach and very much increases KLV-Airedale's versatility.

OK, GREAT! It, looks like, from what I quickly tested, that it's indeed a true multi-user system, no trick available to get back in root once logged in as e.g. spot without knowing the root password, which is how it should be IMO.
(on Debian Dog it's not so good, once you know how, you can easily get back to being root, need to install a login-manager for true multi-user)

geo_c wrote: ↑Fri Mar 11, 2022 2:36 am

the funny thing is I only booted SG2D because I ran into kernel panic on a regular USB frugal install -- a problem that I didn't experience when using the same approach with KLV.beta-1/2. However, I'm not, and haven't been using a fat32 partition, it's ext4, and I'm not sure what was different this last go-round. Since you're already at beta-5. I'm not going to try too hard to figure it out, though I might give beta-4 another try as a frugal-copy-the-files-and-run-grub4dos USB install. Just to see if I was doing something different. I think the thing that might have been different is that grub4dos wrote menu1st entries with UUIDs. And I'm not sure why exactly. I tried swapping in other boot commands, but with no luck. I believe when I ran grub4dos on beta-1, I didn't include any of the iso's boot files. On beta-4 I tried including them and also excluding them with no joy. So I might take another stab at it for my own educational purposes.

You should never assume that all is well just because developers are installing and saying all is fine. When you run into issues it is really best if you always publish what is going wrong in case it is an actual bug that could be fixed if we knew about it.

Here is a very related (not so funny) story:

I hardly ever boot from usb sticks, and hardly thus test WDL initrd is booting from usb okay. However, because I have been trying SG2D from usb stick I decided to try a normal frugal install on the same stick to check RAM0 mode could work with FAT format as well as Linux format partition.

Well... I made the frugal install and it crashed on boot.. Gave weird reason I couldn't figure out.
I took same usb stick to a newer computer I have and found it booted perfectly on that one...
So... I immediately thought (and who wouldn't?): must be usb driver maybe kernel related - doesn't work on the old machine. But I wanted to see where it failed.
So I spent HOURS trying and trying again on the old machine - uncompressing the initrd to put debug statements all over its init script. But the error message I was getting didn't actually make any sense at all to me (at the time - actually it makes perfect sense but I was being dumb). I was echoing back the mountfrom and w_bootfrom variable contents at various places in init and it was saying something like 7979-f9800-0808-08080/KLV-Airedale, where the first (unexpected) number I knew to be the UUID. Why is that number appearing in the variable I thought - that was breaking simple cd commands? I knew it all came down to function _fs_find, so I put a debug statement in there...

BUT... what the hell's going on????, the debug statement I put in the _find_fs function never gets reached despite the init code definitely saying to call function _find_fs!!! So... then all logic vanishes, and my brain tells me all the laws of Linux no longer apply cos something is breaking kernel working on this old machine... (that's what my daft brain told me at least).
Anyway, was going round in circles, so if kernel related, I thought, best to try a different kernel/modules combination... Oh, guess what, I temporarily installed fossapup64 on same FAT partition on usb stick and it booted perfectly fine!!!! But that's good I thought - I can try its kernel/modules in my KLV install and all should now be fine my perfect logic told me.
Nope - even with known to work fossapup kernel I still could not boot KLV-Airedale from my usb stick... tearing my hair out by this time - hours were passing.
Some of this happened last night when I was really tired, so got back to it this morning. Spent a further TWO hours getting nowhere this morning - this flipping old computer is USELESS I thought (worse thing is that its the machine I do most dev work on...). All, as I said, worked fine on newer laptop.
All sorts of daft thoughts going through my head by this stage. Oh my goodness, I'm imagining, this old machine is going to need me to write special new search routines to find the sub-directory KLV stuff is in - after all SG2D uses that and it boots fine on the old machine. Oh no, I thought, that will be tons of work changing the init with lots of new function code instead of busybox method I'm using... Or maybe I just give up on old machines - and tell the forum not guaranteed to work on old rusty laptops.

It just didn't really make logical sense, though, that a function wouldn't be entered when definitely called inside the script... Well... who knows, maybe some memory management madness I know nothing about!!! By this stage I believed anything and that normal Linux theory simply didn't apply to this special machine anymore.

But then, after that few hours the night before and a couple more hours today. Suddenly I took a deep breath and somehow my brain switched on...
The debug error message (given by pretty much all of my debug statements) was:

variable w_bootfrom (and usually also w_mountfrom) contains 7979-f9800-0808-08080/KLV-Airedale

At the end of the day, it was 'supposed to' contain something like: /mnt/sdb2/KLV-Airedale, and NOT that flipping number (the blkid UUID of the usb partition).
because: cd /mnt/sdb2/KLV-Airedale will work, but, cd 7979-f9800-0808-08080/KLV-Airedale will definitely NOT!!!!! aaaaaaagh!!!!!

I checked my menu.lst (on the old computer) and NOTICED it had this (extract):

w_bootfrom=C98F-1850=/KLV-Airedale

It SHOULD HAVE BEEN (I say swearing and with my hair now looking like Einstein's):

w_bootfrom=UUID=C98F-1850=/KLV-Airedale

Yeah... I had it correct on the newer laptop. NOTHING WRONG WITH KLV-AIREDALE!!!! Plenty wrong with my brain - not even understanding my simple debug error messages that were trying to tell me exactly what the error was, but I just didn't trust the old machine and the new kernel and was thus unable to see the obvious.

So the story has a happy ending. I fixed my menu.lst and all working fine booting from frugal install on my usb stick on this old WONDERFUL dev computer of mine. Back to some real dev work now.

wiak wrote: ↑Sat Mar 12, 2022 12:40 am

Yeah... I had it correct on the newer laptop. NOTHING WRONG WITH KLV-AIREDALE!!!! Plenty wrong with my brain - not even understanding my simple debug error messages that were trying to tell me exactly what the error was, but I just didn't trust the old machine and the new kernel and was thus unable to see the obvious.

So the story has a happy ending. I fixed my menu.lst and all working fine booting from frugal install on my usb stick on this old WONDERFUL dev computer of mine. Back to some real dev work now.

Which is kind of the same idea with my frugal USB stick. It finally dawned on me, "what if I just copy grldr and menu.1st to the top level and edit menu.1st to point to sdb1. Bingo, it's that simple, but I had to kernel panic about 5 times before I was able to accept the obvious solution.

@rockedge and @fredx181

I've re-uploaded the loopback.cfg file I made since had the title details wrong for non-RAM2 mode.

https://weedoglinux.rockedge.org/viewto ... p=355#p355

I'm working on the default to RAM0 mode initrd change for if user tries to use RAM2 when FAT32 formatted partition.

@wiak I will wait for the changes to be able to insert them into beta5 before I upload it.

So far it is working very nicely as I test it.

wiak wrote:

I'm working on the default to RAM0 mode initrd change for if user tries to use RAM2 when FAT32 formatted partition.

While you are at it, I'd suggest to add 2>/dev/null to the mount line in function mount_partition while ! mount $3 /dev/"${1}" /mnt/"${1}" 2>/dev/null; do in the init.
Otherwise it could show error message about mounting failed a couple of times which may look as if something's wrong, while in fact there is not (waiting...., boots fine in the end).

Also I found that the crashing on FAT32 is not only with w_changes=RAM2, it occurs also for me when boot line is without w_changes= (but that seems logical, perhaps needless to mention).

@rockedge Just saying, if you include the autologin fix, don't add /etc/sv/agetty-autologin-tty1/supervise/did-autologin in the rootfs sfs (but you may have thought about yourself), otherwise autologin may not work, I think (btw, I think any 'supervise' shouldn't be included in general edit: scratch that, in fact I really don't know).

Have uploaded latest WDL skeleton initrd_v504-rc1.gz

Auto changes to RAM0 mode if underlying w_changes (or w_changes1) partition is FAT32 or ntfs. This was tricky for my grey matter since there are many different modes that had to be accounted for. Hopefully I haven't messed anything up - needs thorough testing, but worked fine for me in my limited tests.

Note that it should be possible to boot from FAT32 or ntfs, but also with save persistence if arranged to be on a Linux format alternative partition/dir (via combination of w_changes specifying save partition/directory location and w_changes1 specifying the mode) but I haven't tested that part for now.
EDIT: that w_changes1 part not working yet - not important right now, but will work on for later version.
EDIT2: Correction... It IS working. I just tried again. In the following w_bootfrom is ntfs partition at my /mnt/sda2/klv1 directory, and w_changes is ext4 partition, where save persistence tested as correctly working to that ext4 partition /mnt/sda4/test/upper_changes directory (tested also with symlinks). Should also be able to add w_changes1=RAM2 to this menu.lst stanza (EDIT3: Yep, tested RAM2 too, and with fred's new save2flash - that all worked too with ntfs bootdir and ext4 changes; it's all go...):

title KLV1
  find --set-root uuid () 16ACF2DDACF2B679
  kernel /klv1/vmlinuz  w_bootfrom=UUID=16ACF2DDACF2B679=/klv1 w_changes=UUID=9f8b9e81-9c04-41ca-ace0-d37b1787a94d=/test
  initrd /klv1/initrd_v504-rc1.gz

One nice thing is that most of the code changes actually occur in w_init, so since that can also be placed external to the initrd it is easy to tweak, debug, and experiment further (and that external w_init also works with SG2D, if you happen to be using that, if placed in BOOTISOS folder). Same facilities will also work with all the weedogit.sh distros of course.

Obviously, I could have mucked something up or missed some major detail. Do please let me know and I'm sure I will do my best to remedy prior to getting back to my coffee.

Download of the get_WDLskelinitrd504rc1.sh.tar script is from the usual place (along with that loopback.cfg file): https://weedoglinux.rockedge.org/viewto ... p=355#p355

Hi @wiak tested the new initrd.gz and didn't work as it should IMO (or I'm missing something).
My GRUB2 stanza, booting from USB sdb1, FAT32 formatted:

menuentry "KLV-Airedale-beta4 - changes RAM2 mode" {
insmod part_msdos
insmod ext2
set root=(hd0,1)
	linux /AIREDALE/vmlinuz w_bootfrom=/mnt/sdb1/AIREDALE net.ifnames=0 w_changes=RAM2
	initrd /AIREDALE/initrd.gz
}

Initially replaced only initrd.gz with the new one, when booting, I got kernel panic, the same as before.
Then noticed the w_init_504-rc1.sh script (downloaded to the AIREDALE dir) and thought maybe should be renamed to just w_init, which I did.
Rebooted and this time it booted OK (as it seemed) with a message (can't remember exactly, but should be the msg that you added I think).
But... then I noticed that /mnt/layers/uc_ro existed (which shouldn't be, I think, when in fact booted with RAM0).

So now I don't know what to do with save2flash as it checks already for w_changes=RAM2, w_changes1=RAM2 and the existence of uc_ro (but that's another problem).
Hopefully I'm not torturing your grey cells to much with this

EDIT: Weird... tried exactly the same again and see no /mnt/layers/uc_ro, sorry gotta take back the above, will test more tomorrow, but for now it seems fine.

Beta5 is uploaded and ready download and test!

• Beta5 has wiak's WDL skeleton initrd_v504-rc1.gz and w_init_504-rc1

• also includes the logout logic provided by fredx181 gives true mulit-user support.

• replaced loop.cfg to the most recent modifications.

• newly compiled kernel 5.16.14-RE is used

Plus the other important improvements contributed by the KLV team.

Link is in the first post or go to https://rockedge.org/kernels

@wiak

fredx181 EDIT in previous post wrote:

EDIT: Weird... tried exactly the same again and see no /mnt/layers/uc_ro, sorry gotta take back the above, will test more tomorrow, but for now it seems fine.

Hi @rockedge Tested beta5, first observations:
The save2flash updated version is not installed (required to match with wiak's new initrd) viewtopic.php?p=52051#p52051 perhaps you missed it.
And content of /home is all owned by root (again ) so couldn't login as spot.

fredx181 wrote: ↑Sat Mar 12, 2022 7:51 pm

Hi @rockedge Tested beta5, first observations:
The save2flash updated version is not installed (required to match with wiak's new initrd) viewtopic.php?p=52051#p52051 perhaps you missed it.
And content of /home is all owned by root (again ) so couldn't login as spot.

Looks like we need a beta6 to include Fred's updates save2flash version and correct permissions for normal users in /home. I'll wait for that one prior to further testing then.

Beta6 with the small repairs ready for download, otherwise the same as beta5......
See first Post for the link

@fredx181 , @wiak Hopefully the little fixes are complete! Testing so far looks good but I am not really doing the out of the ordinary setups.

rockedge wrote: ↑Sat Mar 12, 2022 11:16 pm

Beta6 with the small repairs ready for download, otherwise the same as beta5......
See first Post for the link

@fredx181 , @wiak Hopefully the little fixes are complete! Testing so far looks good but I am not really doing the out of the ordinary setups.

Yes, thanks, logout/login works and the other things are fixed.
---------------------------------------------------------------------------------------------------------------------------------
@wiak It's ok on FAT32, switches to RAM0 if RAM2 specified.
But booting from my USB sdb2 ext4 filesystem I cannot save changes, booting with RAM2 gives the same message as with FAT32 and /mnt/layers/uc_ro is not created, part of my boot line:
w_bootfrom=/mnt/sdb2/aire net.ifnames=0 w_changes=RAM2
And when booting without w_changes= it went the same (with previous initrd it created upper_changes automatically), FAT32 message and no changes saved.

fredx181 wrote: ↑Sun Mar 13, 2022 8:21 am

But booting from my USB sdb2 ext4 filesystem I cannot save changes, booting with RAM2 gives the same message as with FAT32 and /mnt/layers/uc_ro is not created, part of my boot line:
w_bootfrom=/mnt/sdb2/aire net.ifnames=0 w_changes=RAM2
And when booting without w_changes= it went the same (with previous initrd it created upper_changes automatically), FAT32 message and no changes saved.

Okay, I'll test it out. Not much testing been done yet. I usually use UUID method since usb can randomly sometimes change assigned sdX drives, but still it should be made to work (and maybe UUID problematic too - haven't checked yet).

fredx181 wrote: ↑Sun Mar 13, 2022 8:21 am

Code: Select all

w_bootfrom=/mnt/sdb2/aire

Yes, I can confirm the new initrd is not working with that w_bootfrom format, so the first of the following is giving all the ntfs and so on messages and not working, and the second UUID method is working fine. I haven't used the first form for a long time so I didn't notice in my earlier tests. Looking into it now.

Doesn't work:

title KLV1 on usb sdb2
  find --set-root uuid () a19d2682-ec90-45b2-88a5-dcf689676e32
  kernel /klv1/vmlinuz  w_bootfrom=/mnt/sdb2/klv1 w_changes=RAM2
  initrd /klv1/initrd.gz

Works:

title KLV1 on usb sdb2
  find --set-root uuid () a19d2682-ec90-45b2-88a5-dcf689676e32
  kernel /klv1/vmlinuz  w_bootfrom=UUID=a19d2682-ec90-45b2-88a5-dcf689676e32=/klv1 w_changes=RAM2
  initrd /klv1/initrd.gz

EDIT: I know what it is. Small missing detail needed for that w_bootfrom=/mnt/sdb2/XXXX format that is already done for UUID and LABEL methods. Will upload fixed initrd v505rc1 soonish.

Yes, can confirm, tested with UUID and works well.

@rockedge With the new kernel I have no boot delay anymore (that I mentioned a while back, 30 sec delay on my 15 years old HP laptop)

Everything seems fine with Beta6 here. Admittedly, I'm not running many of the tests you guys are....which makes my responses of not much use. I seem to have lost some of my enthusiasm for trying stuff like this out in recent years. A sign of getting older, perhaps?

@fredx181 :-

I've been running the Fossapup kernel all the way through, right from Alpha1. It works for me, is rock-solid, and every piece of hardware functions as it should. Boot time to a settled desktop is perhaps 20 seconds? I can live with that. I tend to leave things well alone when they're that stable. No sense rocking the boat.....where's the point?

(*shrug...*)

Mike.

fredx181 wrote: ↑Sun Mar 13, 2022 9:34 am

Yes, can confirm, tested with UUID and works well.

I now have w_changes=/mnt/sdbX/YYYY form booting as well. But... on my machine at least the boot goes to sleep for about a dozen seconds and then gets over its 'issue' and completes booting. No such issue with UUID or LABEl method. Probably some usb wait issue (different code involved to cater for that method than for UUID/LABEL), but the way I mount the partition used to avoid need for extra usbwait amount. At the moment I haven't found a solution (I know where it temporarily 'sticks' but don't see why) so I suggest just using UUID method for now and I'll post update later.