[opensuse] Re: [opensuse-factory] Feedback needed: swap sharing in the new installer proposal
On 04/13/2016 11:32 AM, Ancor Gonzalez Sosa wrote:
As you may know if you have followed previous blog posts by the YaST team, we are currently redesigning the YaST code for managing and proposing partitioning.
While designing the algorithm that proposes the disk layout for a new installation we came to a philosophical question - should we try to reuse existing swap partitions or should we always create our own?
If the current (i.e. old) installer finds a swap partition that is big enough for our needs, it will use it instead of creating a separate one. Although this can save some space, we are wondering if it's a good idea to do that by default. It effectively means that we will share the swap space with another Linux installation in the same computer. During normal operation that can be fine, but the swap partition is also used for suspend to disk (i.e. hibernate). That means that if we start LinuxA while LinuxB is hibernated, we will make impossible for LinuxB to resume the suspended execution.
Having separate swap partitions is safer from the hibernation point of view, but it consumes potentially valuable space just to make sure that you can run a Linux system while the other is hibernated, which can be considered a pretty weird scenario.
So, what the geckos out there think? Do you prefer to share swap partitions and save space or to have separate ones for better suspend isolation? Is there some implication or use-case that we have overlooked?
In any case, take into account that this will only be the proposed layout. You can always use expert partitioning to make your own.
Cheers.
I have noticed that existing swap is automagically used, when another system is booting. Also, given that swap is only holding stuff that has since closed, in preparation for shut down, there's nothing in there worth keeping. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 04/13/2016 11:32 AM, Ancor Gonzalez Sosa wrote:
As you may know if you have followed previous blog posts by the YaST team, we are currently redesigning the YaST code for managing and proposing partitioning.
While designing the algorithm that proposes the disk layout for a new installation we came to a philosophical question - should we try to reuse existing swap partitions or should we always create our own?
If the current (i.e. old) installer finds a swap partition that is big enough for our needs, it will use it instead of creating a separate one. Although this can save some space, we are wondering if it's a good idea to do that by default. It effectively means that we will share the swap space with another Linux installation in the same computer. During normal operation that can be fine, but the swap partition is also used for suspend to disk (i.e. hibernate). That means that if we start LinuxA while LinuxB is hibernated, we will make impossible for LinuxB to resume the suspended execution.
Having separate swap partitions is safer from the hibernation point of view, but it consumes potentially valuable space just to make sure that you can run a Linux system while the other is hibernated, which can be considered a pretty weird scenario.
So, what the geckos out there think? Do you prefer to share swap partitions and save space or to have separate ones for better suspend isolation? Is there some implication or use-case that we have overlooked?
In any case, take into account that this will only be the proposed layout. You can always use expert partitioning to make your own.
Cheers.
I have noticed that existing swap is automagically used, when another system is booting. Also, given that swap is only holding stuff that has since closed, in preparation for shut down, there's nothing in there worth keeping.
Umm, except when a system has been hibernated. /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-13 23:50, James Knott wrote:
On 04/13/2016 04:50 PM, Per Jessen wrote:
Umm, except when a system has been hibernated.
Since when do you get to choose another OS when coming out of hibernation?
You do, when you have several Linux installed, and the one that hibernated is not the one that controls the master grub. There is, or was, a config option to not disable grub menu on hibernation. Some people hibernate Linux, then boot Windows, close it, then restore Linux. I have done this myself on occasion. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcOyAgACgkQja8UbcUWM1zTXAD/edLZqvqx3KMvHZLAMRzP7N/1 8pdZZ5kQYZXoHn/UmwQBAI6rQiu/aoNVGQyUVrQj9hbkuY/+GWPhhkrxCp6yM2j6 =nAYW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
14.04.2016 01:28, Carlos E. R. пишет:
On 2016-04-13 23:50, James Knott wrote:
On 04/13/2016 04:50 PM, Per Jessen wrote:
Umm, except when a system has been hibernated.
Since when do you get to choose another OS when coming out of hibernation?
You do, when you have several Linux installed, and the one that hibernated is not the one that controls the master grub.
There is, or was, a config option to not disable grub menu on hibernation.
Master grub would not be aware of it, so this option is irrelevant. Instance that hibernates would set it for *own* grub which is not the one that gets loaded by firmware.
On Wed, Apr 13, 2016 at 3:50 PM, James Knott <james.knott@rogers.com> wrote:
On 04/13/2016 04:50 PM, Per Jessen wrote:
Umm, except when a system has been hibernated.
Since when do you get to choose another OS when coming out of hibernation?
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. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op woensdag 13 april 2016 17:10:17 CEST schreef Chris Murphy:
On Wed, Apr 13, 2016 at 3:50 PM, James Knott <james.knott@rogers.com> wrote:
On 04/13/2016 04:50 PM, Per Jessen wrote:
Umm, except when a system has been hibernated.
Since when do you get to choose another OS when coming out of hibernation?
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".
-- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Knurpht - Gertjan Lettink schreef op 14-04-16 09:23:
Op woensdag 13 april 2016 17:10:17 CEST schreef Chris Murphy:
On Wed, Apr 13, 2016 at 3:50 PM, James Knott <james.knott@rogers.com> wrote:
On 04/13/2016 04:50 PM, Per Jessen wrote:
Umm, except when a system has been hibernated.
Since when do you get to choose another OS when coming out of hibernation?
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? I think maybe that is the question you need to ask first. If then the resulting system requires two swaps (for instance) that is a choice. Personally when I construct my filesystems (partitions) I put a swap after root. I rarely hibernate if ever but I plan for it by making it the same size as my memory. Then if I ever decide I don't want the swap or want to place it elsewhere, I have about 4-8GB of room to grow the root filesystem if I need it to. So for me swap is something I tie in with rootfs because my roots are usually quite small (this Kubuntu install has 16GB). If I were to install another distro on the same disk (like some version of OpenSUSE likely, since I am very content with Kubuntu 16.04 and don't really need anything else from that branch) the question whether I wanted another swap would come down to maybe two considerations: - Would I ever want this "hibernate one, boot another" scenario? - Does it bring me any benefit to use a different swap: is the swap of the other filesystem inaccessible? Encrypted or something? Do I want to hibernate at all. Personally I never hibernate but this is no laptop. I only use suspend. Personally I very often will not choose a second swap. Personally I don't really want it. If that means not having hibernate one, boot another, so be it. Dual boot is a horror to me anyway and I look more and more into virtualisation as a choice of how to deal with that. There are certainly virtualizers that can load another system from actual partitions, and if the user interface for that is good, it could maybe for the most part permanently replace actually dual booting something for me. Then maybe you can't have swap for the guest OS. Or you make a small one. I have often considered the question myself when installing another system and I have never chosen to date to create a nother swap, from my recollection. The idea of reusing the same partition feels much nicer to me. So unless the hibernate-boot-another scenario is important to you, I would suggest to not create additional swaps. As a default, I doubt really many people would use it that way, I don't think many people have a real concern for this, if you reboot, maybe expect to shut down your current system, but I don't know. I think there's not really anything bad about it and conceptually maybe it feels nicer to close one instance before opening another. Stop before you start, end before you begin. 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? If everything is logically separated, this never becomes a concern in your mind ever. But now, there may be instances where you need to think about it. Do you want that mental burden? When are you going to know when you need to think about it, and when are you going to know when you don't? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----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. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcQQ1sACgkQja8UbcUWM1xoPwD8DfP7409RrQdGaG0XNvWL/gfh mWA9j7vZBk6wClDqXagA/Ay58sIyp+iFBPj77HoFi5kXFtmDKGF24ko0F22VA6R5 =mNZM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
On 2016-04-15 16:41, Xen wrote:
Carlos E. R. schreef op 15-04-16 03:26:
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.
Well, there is the "dirty" flag, and the journal. Mounting a filesystem "dirty" is normally refused. It has to run fsck first. Depending on case and filesystem type, journal is erased or applied, then then system consistency is checked and corrected. Data on files could still be wrong. When the hibernated system returns, it finds a clean filesystem, but treats it as if it was unchanged from when he went to sleep... it is disastrous.
But I do think that if the running system expects the currently mounted partitions -- to have exclusive ownership over it.
Absolutely.
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.
No, it is the same thing. Only the local kernel can write. A networked mount is similar to multitasking: it is the local kernel who writes, but orders can come from many users and processes, many of them over the network.
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.
I know that I'm correct, because I have done this and had to clean up the disaster. :-} And believe me, it is an horrible disaster. The kind that needs format and restore from backup. Maybe all partitions.
Provided you share filesystems.
Actually, you only need to "list" the filesystem in fstab. Unless there is a "0 0" at the end, the init system will automatically fsck all listed entries, regardless of the need to mount them at the time. And as non listed entries can be automatically managed by systemd, I'm not sure what the situation is currently about "non listed in fstab filesystem" regarding fsck on boot.
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.
Correct.
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."
Something like that, yes.
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."
Right.
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.
Yes.
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.
However... The second system will probably look at the swap and see it has an hibernation image. It may attempt to load it, maybe see the signature does not match the new kernel, perhaps abort. If it doesn't abort, but just disable that swap, disaster may arise. It may erase the image and continue, and then it will see some dirty filesystems it will try to correct. IMHO, it should abort and ask. Maybe the user recognizes the situation and can attempt to boot the correct system in order to close it properly, then retry the second system. Thus, a single swap is way safer. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 16/04/2016 11:44, Carlos E. R. a écrit :
Thus, a single swap is way safer.
looks like nothing is really safe if one hibernate the system that do not control the boot. Is it reasonable (or even possible) to test each swap system and ask if an hibernation image is found? This discussion is interesting, because it makes clear there is no mechanism to lock a file system (that is prevent dual mounting) thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-16 11:52, jdd wrote:
Le 16/04/2016 11:44, Carlos E. R. a écrit :
Thus, a single swap is way safer.
looks like nothing is really safe if one hibernate the system that do not control the boot.
Is it reasonable (or even possible) to test each swap system and ask if an hibernation image is found?
:-? Only the swap indicated in the kernel line is tested. Testing others... I'm unsure of the implications.
This discussion is interesting, because it makes clear there is no mechanism to lock a file system (that is prevent dual mounting)
Well... the mount procedure could store a flag (a file, could be) that contains a signature of the system that mounted it. Kind of a dirty flag on steroids. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 16/04/2016 11:58, Carlos E. R. a écrit :
Only the swap indicated in the kernel line is tested. Testing others... I'm unsure of the implications.
ask is an hibernation image is found if all the swaps are mounted, will there be a warning? The case I had was opposite: if one of the swap was not present (disk removed), the system crashed at boot jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-16 12:04, jdd wrote:
Le 16/04/2016 11:58, Carlos E. R. a écrit :
Only the swap indicated in the kernel line is tested. Testing others... I'm unsure of the implications.
ask is an hibernation image is found
Yes, but the kernel does not search for swap spaces. It is directly told to load a single one, no searching.
if all the swaps are mounted, will there be a warning?
I don't understand this sentence :-?
The case I had was opposite: if one of the swap was not present (disk removed), the system crashed at boot
Yes, the kernel can not boot if one of the components specified in load parameters is wrong: kernel file, init ram file, swap, dunno what more. At that stage, it doesn't search, as far as I know. Grub could search, perhaps. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 16/04/2016 12:29, Carlos E. R. a écrit :
if all the swaps are mounted, will there be a warning?
I don't understand this sentence :-?
if all the swap spaces are inserted in fstab, and one of them hold an hibernation image, what do the kernel do? ask? jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-16 19:02, jdd wrote:
Le 16/04/2016 12:29, Carlos E. R. a écrit :
if all the swaps are mounted, will there be a warning?
I don't understand this sentence :-?
if all the swap spaces are inserted in fstab, and one of them hold an hibernation image, what do the kernel do? ask?
Ah! I see. I have several swap spaces in fstab. Well, I know that it only loads the hibernation image from the one space that is listed in the "resume=" parameter. I don't know if it is possible to list more than one there :-? I'm unsure if fstab (in the initrd image) is parsed early enough for searching hibernation images in other swap spaces, but I think not. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
16.04.2016 20:19, Carlos E. R. пишет:
On 2016-04-16 19:02, jdd wrote:
Le 16/04/2016 12:29, Carlos E. R. a écrit :
if all the swaps are mounted, will there be a warning?
I don't understand this sentence :-?
if all the swap spaces are inserted in fstab, and one of them hold an hibernation image, what do the kernel do? ask?
Ah! I see.
I have several swap spaces in fstab.
Well, I know that it only loads the hibernation image from the one space that is listed in the "resume=" parameter. I don't know if it is possible to list more than one there :-?
No. Hibernation image is written to a single device. There is no requirement it must swap though.
I'm unsure if fstab (in the initrd image) is parsed early enough for searching hibernation images in other swap spaces, but I think not.
On 2016-04-16 19:23, Andrei Borzenkov wrote:
16.04.2016 20:19, Carlos E. R. пишет:
On 2016-04-16 19:02, jdd wrote:
I have several swap spaces in fstab.
Well, I know that it only loads the hibernation image from the one space that is listed in the "resume=" parameter. I don't know if it is possible to list more than one there :-?
No. Hibernation image is written to a single device. There is no requirement it must swap though.
Huh, sorry, I got lost with your second sentence :-? Some years ago, hibernation aborted if more than one swap spaces was listed in fstab. Later it learnt to use only the one listed in the "resume=" parameter, and ignore fstab for this respect. It would be nice if it could hibernate to several swaps, same as it can use them on normal usage (it is faster). But I think this is not supported. So the resume space has to be big enough, even if there are more swap spaces in fstab. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
16.04.2016 20:31, Carlos E. R. пишет:
On 2016-04-16 19:23, Andrei Borzenkov wrote:
16.04.2016 20:19, Carlos E. R. пишет:
On 2016-04-16 19:02, jdd wrote:
I have several swap spaces in fstab.
Well, I know that it only loads the hibernation image from the one space that is listed in the "resume=" parameter. I don't know if it is possible to list more than one there :-?
No. Hibernation image is written to a single device. There is no requirement it must swap though.
Huh, sorry, I got lost with your second sentence :-?
There is no requirement that device you use to store hibernation image be used as swap device. It can be dedicated partition used for this purpose only.
Some years ago, hibernation aborted if more than one swap spaces was listed in fstab. Later it learnt to use only the one listed in the "resume=" parameter, and ignore fstab for this respect.
It would be nice if it could hibernate to several swaps, same as it can use them on normal usage (it is faster). But I think this is not supported. So the resume space has to be big enough, even if there are more swap spaces in fstab.
On 2016-04-16 19:56, Andrei Borzenkov wrote:
16.04.2016 20:31, Carlos E. R. пишет:
No. Hibernation image is written to a single device. There is no requirement it must swap though.
Huh, sorry, I got lost with your second sentence :-?
There is no requirement that device you use to store hibernation image be used as swap device. It can be dedicated partition used for this purpose only.
Ah! I see. Curious. Now, could this be advantageous? I have three or four swaps, so I can easily configure this. But has it known advantages? :-? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. schreef op 16-04-16 11:44:
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.
However...
The second system will probably look at the swap and see it has an hibernation image. It may attempt to load it, maybe see the signature does not match the new kernel, perhaps abort. If it doesn't abort, but just disable that swap, disaster may arise. It may erase the image and continue, and then it will see some dirty filesystems it will try to correct.
But that is not very different from hard-rebooting your computer. I do that all the time. When my system takes another 5 eaons to shut down, or, it accidentally boots when I was doing something else, and I don't feel like waiting 5 minutes before the thing is back again. I never get in trouble as far as I know.
IMHO, it should abort and ask. Maybe the user recognizes the situation and can attempt to boot the correct system in order to close it properly, then retry the second system.
Personally? That would take so much time, I probably would want to just go ahead. Then again, you don't know if you have really forgotten and you have some important files open and unsaved. But I'd take the ball. I'd risk the thing. And it's only relevant for dual booting Linux and I don't see myself doing that just like that but, .... to each his own I guess. I'll just go hang in a tree and play with monkeys instead. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-16 13:38, Xen wrote:
Carlos E. R. schreef op 16-04-16 11:44:
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.
However...
The second system will probably look at the swap and see it has an hibernation image. It may attempt to load it, maybe see the signature does not match the new kernel, perhaps abort. If it doesn't abort, but just disable that swap, disaster may arise. It may erase the image and continue, and then it will see some dirty filesystems it will try to correct.
But that is not very different from hard-rebooting your computer.
Yes.
I do that all the time. When my system takes another 5 eaons to shut down, or, it accidentally boots when I was doing something else, and I don't feel like waiting 5 minutes before the thing is back again.
I never get in trouble as far as I know.
No hard trouble, except lost work.
IMHO, it should abort and ask. Maybe the user recognizes the situation and can attempt to boot the correct system in order to close it properly, then retry the second system.
Personally? That would take so much time, I probably would want to just go ahead. Then again, you don't know if you have really forgotten and you have some important files open and unsaved. But I'd take the ball. I'd risk the thing.
Not me. But then, the system asking covers both cases.
And it's only relevant for dual booting Linux and I don't see myself doing that just like that but, .... to each his own I guess.
I have, I don't remember, 3 or 6 Linuxes in this computer.
I'll just go hang in a tree and play with monkeys instead.
LOL. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thu, Apr 14, 2016 at 1:23 AM, Knurpht - Gertjan Lettink <knurpht@opensuse.org> wrote:
Op woensdag 13 april 2016 17:10:17 CEST schreef Chris Murphy:
On Wed, Apr 13, 2016 at 3:50 PM, James Knott <james.knott@rogers.com> wrote:
On 04/13/2016 04:50 PM, Per Jessen wrote:
Umm, except when a system has been hibernated.
Since when do you get to choose another OS when coming out of hibernation?
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".
Yes and for mortal users "GRUB is controlled by the other OS" is total nonsense. It means nothing to a regular user who is the target market of a GUI installer, using automatic partitioning. So you need to design things accordingly, or accept that your OS is potentially dangerous for mortal users who aren't experts. I don't know the details of how a Linux hibernation image is properly restored. Can someone explain that? The hibernation image is written to the swap partition, I get that part, and there is a resume= hint as a boot parameter. So the system basically cold boots up, the bootloader is executed, and runs the proper boot menu entry that includes that resume= parameter, but also includes loading the kernel and the initramfs. Now what? The kernel knows to look for the hibernation image at the resume= defined swap location? And it ignores the initramfs? Does the kernel to any kind of sanity checking to make sure it's restoring the correct hibernation file? While this is not sufficient, at the very least I'd like to think that the kernel can compare its signing key to that of the one inside the hibernation image before committing to resume. If they don't match, for sure the kernel should panic before trying to write anything to disk. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-15 01:50, Chris Murphy wrote:
I don't know the details of how a Linux hibernation image is properly restored. Can someone explain that? The hibernation image is written to the swap partition, I get that part, and there is a resume= hint as a boot parameter. So the system basically cold boots up, the bootloader is executed, and runs the proper boot menu entry that includes that resume= parameter,
Without displaying the menu. That's important. The user must not try to boot anything else.
but also includes loading the kernel and the initramfs. Now what? The kernel knows to look for the hibernation image at the resume= defined swap location?
Yes
And it ignores the initramfs?
No.
Does the kernel to any kind of sanity checking to make sure it's restoring the correct hibernation file?
Yes, but I don't know what exactly it checks.
While this is not sufficient, at the very least I'd like to think that the kernel can compare its signing key to that of the one inside the hibernation image before committing to resume. If they don't match, for sure the kernel should panic before trying to write anything to disk.
Basically, the kernel starts to boot. It knows that there is the possibility that it has to read an hibernation image; at some point in boot, it suddenly checks that image. If valid, it loads that image into memory, in the position in memory that everything should be (where things where), and I will not try to imagine how. I can guess enough to know it is a nightmare. After everything is loaded, I suppose it reactivates hardware to the state it was, then passes control to some point in the just loaded image, and somehow erases itself. Perhaps at some point there is a move memory. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcQRUcACgkQja8UbcUWM1xEgQEAg+SWZRc49fbPRmwgpL5/bExN HliwOjM5eNIgVbzArrwBAIw1ywlP86uJ/tS7kZmsiZdvnysualcEFHUtqVG25iCU =Gb19 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
15.04.2016 04:35, Carlos E. R. пишет:
On 2016-04-15 01:50, Chris Murphy wrote:
I don't know the details of how a Linux hibernation image is properly restored. Can someone explain that? The hibernation image is written to the swap partition, I get that part, and there is a resume= hint as a boot parameter. So the system basically cold boots up, the bootloader is executed, and runs the proper boot menu entry that includes that resume= parameter,
Without displaying the menu. That's important. The user must not try to boot anything else.
but also includes loading the kernel and the initramfs. Now what? The kernel knows to look for the hibernation image at the resume= defined swap location?
Yes
And it ignores the initramfs?
No.
This will not work without initramfs, see below.
Does the kernel to any kind of sanity checking to make sure it's restoring the correct hibernation file?
Yes, but I don't know what exactly it checks.
At least kernel version is checked.
While this is not sufficient, at the very least I'd like to think that the kernel can compare its signing key to that of the one inside the hibernation image before committing to resume. If they don't match, for sure the kernel should panic before trying to write anything to disk.
Basically, the kernel starts to boot. It knows that there is the possibility that it has to read an hibernation image; at some point in boot, it suddenly checks that image. If valid, it loads that image into memory, in the position in memory that everything should be
Today this first attempt almost universally fails because resume= parameter refers to udev links that kernel itself cannot resolve. So initramfs has code to trigger this attempt once more after udev runs and links are created but before it attempts to mount root. In this case it simply passes to kernel major:minor of resume device.
On Thu, Apr 14, 2016 at 9:25 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
15.04.2016 04:35, Carlos E. R. пишет:
On 2016-04-15 01:50, Chris Murphy wrote:
I don't know the details of how a Linux hibernation image is properly restored. Can someone explain that? The hibernation image is written to the swap partition, I get that part, and there is a resume= hint as a boot parameter. So the system basically cold boots up, the bootloader is executed, and runs the proper boot menu entry that includes that resume= parameter,
Without displaying the menu. That's important. The user must not try to boot anything else.
but also includes loading the kernel and the initramfs. Now what? The kernel knows to look for the hibernation image at the resume= defined swap location?
Yes
And it ignores the initramfs?
No.
This will not work without initramfs, see below.
Does the kernel to any kind of sanity checking to make sure it's restoring the correct hibernation file?
Yes, but I don't know what exactly it checks.
At least kernel version is checked.
While this is not sufficient, at the very least I'd like to think that the kernel can compare its signing key to that of the one inside the hibernation image before committing to resume. If they don't match, for sure the kernel should panic before trying to write anything to disk.
Basically, the kernel starts to boot. It knows that there is the possibility that it has to read an hibernation image; at some point in boot, it suddenly checks that image. If valid, it loads that image into memory, in the position in memory that everything should be
Today this first attempt almost universally fails because resume= parameter refers to udev links that kernel itself cannot resolve. So initramfs has code to trigger this attempt once more after udev runs and links are created but before it attempts to mount root. In this case it simply passes to kernel major:minor of resume device.
Interesting. What about resume= to the swap's UUID set with mkswap and reported by blkid? Seems like that would be a lot more reliable. And if it is more reliable, why isn't that the default boot parameter setting? -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
15.04.2016 20:51, Chris Murphy пишет:
On Thu, Apr 14, 2016 at 9:25 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
15.04.2016 04:35, Carlos E. R. пишет:
On 2016-04-15 01:50, Chris Murphy wrote:
I don't know the details of how a Linux hibernation image is properly restored. Can someone explain that? The hibernation image is written to the swap partition, I get that part, and there is a resume= hint as a boot parameter. So the system basically cold boots up, the bootloader is executed, and runs the proper boot menu entry that includes that resume= parameter,
Without displaying the menu. That's important. The user must not try to boot anything else.
but also includes loading the kernel and the initramfs. Now what? The kernel knows to look for the hibernation image at the resume= defined swap location?
Yes
And it ignores the initramfs?
No.
This will not work without initramfs, see below.
Does the kernel to any kind of sanity checking to make sure it's restoring the correct hibernation file?
Yes, but I don't know what exactly it checks.
At least kernel version is checked.
While this is not sufficient, at the very least I'd like to think that the kernel can compare its signing key to that of the one inside the hibernation image before committing to resume. If they don't match, for sure the kernel should panic before trying to write anything to disk.
Basically, the kernel starts to boot. It knows that there is the possibility that it has to read an hibernation image; at some point in boot, it suddenly checks that image. If valid, it loads that image into memory, in the position in memory that everything should be
Today this first attempt almost universally fails because resume= parameter refers to udev links that kernel itself cannot resolve. So initramfs has code to trigger this attempt once more after udev runs and links are created but before it attempts to mount root. In this case it simply passes to kernel major:minor of resume device.
Interesting.
What about resume= to the swap's UUID set with mkswap and reported by blkid?
This is just as well unknown to kernel so there is no difference. Actually UUID=xyz has been alias for /dev/disk/by-uuid/xyz for a long time.
Seems like that would be a lot more reliable. And if it is more reliable, why isn't that the default boot parameter setting?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 13/04/2016 21:34, James Knott a écrit :
So, what the geckos out there think? Do you prefer to share swap
avoid using all swaps on all disks. It's a frequent way to remove an old disk when the new is installed fully, and openSUSE don't like missing swaps jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 13/04/2016 21:34, James Knott a écrit :
So, what the geckos out there think? Do you prefer to share swap
I lost the original mail, so I reply here. The system should help users to do the right thing. If you don't have a second Linux, this is a non-issue. If you install a second Linux system, the installer should detect that and warn that you need to be careful when hibernating and suggest to create one swap per install. If you boot and another Linux is currently using the swap partition for hibernate data, then mounting the swap should fail with and a useful error message should be displayed. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-14 20:57, Aaron Digulla wrote:
I lost the original mail, so I reply here.
The system should help users to do the right thing. If you don't have a second Linux, this is a non-issue.
If you install a second Linux system, the installer should detect that and warn that you need to be careful when hibernating and suggest to create one swap per install.
Again, booting a second Linux while the first is hibernated can destroy all filesystems that are attempted to be mounted on both. It is a very dangerous procedure. The installer should not consider this situation at all. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcQRk0ACgkQja8UbcUWM1xOKAD+NnEj/N4h3mOunN8vkjxJPbMX YR7UcCVsg7F3P3+ibN8A/iQGyH7OzvV3DznuqcU2u3sXglg2OlX0KFvOCEEtyHi5 =KhwA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Apr 14, 2016 at 7:39 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-04-14 20:57, Aaron Digulla wrote:
I lost the original mail, so I reply here.
The system should help users to do the right thing. If you don't have a second Linux, this is a non-issue.
If you install a second Linux system, the installer should detect that and warn that you need to be careful when hibernating and suggest to create one swap per install.
Again, booting a second Linux while the first is hibernated can destroy all filesystems that are attempted to be mounted on both. It is a very dangerous procedure. The installer should not consider this situation at all.
Yeah I'm pretty much starting to think that dual boot Linux + Linux is just fundamentally broken and is only the realm of expert users. As such GUI installers shouldn't permit it with their default/guided/automatic partitioning used by regular users. Dual boot Windows + Linux is pretty reliable. Mac OS X + Linux is also reliable but broken in all versions of GRUB for a very long time, but at least it's possible to use the Mac's built-in firmware manager to switch reliably. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
15.04.2016 20:46, Chris Murphy пишет:
On Thu, Apr 14, 2016 at 7:39 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-04-14 20:57, Aaron Digulla wrote:
I lost the original mail, so I reply here.
The system should help users to do the right thing. If you don't have a second Linux, this is a non-issue.
If you install a second Linux system, the installer should detect that and warn that you need to be careful when hibernating and suggest to create one swap per install.
Again, booting a second Linux while the first is hibernated can destroy all filesystems that are attempted to be mounted on both. It is a very dangerous procedure. The installer should not consider this situation at all.
Yeah I'm pretty much starting to think that dual boot Linux + Linux is just fundamentally broken and is only the realm of expert users. As such GUI installers shouldn't permit it with their default/guided/automatic partitioning used by regular users.
Dual boot Windows + Linux is pretty reliable. Mac OS X + Linux is also
Huh? How are you going to automatically boot into Windows after hibernating it when using Linux bootloader? I do not see any difference here except you are less likely to accidentally corrupt Windows filesystem in this case.
reliable but broken in all versions of GRUB for a very long time, but at least it's possible to use the Mac's built-in firmware manager to switch reliably.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov schreef op 16-04-16 06:27:
Dual boot Windows + Linux is pretty reliable. Mac OS X + Linux is also
Huh? How are you going to automatically boot into Windows after hibernating it when using Linux bootloader? I do not see any difference here except you are less likely to accidentally corrupt Windows filesystem in this case.
I think the difference is mostly that it is not very well defined how "two grubs" are going to work together. If you have two systems, it is not clear at all how you are supposed to make them work together (unless, perhaps, you have more knowledge about that). I have never heard of a concept that said "this is THE solution to having multiple Linux installations". What you would expect is for different installations to be aware of each other and for (the second) OS install to recognise the existing grub, and even update that config, but that might not work if they are different versions or whatever. If I wanted to dual boot Linux I would want to have one config for both. Then again I prefer to manually edit my grub.cfg because it is never to my liking -- which creates problems with kernels being updated. In essence Grub is a pretty mediocre program from a user point of view. At least OpenSUSE gets a very nice theme for it which makes it look rather awesome, but the Ubuntus don't even do that -- it is just plain ugly mundane 4-5 line menu filled with options you may not even need and that you will have a very hard time customizing. Oh, the glory days of autoexec.bat and config.sys. Boot menus with such a breeze. Everything so easy. I was more in power about my system in MS-DOS by a very large margin. MS-DOS was under my control. Linux. I have about the same control over Linux as I have over a sun in a different solar system. Makes me want to liken MS-DOS to the moon :p. You cannot really customize grub because you have to customize the script that generates it, which means you are now a programmer. In other words, you need to /develop/ linux before you can customize that simple part of it. Well, if I could I'd jump in the water and drown myself because changing this is not ever goint to happen ;-). Regards. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Xen composed on 2016-04-16 13:09 (UTC+0200):
Andrei Borzenkov composed:
Dual boot Windows + Linux is pretty reliable. Mac OS X + Linux is also
Huh? How are you going to automatically boot into Windows after hibernating it when using Linux bootloader? I do not see any difference here except you are less likely to accidentally corrupt Windows filesystem in this case.
I think the difference is mostly that it is not very well defined how "two grubs" are going to work together.
If you have two systems, it is not clear at all how you are supposed to make them work together (unless, perhaps, you have more knowledge about that).
I have never heard of a concept that said "this is THE solution to having multiple Linux installations".
The solution used here, where all machines are BIOS, is limiting bootloader control of each installation exclusively to its own installation, loaded through a bootloader independently controlled. For that I use Grub 0.97+ mostly, also IBM OS/2's Boot Manager, and even NTLDR. Other options exist, such as Acronis, AiR-Boot, Plop and XOSL. ...
At least OpenSUSE gets a very nice theme for it which makes it look rather awesome
Hence my choice of openSUSE's Grub 0.97 as master bootloader on most multiboot installations. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata schreef op 16-04-16 13:55:
I have never heard of a concept that said "this is THE solution to having multiple Linux installations".
The solution used here, where all machines are BIOS, is limiting bootloader control of each installation exclusively to its own installation, loaded through a bootloader independently controlled. For that I use Grub 0.97+ mostly, also IBM OS/2's Boot Manager, and even NTLDR. Other options exist, such as Acronis, AiR-Boot, Plop and XOSL.
Man. That almost sounds like "TL;DR". That is not something someone is able to do who hasn't have a LOT of knowledge about the system. I couldn't do that for YEARS unless I dedicated myself to it exclusively, and even then I couldn't because I just can't be interested in it. Oh, you're saying you can use that older Grub as the master, probably with a form of chainloading that they say is now gone from Grub2. Maybe that wouldn't be too hard. Maybe that would be doable. I think the original Grub was not nearly as hard to configure as what we have today. Thanks, maybe ... I have always been reluctant to dive into older versions. For some reason, you don't want older versions. They are deprecated, unless you have used them before you now need to learn about older versions that are no longer current or very relevant. I guess. Well, thanks anyway. Regards. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-16 14:32, Xen wrote:
Felix Miata schreef op 16-04-16 13:55:
Oh, you're saying you can use that older Grub as the master, probably with a form of chainloading that they say is now gone from Grub2.
No, not gone. I experimented about it not long ago, and posted about it here. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
16.04.2016 14:55, Felix Miata пишет:
Xen composed on 2016-04-16 13:09 (UTC+0200):
The solution used here, where all machines are BIOS, is limiting bootloader control of each installation exclusively to its own installation, loaded through a bootloader independently controlled.
How does it solve the problem discussed here? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov composed on 2016-04-16 19:04 (UTC+0300):
Felix Miata composed:
The solution used here, where all machines are BIOS, is limiting bootloader control of each installation exclusively to its own installation, loaded through a bootloader independently controlled.
How does it solve the problem discussed here?
There's an underlying issue in $SUBJECT: "new installer". The installer is being rebuilt anew, which is ideal opportunity for thinking outside the box, possibly evolving what an installer can or should do. We've seen in the thread multiple issues regarding swap configuration besides swap device count, among which: 1-hibernation of multiboot systems is loaded with opportunity for destruction. 2-hibernation seems to be the primary use of swap in modern systems with copious RAM, multiple fast CPU cores, often employing SSDs dramatically lowering I/O time and diminishing efficacy of swapping 3-a partitioning proposal for a multiboot system arguably must depend on informed user input Were all OS installations limiting themselves to controlling only the installation from whence provided, their jobs could be as simple as when only one installation is or will be present. Instead of every OS's boot loader trying to incorporate anticipation of abundant possibilities, control that which cannot be controlled, or wresting control from that which was last configured, a master bootloader under independent control whose job on wake is to determine sleep state before anything proceeds, then allow only compatible options to proceed, could be designed and implemented, a two-stage boot selection process. Possibly this is the realm of UEFI or an extension thereto, either of which can be no help for legacy systems. In the mean time, a less sophisticated master boot loader under independent control could serve as reminder of danger and pitfalls, especially if its active selection details are served up with *resume<whatever> as a highlight, as Gfxboot's showopts can. Here, normal Linux kernel stanzas always contain noresume. Boot speed here, as long as not unduly delayed (boot times ~90s or less being acceptable), is a non-issue compared to predictability and reliability. Here, both Grub Legacy and IBM BM have proven suited to task. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata schreef op 16-04-16 20:57:
1-hibernation of multiboot systems is loaded with opportunity for destruction.
2-hibernation seems to be the primary use of swap in modern systems with copious RAM, multiple fast CPU cores, often employing SSDs dramatically lowering I/O time and diminishing efficacy of swapping
3-a partitioning proposal for a multiboot system arguably must depend on informed user input
Nice summary Felix.
Were all OS installations limiting themselves to controlling only the installation from whence provided, their jobs could be as simple as when only one installation is or will be present. Instead of every OS's boot loader trying to incorporate anticipation of abundant possibilities, control that which cannot be controlled, or wresting control from that which was last configured, a master bootloader under independent control whose job on wake is to determine sleep state before anything proceeds, then allow only compatible options to proceed, could be designed and implemented, a two-stage boot selection process. Possibly this is the realm of UEFI or an extension thereto, either of which can be no help for legacy systems.
Two-stage is generally an interesting thing anyway, for several reasons (for me): - chainloading additional loaders is one of the most essential and elementary things if you want to create a more complex operating system setup If ANYTHING should be easy, it should be chainloading into e.g. the boot record of a partition (rather than MBR/whatever). - UEFI may try to do this thing as well but at the moment, for me, the thing is utterly complicated - an advanced boot loader may be able to hide boot options, or group them together at a lower level. Grub even contains decryption options and may even be able to chainload into another bootloader that it has first decrypted.
In the mean time, a less sophisticated master boot loader under independent control could serve as reminder of danger and pitfalls, especially if its active selection details are served up with *resume<whatever> as a highlight, as Gfxboot's showopts can. Here, normal Linux kernel stanzas always contain noresume. Boot speed here, as long as not unduly delayed (boot times ~90s or less being acceptable), is a non-issue compared to predictability and reliability. Here, both Grub Legacy and IBM BM have proven suited to task.
Personally I do feel the operating system should be allowed to control the (master) boot loader. The system I would devise myself would include: - an agreement between Linux systems on how to configure a common "core" (boot configuration) - a different system where configuration is not generated as it is now (grub2) but where operating systems insert modules into some common directory - in this system the user is capable of making his/her own choice as to the "markup" or "layout" of the boot menu -- the relevent options and all of the required parameters are already there, the user now only has to pick and choose. This implies that boot parameters (locations) are saved as files. The menu is a user-editable file. The file can reference inclusions and this could for instance include symlinks to "main kernel" and "secondary kernel". If you had that, interoperability between Linux OSes would become much easier. The parameters for each OS are now controlled by that OS itself. The only thing that both (or more) operating systems can touch, is the common menu file, and/or locations where kernels are kept (ie. a shared /boot). I think this starts to resemble UEFI but now it is a much more simple thing. I don't know the details of what it should be, but that is what I would do. Grub2 is just notoriously difficult because the detection scripts may not even work for a different install. It is being asked to control the boot parameters for a different OS it may not full well know about. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Xen composed on 2016-04-16 21:22 (UTC+0200):
Personally I do feel the operating system should be allowed to control the (master) boot loader.
That's the root of the MBR anarchy incepted by multiboot as most know it. Every installer that finds the MBR non-empty should very explicitly ask permission before doing anything, control granted, rather than control usurped. When generic MBR code, can be preserved in conjunction with a FOSS bootloader installed elsewhere to provide a choice of both old and new, it should be the preferred or initial offering rather than obliteration of the existing. http://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up... -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Apr 15, 2016 at 10:27 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
15.04.2016 20:46, Chris Murphy пишет: ult/guided/automatic partitioning used by regular users.
Dual boot Windows + Linux is pretty reliable. Mac OS X + Linux is also
Huh? How are you going to automatically boot into Windows after hibernating it when using Linux bootloader? I do not see any difference here except you are less likely to accidentally corrupt Windows filesystem in this case.
Modern systems are capable of using firmware managed hibernation. The bootloader isn't a factor. The firmware recovers the hibernation image from a dedicated partition to RAM, and resumes. It's not a cold boot based resume. But this is a fragmented implementation to be sure, not every manufacturer is using it I suspect. I also don't know what the default behaviors are. Probably the most reliable way to handle hibernation is via the firmware; even single system booting. But for multibooting it'd be even more reliable. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
16.04.2016 20:43, Chris Murphy пишет:
On Fri, Apr 15, 2016 at 10:27 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
15.04.2016 20:46, Chris Murphy пишет: ult/guided/automatic partitioning used by regular users.
Dual boot Windows + Linux is pretty reliable. Mac OS X + Linux is also
Huh? How are you going to automatically boot into Windows after hibernating it when using Linux bootloader? I do not see any difference here except you are less likely to accidentally corrupt Windows filesystem in this case.
Modern systems are capable of using firmware managed hibernation. The
Firmware managed hibernation was possible (and in effect the only possibility) about 15 to 20 years ago (not sure when I met it first), before operating systems started to support it natively.
bootloader isn't a factor. The firmware recovers the hibernation image from a dedicated partition to RAM, and resumes. It's not a cold boot based resume.
Yes. That is how it worked in the past. I am interested which of modern computers do it; could you give reference(s)?
But this is a fragmented implementation to be sure, not every manufacturer is using it I suspect. I also don't know what the default behaviors are.
Probably the most reliable way to handle hibernation is via the firmware; even single system booting. But for multibooting it'd be even more reliable.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Apr 16, 2016 at 12:00 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
16.04.2016 20:43, Chris Murphy пишет:
bootloader isn't a factor. The firmware recovers the hibernation image from a dedicated partition to RAM, and resumes. It's not a cold boot based resume.
Yes. That is how it worked in the past. I am interested which of modern computers do it; could you give reference(s)?
For sure the Dell XPS laptops work this way because I had one for evaluation. It uses Intel Rapid Start, only on SSD, and requires partition of the proper size with partition type GUID D3BFE2DE-3DAF-11DF-BA40-E3A556D89593. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Apr 16, 2016 at 1:39 PM, Chris Murphy <lists@colorremedies.com> wrote:
On Sat, Apr 16, 2016 at 12:00 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
16.04.2016 20:43, Chris Murphy пишет:
bootloader isn't a factor. The firmware recovers the hibernation image from a dedicated partition to RAM, and resumes. It's not a cold boot based resume.
Yes. That is how it worked in the past. I am interested which of modern computers do it; could you give reference(s)?
For sure the Dell XPS laptops work this way because I had one for evaluation. It uses Intel Rapid Start, only on SSD, and requires partition of the proper size with partition type GUID D3BFE2DE-3DAF-11DF-BA40-E3A556D89593.
https://mjg59.dreamwidth.org/26022.html -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Apr 16, 2016 at 1:41 PM, Chris Murphy <lists@colorremedies.com> wrote:
On Sat, Apr 16, 2016 at 1:39 PM, Chris Murphy <lists@colorremedies.com> wrote:
On Sat, Apr 16, 2016 at 12:00 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
16.04.2016 20:43, Chris Murphy пишет:
bootloader isn't a factor. The firmware recovers the hibernation image from a dedicated partition to RAM, and resumes. It's not a cold boot based resume.
Yes. That is how it worked in the past. I am interested which of modern computers do it; could you give reference(s)?
For sure the Dell XPS laptops work this way because I had one for evaluation. It uses Intel Rapid Start, only on SSD, and requires partition of the proper size with partition type GUID D3BFE2DE-3DAF-11DF-BA40-E3A556D89593.
The other cool thing about this, is that the user can just use regular sleep, including closing the lid, and the firmware can flip it over on its own to hibernation without involving the OS. Apple does something similar with OS X but it's a hybrid firmware+bootloader approach because they write out the sleep image to a file on HFSJ/HFSX which itself can be on their logical volume implementation which can be encrypted. The booloader might get a hint for this from NVRAM, but the bootloader is what presents a disk passphrase entry UI to the user, and at that point it can read the sleep file and resume. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Chris Murphy schreef op 16-04-16 21:58:
On Sat, Apr 16, 2016 at 1:41 PM, Chris Murphy <lists@colorremedies.com> wrote:
On Sat, Apr 16, 2016 at 1:39 PM, Chris Murphy <lists@colorremedies.com> wrote:
On Sat, Apr 16, 2016 at 12:00 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
16.04.2016 20:43, Chris Murphy пишет:
bootloader isn't a factor. The firmware recovers the hibernation image from a dedicated partition to RAM, and resumes. It's not a cold boot based resume.
Yes. That is how it worked in the past. I am interested which of modern computers do it; could you give reference(s)?
For sure the Dell XPS laptops work this way because I had one for evaluation. It uses Intel Rapid Start, only on SSD, and requires partition of the proper size with partition type GUID D3BFE2DE-3DAF-11DF-BA40-E3A556D89593.
The other cool thing about this, is that the user can just use regular sleep, including closing the lid, and the firmware can flip it over on its own to hibernation without involving the OS.
Apple does something similar with OS X but it's a hybrid firmware+bootloader approach because they write out the sleep image to a file on HFSJ/HFSX which itself can be on their logical volume implementation which can be encrypted. The booloader might get a hint for this from NVRAM, but the bootloader is what presents a disk passphrase entry UI to the user, and at that point it can read the sleep file and resume.
Personally I don't like this interference of the firmware with the operating system. One reason I also don't like UEFI (although I don't know enough about it). I will liken it to a choice made by some cheap German firmware RAID card. I had configured a raid array in the thing without realizing I wouldn't easily be able to use it in Linux. After, I didn't care and just installed the thing, I installed Linux on it and put mdadm raid onto it (using the Debian installer). All is fine and well, but I cannot remove the raid array from the raid card without it clearing the partition tables on the devices (disks). You may think: what does it matter, in this case it is just cosmetic, but it just illustrates the dangers of having some firmware that is not well implemented if your operating system can no longer control it by iself. Supposing that everyone thought this feature was really great and they removed hibernation support from the OS natively? Not a good thing. Just my opinion here.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-16 21:58, Chris Murphy wrote:
The other cool thing about this, is that the user can just use regular sleep, including closing the lid, and the firmware can flip it over on its own to hibernation without involving the OS.
There is a possibly nasty problem with this. The computer has to awake (at least partially) at some point (when battery is low) to store the sleep image on disk, then power off. Hopefully, this may take only a minute, but the laptop may at that time be inside a bag. No ventilation, no cooling. And, if it hangs and does not finish in a minute, then it can overheat badly. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. schreef op 17-04-16 14:29:
On 2016-04-16 21:58, Chris Murphy wrote:
The other cool thing about this, is that the user can just use regular sleep, including closing the lid, and the firmware can flip it over on its own to hibernation without involving the OS.
There is a possibly nasty problem with this.
The computer has to awake (at least partially) at some point (when battery is low) to store the sleep image on disk, then power off. Hopefully, this may take only a minute, but the laptop may at that time be inside a bag. No ventilation, no cooling. And, if it hangs and does not finish in a minute, then it can overheat badly.
Actually Windows appears to do this by default. My computer (laptop) would regularly just come out of standby and hibernate instead. It never failed and was very dependable. There was no chance whatsoever that it would cause any kind of heat problems. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 18 Apr 2016 00:08:16 +0200 Xen Xen wrote:
Actually Windows appears to do this by default.
My computer (laptop) would regularly just come out of standby and hibernate instead.
It never failed and was very dependable. There was no chance whatsoever that it would cause any kind of heat problems.
Count your blessings. My wife contributed two worthless laptop shells to our 'surplus equipment' collection in three years. I suspect it was due to this very type of behavior. She had no clue what to look for. She just closed them up when she was done, put them away in the case and they come out dead - as in a completely failed CPU, a mainboard that won't POST and a hard disk that won't spin up. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carl Hartung schreef op 18-04-16 01:43:
On Mon, 18 Apr 2016 00:08:16 +0200 Xen Xen wrote:
Actually Windows appears to do this by default.
My computer (laptop) would regularly just come out of standby and hibernate instead.
It never failed and was very dependable. There was no chance whatsoever that it would cause any kind of heat problems.
Count your blessings. My wife contributed two worthless laptop shells to our 'surplus equipment' collection in three years. I suspect it was due to this very type of behavior. She had no clue what to look for. She just closed them up when she was done, put them away in the case and they come out dead - as in a completely failed CPU, a mainboard that won't POST and a hard disk that won't spin up.
I thought you said "Consider yourself lucky" ;-). Would be more apt here. But... do laptops have cases? You can't put a standby-laptop away for ever in any case. ;-). But okay, yeah, if it fails you might get in trouble as you say. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-18 01:51, Xen wrote:
But... do laptops have cases? You can't put a standby-laptop away for
Bags, suitcases. Whatever. Yes, this type of heat accident is not that uncommon. And W10 machines by default do this quick power off instead of power off. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcUK5wACgkQja8UbcUWM1xI+AD/dZQJi0yXA9AL/n5RHNXO/W7O MCxIIFWVEOL9n09EWLoBAJ9xNHxKn0SD61EuDL9hR6S5v8u440w+ZlxkTHq87unt =rix2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/17/2016 05:34 PM, Carlos E. R. wrote:
On 2016-04-18 01:51, Xen wrote:
But... do laptops have cases? You can't put a standby-laptop away for
Bags, suitcases. Whatever.
Yes, this type of heat accident is not that uncommon. And W10 machines by default do this quick power off instead of power off.
By that you mean what, exactly? Is a quick power off a suspend to ram? -- After all is said and done, more is said than done.
On 2016-04-18 19:07, John Andersen wrote:
On 04/17/2016 05:34 PM, Carlos E. R. wrote:
On 2016-04-18 01:51, Xen wrote:
But... do laptops have cases? You can't put a standby-laptop away for
Bags, suitcases. Whatever.
Yes, this type of heat accident is not that uncommon. And W10 machines by default do this quick power off instead of power off.
By that you mean what, exactly? Is a quick power off a suspend to ram?
Windows parlance. Some kind of hybrid. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Mon, Apr 18, 2016 at 1:07 PM, John Andersen <jsamyth@gmail.com> wrote:
On 04/17/2016 05:34 PM, Carlos E. R. wrote:
On 2016-04-18 01:51, Xen wrote:
But... do laptops have cases? You can't put a standby-laptop away for
Bags, suitcases. Whatever.
Yes, this type of heat accident is not that uncommon. And W10 machines by default do this quick power off instead of power off.
Carlos, I have no idea why a Windows "Fast Startup" feature migh overheat a computer. As far as I know it truly powers down at the end of the process.
By that you mean what, exactly? Is a quick power off a suspend to ram?
No, it's a partial system shutdown followed by a hibernate. The shutdown kills all apps, but leaves the NTFS volumes dirty. If a dual boot systems uses "fast startup" in Windows, they can't mount the NTFS volumes in Linux. Here's some detail: https://msdn.microsoft.com/en-us/library/windows/hardware/jj835779(v=vs.85).... === In contrast, a fast startup simply loads the hibernation file (Hiberfil.sys) into memory to restore the previously saved image of the Windows kernel and loaded drivers. A fast startup tends to take significantly less time than a cold startup. To prepare for a fast startup, Windows performs a hybrid shutdown sequence that combines elements of a full shutdown sequence and a prepare-for-hibernation sequence. First, as in a full shutdown, Windows closes all applications and logs off all user sessions. At this stage, the system state is similar to that of a computer that has just started up—no applications are running, but the Windows kernel is loaded and the system session is running. Next, the power manager sends system power IRPs to device drivers to tell them to prepare their devices to enter hibernation. Finally, Windows saves the kernel memory image (including the loaded kernel-mode drivers) in Hiberfil.sys and shuts down the computer. By default, Windows 8 uses a fast startup in place of a cold startup. Users can typically ignore the differences between fast and cold startups, but, to meet users' expectations, fast startups should behave the same as cold startups. In particular, the devices attached to the computer should be configured the same for a fast startup as they would be for a cold startup. === Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Apr 18, 2016 at 2:19 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
No, it's a partial system shutdown followed by a hibernate. The shutdown kills all apps, but leaves the NTFS volumes dirty.
I'm not sure if it's dirty in the same way as an unclean unmount, or if it's a separate flag that indicates a hibernation file is in play. It could set both dirty and hibernate flags, that'd make sense also. Seems like it'd be a bad idea to hibernate without at least syncing the system so that it can easily recover from merely journal replay at next mount in case the hibernation file croaks. The problem that remains is if the volume were to be mounted elsewhere and modified, and then the hibernation image resumed. In that case there'd be a disconnect between the two states. And maybe that's what the "hibernate" form of dirty flag helps avoid? It doesn't seem we have such a thing on Linux file systems. If Linux A hibernates, and Linux B is booted, say a Live USB stick or even dual boot where another bootloader assumes control before (software) hibernation can be resumed, and Linux A's volume were mounted and modified, what happens when Linux A is rebooted? Can the kernel know there's a difference in the file system states? The on disk state is clearly different than the state known by the hibernation file. And if yes does the kernel fail to resume from hibernate, discard/invalidate the hibernation file, and fallback to normal boot? Or does it proceed? If it proceeds to resume and mounts the file system, I expect eventual and significant corruption. And if that's true whose problem is this (component wise, obviously it's ultimately the user's problem, even though not their fault)? -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-18 23:19, Chris Murphy wrote:
On Mon, Apr 18, 2016 at 2:19 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
No, it's a partial system shutdown followed by a hibernate. The shutdown kills all apps, but leaves the NTFS volumes dirty.
I'm not sure if it's dirty in the same way as an unclean unmount, or if it's a separate flag that indicates a hibernation file is in play.
There is a flag, I think, because Linux can detect this situation in the NTFS volumes, and refuses to mount them. There was a paragraph in the openSUSE release notes about this, IIRC. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2016-04-18 22:19, Greg Freemyer wrote:
On Mon, Apr 18, 2016 at 1:07 PM, John Andersen <jsamyth@gmail.com> wrote:
On 04/17/2016 05:34 PM, Carlos E. R. wrote:
On 2016-04-18 01:51, Xen wrote:
But... do laptops have cases? You can't put a standby-laptop away for
Bags, suitcases. Whatever.
Yes, this type of heat accident is not that uncommon. And W10 machines by default do this quick power off instead of power off.
Carlos, I have no idea why a Windows "Fast Startup" feature migh overheat a computer. As far as I know it truly powers down at the end of the process.
Because if the battery runs out (I have not tested this with W10) it wakes up for a minute to do a real hibernation to disk, not to ram. If this procedure crashes, the machine stays running (while the battery lasts), at a time when the laptop can be inside a bag, where the fan can not work. In fact, it may wake up automatically to do other tasks that it has postponed - this I have been told that happened to a friend. I have known this to happen, it is not imagination. In fact, there was a warning about this in my laptop documentation. Actually, my laptop was unable to power off in W10 the last time I tried, after the last service pack type update. It goes dark, but does not power off. My guess is that it tries to hibernate, but fails, because the Windows partition is not marked bootable (I'm certain of this: marking the partition bootable allows my laptop to hibernate in Windows). Instead, I had to tell W10 to reboot, then hit the button at the bios screen. Somehow it must have activated quick power off by default on my back. I'll verify this next time I boot W10. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 18/04/2016 23:24, Carlos E. R. a écrit :
Instead, I had to tell W10 to reboot, then hit the button at the bios screen.
yes, I have been told it's the only way to be sure the computer is switched off it's important when you have to install openSUSE on a computer: openSUSE (yast) can't shrink the ntfs file system when the computer is not really shut down. it's also why I like better shrink the file system in wondows. but the hover all conclusion I get reading this thread is that hibernation is evil. This is specially true when using ssd, where boot is 20 s fast jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-19 08:56, jdd wrote:
Le 18/04/2016 23:24, Carlos E. R. a écrit :
Instead, I had to tell W10 to reboot, then hit the button at the bios screen.
yes, I have been told it's the only way to be sure the computer is switched off
Yesterday I googled and told W10 to really switch off.
it's important when you have to install openSUSE on a computer: openSUSE (yast) can't shrink the ntfs file system when the computer is not really shut down.
Not even mount the partition.
but the hover all conclusion I get reading this thread is that hibernation is evil. This is specially true when using ssd, where boot is 20 s fast
I hibernate every day in Linux, several times. It is not evil. In SSD it is even faster, specially considering that I get the twenty application windows opened in the same status as they were the previous time, including opened files. This is simply impossible to do with a restart. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 19/04/2016 12:06, Carlos E. R. a écrit :
windows opened in the same status as they were the previous time, including opened files. This is simply impossible to do with a restart.
I almost never keep files opened when not in immediate use, risk is to high IMHO, not of system failure but of my own memory failure :-)) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-19 12:47, jdd wrote:
Le 19/04/2016 12:06, Carlos E. R. a écrit :
windows opened in the same status as they were the previous time, including opened files. This is simply impossible to do with a restart.
I almost never keep files opened when not in immediate use, risk is to high IMHO, not of system failure but of my own memory failure :-))
Well, I may be working on a calc sheet in LibreOffice, and I have to go. I save the file, then I hibernate. When I come back, I continue work, that day or another day. It stays open. If it crashes, does not matter: the file was saved, too. meanwhile, the program stays open where I left, so that when I see it I remember that there is work pending there ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 19/04/2016 13:51, Carlos E. R. a écrit :
the file was saved, too. meanwhile, the program stays open where I left, so that when I see it I remember that there is work pending there ;-)
there is a high risk of typing in there in place of an other page... (for me) and there is a "previous file open" on the menus :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-19 13:53, jdd wrote:
Le 19/04/2016 13:51, Carlos E. R. a écrit :
the file was saved, too. meanwhile, the program stays open where I left, so that when I see it I remember that there is work pending there ;-)
there is a high risk of typing in there in place of an other page... (for me)
That's one of the reasons I use several desktops. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 19/04/2016 14:00, Carlos E. R. a écrit :
That's one of the reasons I use several desktops.
I have 8 :-) but the center mouse wheel changes the desktop too easily :-) but I guess we are too far from the subject. For me I need one swap (if any, with 8Bg ram) and no hibernation :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/19/2016 04:51 AM, Carlos E. R. wrote:
On 2016-04-19 12:47, jdd wrote:
Le 19/04/2016 12:06, Carlos E. R. a écrit :
windows opened in the same status as they were the previous time, including opened files. This is simply impossible to do with a restart.
I almost never keep files opened when not in immediate use, risk is to high IMHO, not of system failure but of my own memory failure :-))
Well, I may be working on a calc sheet in LibreOffice, and I have to go. I save the file, then I hibernate. When I come back, I continue work, that day or another day. It stays open. If it crashes, does not matter: the file was saved, too. meanwhile, the program stays open where I left, so that when I see it I remember that there is work pending there ;-)
I've been using Carlos's method for a couple years now on 13.2 as well as Win7, and more recently on Manjaro Linux. I've never had a problem with any documents being corrupted or lost changes and my machines are all set to hibernate (suspend to ram, or to disk if battery low) after being left unattended for a while. Most of my work is in LibreOffice, as well as programming editors. It is amazing how robust systems are these days in terms of reliability. And I can't remember a time when Opensuse's suspend to ram worked so reliably as it does on 13.2, (which is another reason I've not moved to Leap). -- After all is said and done, more is said than done.
On 2016-04-19 19:04, John Andersen wrote:
On 04/19/2016 04:51 AM, Carlos E. R. wrote:
Most of my work is in LibreOffice, as well as programming editors. It is amazing how robust systems are these days in terms of reliability. And I can't remember a time when Opensuse's suspend to ram worked so reliably as it does on 13.2, (which is another reason I've not moved to Leap).
I was aware of hibernation since around the 2000, that I saw it somewhere. It did not always work in Linux. It finally did, in more or less the current form, but there have been SuSE/SUSE/openSUSE releases where it failed in some computers and worked on others. Even now, it is something that you have to test on each new release. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 20/04/2016 3:27 AM, Carlos E. R. wrote:
It finally did, in more or less the current form, but there have been SuSE/SUSE/openSUSE releases where it failed in some computers and worked on others. Even now, it is something that you have to test on each new release.
Often drivers for hardware seem to be a problem, or usb devices. Hibernate was working well for me on Tumbleweed until I installed the nvidia driver. Suspend still works well though. -- Lindsay Mathieson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Apr 18, 2016 at 11:07 AM, John Andersen <jsamyth@gmail.com> wrote:
On 04/17/2016 05:34 PM, Carlos E. R. wrote:
On 2016-04-18 01:51, Xen wrote:
But... do laptops have cases? You can't put a standby-laptop away for
Bags, suitcases. Whatever.
Yes, this type of heat accident is not that uncommon. And W10 machines by default do this quick power off instead of power off.
By that you mean what, exactly? Is a quick power off a suspend to ram?
Windows 8/10 shut down by default does a logout (closes apps) then does whatever hibernation is supported; on recent hardware this is typically IRST suspend to disk which is firmware managed, supported only on SSDs. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (14)
-
Aaron Digulla -
Andrei Borzenkov -
Carl Hartung -
Carlos E. R. -
Chris Murphy -
Felix Miata -
Greg Freemyer -
James Knott -
jdd -
John Andersen -
Knurpht - Gertjan Lettink -
Lindsay Mathieson -
Per Jessen -
Xen