Carlos E. R. schreef op 15-04-16 03:26:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-04-14 19:12, Xen wrote:
I've always been greeted by the exact same GRUB boot menu options whether cold boot or resuming from suspend to disk. So... that's presumably how I could choose the wrong thing. That means your GRUB is controlled by "the other OS".
Shouldn't this sort of thing be a feature to begin with?
I mean.... if you can start another OS while keeping the other one hibernated, why should you not be allowed to do it?
Because if you try to mount a partition that was in use by the other system, it is totally wrecked. It completely trashes your disk.
Carlos, you have a good way of always insinuating that I have not considered yet the answer you are giving. But of course I wrote:
For instance, hibernating one instance and then loading another that has access to the same filesystems, immediately raises the concern of: what will happen if I change something the hibernated instance has open, or anything of the kind?
But of course I didn't know it was that bad (and I don't know if it is). I do not think the state of the mounted filesystem is registered on disk itself, but I could be wrong. That would be a very weird way to do things. In a hibernated instance, nothing should change to the disk except the files that are open, and of course the internal representation. But I do think that if the running system expects the currently mounted partitions -- to have exclusive ownership over it. We once had an issue with that relating to XFS. A regular filesystem driver does not consider changes being done by something else. But networked filesystems might. Anyway. I think you are correct in saying that if a hibernated system resumes on a filesystem that no longer agrees with its internal representation, things might get messed up badly. Provided you share filesystems. But this is the biggest concern because most dual boot systems would. That implies shared filesystems would need to get unmounted and this is not a viable solution. So again, I recommend not doing this sort of thing, not using separate swaps, just use the same swap and do not consider that hibernation strategy. Unless you know what you are doing and take pains not to use the same on-system filesystems (for instance only use shared network filesystems). So my recommendation is, contrary to what Aaron Digulla is saying: "the installer should detect that and warn that you need to be careful when hibernating and suggest to create one swap per install." I would recommend to not make things more complicated, not go and educate users in the freaking installer, suggest one swap (ie. use the existing) and then AFTER issue that warning prior to installing or maybe even better, send the person an email (but not many ...ugh... distributions actually use email to inform users on the local system). Don't warn beforehand, just warn afterhand. Make one swap the default choice and then when you proceed to install, say "Note that you now have two systems running on one swap. When hibernating, make sure not to boot the other system because it will overwrite the hibernate file. Even if you have two swaps, you cannot hibernate one and boot the other if you have any shared filesystems." Then if a user has chosen to make another swap, you might still say "Note that having two swaps in principle allows you to boot one system while the other is hibernated. However, this is severely risky if you have any shared filesystems and they are mounted prior to hibernating. Do not access filesystems mounted by the other OS." And then maybe that should be enough. Or you can prompt the user with a choice as said. But if you don't prompt a choice, the default should be one swap in my opinion, and just warn people after (but before installing most likely) and consider that most users may not even want to do this thing. But you might do it by accident of course. Anyway, Regards. PS. if you have one swap and you mount the other system by accident, that means the hibernate file gets overwritten (?) and you are safe from unwanted side effects from dual-mounted filesystems. You will just have a system that was not "properly" shut down, and that will be all. So I feel one swap is even safer than two swaps. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org