-----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

On Wed, Apr 13, 2016 at 3:50 PM, 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?

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

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 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

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

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

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

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

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.

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.

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 Thu, Apr 14, 2016 at 1:23 AM, Knurpht - Gertjan Lettink wrote:

Op woensdag 13 april 2016 17:10:17 CEST schreef Chris Murphy:

...

On Wed, Apr 13, 2016 at 3:50 PM, 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?

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

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.

15.04.2016 20:51, Chris Murphy пишет:

On Thu, Apr 14, 2016 at 9:25 PM, Andrei Borzenkov 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

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

On Thu, Apr 14, 2016 at 7:39 PM, Carlos E. R. 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

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

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

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

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

15.04.2016 20:46, Chris Murphy пишет:

On Fri, Apr 15, 2016 at 10:27 PM, Andrei Borzenkov wrote: 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

On Sat, Apr 16, 2016 at 12:00 PM, Andrei Borzenkov 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:41 PM, Chris Murphy wrote:

On Sat, Apr 16, 2016 at 1:39 PM, Chris Murphy wrote:

...

On Sat, Apr 16, 2016 at 12:00 PM, Andrei Borzenkov 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

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

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)

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

-----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 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 2:19 PM, Greg Freemyer 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 22:19, Greg Freemyer wrote:

On Mon, Apr 18, 2016 at 1:07 PM, 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.

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)

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)

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)

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)

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 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