Yesterday I was surprised to see that with *another* external USB diskhappening to be connected before boot,the system booted with root partition device sdb1 assigned rather than sda1.Not thinking much, I then proceeded putting the system into suspend,only to be even more surprised to then end up with swapped device nodespost-resume and the system killed(I *know* that device nodes ended up jumbled since the root device contains"root" plus "swap" partition device node, whereas the "other" USB devicecontains one partition only,and the set of partition device nodes as still successfully looked up vials -l /dev/sd*ended up exactly reversed after system resume).I attempted to get dmesg off this system, however not even plain sector writingof my /tmp/dmesg.log to a new USB device worked since "dd" segfaulted.Also, no network access of course.

The thing is, /sys persist nodes *are* all set to 1 for any affecteddevice (at least as observed after the subsequent fresh boot).

The plausibility of the previous killed boot having had "persist"attribute set as well for all devices is VERY high(there were no changes/updates in system software configuration done,thus settings should have been identical).

Thus I'm highly puzzled as to why with USB persistence *activated*it still decided to jumble device nodes on this system resume.Content of the pathological dmesg log didn't contain any mentioningof any "persistence" mechanism activity, BTW, AFAIR.

Netbook Acer Aspire One A110L.Running 3.5.0-rc7+ here (yes ma'am, bleeding edge tester :).Was the first time to attempt resume with an additional device remainingconnected, IIRC - that -rc7 thing likely doesn't play much of a role here.A bit hesitant to (dis-)prove the bug's "regression flag" with another versionsince random possibly succeeding I/O accesses to incompatible devicesare not necessarily my thing (or is this safe to attempt again? Any morespecific session info one would need?).