General Questions • Is it possible to reconnect a disconnected live boot device without rebooting?

Hello, and thank you both (Aki and pwzhangzz) for your help.

Debian Live is not the first choice for long uptimes and for use cases when the computer needs to be suspended.

That’s a reasonable take. Indeed, my prolonged use of the “Live” image was neither planned nor intentional. Regular installation will eventually happen! At the same time, it has been running so well that I haven’t felt any urgency to make arrangements for a regular installation!

Thank you, in particular, for pointing me to the article about USB persistence in the Linux USB API documentation. I wouldn’t have found it by myself, and it is quite informative. Interestingly, it says:

This is especially annoying if your root filesystem was located on the device, since your system will instantly crash.

After disconnection of the boot device, a crash is exactly what I would have expected, yet did not experience; and that raised my second question, as I am wondering what’s going on internally. I can only imagine that I owe the continued survival of the system to the file system cache, coupled with the use by “Live” of an overlay file system. My (uneducated) hypothesis is that files that need to be read are first searched in the cache and, if previously read, found there, and the missing device would not even need to be accessed, thus avoiding actual errors; and files that need to be written are written into the upper area of the overlay file system (in RAM), again without the need to access the missing device. And, since I am unable to read additional files from the root file system, the cache does not fill up much further, thus preserving its contents (and enabling the system to remain functional) longer than it would in a more typical configuration. (If that hypothesis is wrong, corrections will be appreciated!) In all cases, longevity has been remarkable (and enjoyable).

You also wrote:

The Linux kernel has a feature to make the device name persist during suspension, but this is not your case. Even if you could get the kernel to recognise the USB drive with the same device name, the file system would probably be corrupted in this situation.

Actually, I can see that “USB-persist” is enabled on my system for the root device (“cat sys/bus/usb/devices/.../power/persist” returns “1”). That‘s likely the reason why the system had been able to seamlessly handle dozens of standby/resume cycles before the January-6 disconnection occurred (an experience mirroring that of pwzhangzz). The use of “USB-persist” should also explain the ability to physically disconnect the device while suspended, as long as it is reconnected before resuming (as reported by pwzhangzz). In that regard, the article about USB persistence states (emphasis mine):

If the re-enumeration shows that the device now attached to that port has the same descriptors as before, including the Vendor and Product IDs, then the kernel continues to use the same device structure. In effect, the kernel treats the device as though it had merely been reset instead of unplugged. The same thing happens if the host controller is in the expected state but a USB device was unplugged and then replugged, or if a USB device fails to carry out a normal resume.

So, then, what happened, in my case, on January 6? My suspicion is that a physically-bad connection (I may have bumped the device by accident) caused the device to be unrecognised. Remember that the log showed the device appearing as a “high-speed” device on bus 1 and no longer a “SuperSpeed” device on bus 2. The kernel would then have logically treated it as a different device upon resuming, as described in the article:

If the descriptors are different from what the kernel remembers, then the treatment is what you would expect. The kernel destroys the old device structure and behaves as though the old device had been unplugged and a new device plugged in.

On the other hand, given that the partition on the root device was mounted read-only (in this case), I was thinking that the file system might not, in fact, be corrupted, and that reestablishing the device as “sda” would have a chance to bring things back to a normal state. After all, isn’t that similar to what the “USB-persist” mechanism does (after verifying that the device is the same)? In any case, it would have been interesting to try it out. Unfortunately, I don’t see any user-space command that could force the kernel to assign a certain name to a block device, and perhaps there isn’t any. Admittedly, this is probably not a common (or even compelling) use case! However, if anyone knows of such a command, I’ll be grateful to be able to read about it, if only for tinkering, experimenting and learning further!

Thanks again!

Statistics: Posted by Picotin — 2024-02-02 06:09 — Replies 5 — Views 276

---