[opensuse-factory] Feedback needed: swap sharing in the new installer proposal
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. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 13/04/2016 17:32, Ancor Gonzalez Sosa ha scritto:
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? .. 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 think you should do nothing and ask user what to do. Daniele. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/13/2016 05:46 PM, Daniele wrote:
Il 13/04/2016 17:32, Ancor Gonzalez Sosa ha scritto:
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? .. 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 think you should do nothing and ask user what to do.
Well, then it's not longer a proposal. :-) -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 13/04/2016 18:43, Ancor Gonzalez Sosa ha scritto:
I think you should do nothing and ask user what to do.
Well, then it's not longer a proposal. :-)
Show proposal after user decision. Nowdays, proposal is a bit scary with all subvolumes and partitions; non so easy to change for a newbie. Daniele. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On mercredi, 13 avril 2016 18.55:13 h CEST Daniele wrote:
Il 13/04/2016 18:43, Ancor Gonzalez Sosa ha scritto:
I think you should do nothing and ask user what to do.
Well, then it's not longer a proposal. :-)
Show proposal after user decision. Nowdays, proposal is a bit scary with all subvolumes and partitions; non so easy to change for a newbie.
Daniele.
That's only if you insist to use btrfs :-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 13/04/2016 21:21, Bruno Friedmann ha scritto:
On mercredi, 13 avril 2016 18.55:13 h CEST Daniele wrote:
Il 13/04/2016 18:43, Ancor Gonzalez Sosa ha scritto:
I think you should do nothing and ask user what to do.
Well, then it's not longer a proposal. :-)
Show proposal after user decision. Nowdays, proposal is a bit scary with all subvolumes and partitions; non so easy to change for a newbie.
Daniele.
That's only if you insist to use btrfs :-)
Right but btrfs is by default (if space is enough) so back to the point. Daniele. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/13/2016 04:33 PM, Daniele wrote:
Il 13/04/2016 21:21, Bruno Friedmann ha scritto:
On mercredi, 13 avril 2016 18.55:13 h CEST Daniele wrote:
Il 13/04/2016 18:43, Ancor Gonzalez Sosa ha scritto:
I think you should do nothing and ask user what to do.
Well, then it's not longer a proposal. :-)
Show proposal after user decision. Nowdays, proposal is a bit scary with all subvolumes and partitions; non so easy to change for a newbie.
Daniele.
That's only if you insist to use btrfs :-)
Right but btrfs is by default (if space is enough) so back to the point.
Daniele. I prefer a single swap. Has anyone tried zram swap? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 13.04.2016 um 17:32 schrieb Ancor Gonzalez Sosa:
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 prefer separate swap partitions. Hendrik -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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.
I would always put safety/stability above ease. People above all else want a stable system. -- Ken linux since 1994 S.u.S.E./openSUSE since 1996 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/13/2016 11:51 AM, Ken Schneider wrote:
I would always put safety/stability above ease. People above all else want a stable system.
Why would state swap do that? What ever's in there is no longer relevant. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-13 21:36, James Knott wrote:
On 04/13/2016 11:51 AM, Ken Schneider wrote:
I would always put safety/stability above ease. People above all else want a stable system.
Why would state swap do that? What ever's in there is no longer relevant.
He referred to the previous paragraph:
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.
- -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcOoWEACgkQja8UbcUWM1xnpAD8DYlfvrj8CM1PUgmMjD688M/z 8vIk8lVyjgIip5UHgEQA/j8DACtYFMVtP2xxhRqfra+pcpdpFWfdtGPmvpQs0FmI =HIio -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
13.04.2016 18:32, Ancor Gonzalez Sosa пишет:
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.
Hibernation with multiple Linux instances is questionable at the very least. If we use default scheme with master grub2 and os-prober generated menu entries, then LinuxB has no easy way to configure bootloader in LinuxA, which means user must remember to manually select LinuxB from LinuxA menu. If (s)he does not do it, LinuxA boots. Also even if hibernation image is preserved, if LinuxA tries to access any filesystem of LinuxB, it gets corrupted. So basically either we find how to ensure how to boot the right instance after resume automatically, in which case it really does not matter whether swap is shared, or we lost anyway :)
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.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-04-13 18:46, Andrei Borzenkov wrote:
Also even if hibernation image is preserved, if LinuxA tries to access any filesystem of LinuxB, it gets corrupted.
Yes, I was going to say this. It gets awfully corrupted, in fact, beyond repair most times. In fact, during hibernation grub disables the boot menu, so that the user can not choose a different system to boot to avoid precisely this scenario. I don't see an advantage to creating another swap. If wanted, it must be a manual and intentional choice, and another for presenting grub menu after hibernation. Long explanation: When trying to mount a filesystem belonging to an hibernated machine (A), the (B) system sees it as dirty and does an fsck on it, which probably succeeds. But (A) has a memory image of what should be that mounted filesystem, with files opened and half written. When it comes out of hibernation, at some time it will write those files to the blocks it would have used previously, not matching what (B) did with the fsck. The result is awful corruption. I know this from personal experience. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Ancor Gonzalez Sosa composed on 2016-04-13 17:32 (UTC+0200):
Having separate swap partitions is safer from the hibernation point of view, but it consumes potentially valuable space just to make sure that
I wonder the value of space given how much disks have grown in capacity. OTOH, if booting and running from SSD, what point is there to having swap?
you can run a Linux system while the other is hibernated, which can be considered a pretty weird scenario.
Do multibooters really hibernate as a matter of course? I would think it no small problem to remember which was last used if employing hibernation and shared swap.
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?
I don't think it makes sense to do any presuming in a multiboot environment. Probably the only valid presumption would be if the existing installation(s) contain "noresume" in their boot stanzas. In other cases, the question should be posed the user. All my PCs are multiboot. Most have only one disk. None have more than one swap partition per disk. But, all my partitioning is always completed and formatted prior to beginning any distro installation, so I always use expert mode anyway. -- "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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 14/04/2016 3:05 AM, Felix Miata wrote:
I wonder the value of space given how much disks have grown in capacity.
OTOH, if booting and running from SSD, what point is there to having swap?
Keeping your open applications, documents and layout. I hibernate after the end of every work day, means I'm straight back into things the next day. -- Lindsay Mathieson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Lindsay Mathieson composed on 2016-04-14 07:01 (UTC+1000):
Felix Miata wrote:
I wonder the value of space given how much disks have grown in capacity.
OTOH, if booting and running from SSD, what point is there to having swap?
Keeping your open applications, documents and layout.
That the job I expect the DE to do, not the underlying OS or kernel. These operating systems are by their nature multiuser. Does hibernating even ever work when one user decides the machine's whole assortment of users needs to sleep? -- "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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 14/04/2016 7:17 AM, Felix Miata wrote:
That the job I expect the DE to do, not the underlying OS or kernel. These operating systems are by their nature multiuser.
Session restore is very limited in it support, there are many tjhings it doesn't cover.
Does hibernating even ever work when one user decides the machine's whole assortment of users needs to sleep?
Not an issue for as sole user of my desktop. -- Lindsay Mathieson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-13 23:38, Lindsay Mathieson wrote:
On 14/04/2016 7:17 AM, Felix Miata wrote:
That the job I expect the DE to do, not the underlying OS or kernel. These operating systems are by their nature multiuser.
Session restore is very limited in it support, there are many tjhings it doesn't cover.
That is so. I also hibernate at the end of the day, often more.
Does hibernating even ever work when one user decides the machine's whole assortment of users needs to sleep?
Not an issue for as sole user of my desktop.
Nor in an office. At the end of the day, all machines may hibernate. It is possible to automate this, when a machine is idle. With caveats. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcOxz0ACgkQja8UbcUWM1wrtQD8Cm4pmg+FWPKp1CzBVIugqpaS nxL9/KrPad44+xiCdG4A/2tm9eNVnHDVuDxUCZcWFd82H4/Ap0IRhE6mNV3Y4LAv =gUBw -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op donderdag 14 april 2016 07:01:39 CEST schreef Lindsay Mathieson:
On 14/04/2016 3:05 AM, Felix Miata wrote:
I wonder the value of space given how much disks have grown in capacity.
OTOH, if booting and running from SSD, what point is there to having swap?
Keeping your open applications, documents and layout. I hibernate after the end of every work day, means I'm straight back into things the next day.
The point in my case, to be precise: - A Kate session with 183 files open - Lowriter and Localc with multiple files open - Chromium and Firefox with multiple tabs open - Kontact open - and so on. All this in < 2 seconds back from suspend. BTW. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-04-14 08:49, Knurpht - Gertjan Lettink wrote:
Op donderdag 14 april 2016 07:01:39 CEST schreef Lindsay Mathieson:
On 14/04/2016 3:05 AM, Felix Miata wrote:
I wonder the value of space given how much disks have grown in capacity.
OTOH, if booting and running from SSD, what point is there to having swap?
Keeping your open applications, documents and layout. I hibernate after the end of every work day, means I'm straight back into things the next day.
The point in my case, to be precise: - A Kate session with 183 files open - Lowriter and Localc with multiple files open - Chromium and Firefox with multiple tabs open - Kontact open - and so on. All this in < 2 seconds back from suspend.
Suspend or hibernate? Suspend, which works on RAM, is bound to restore fast, no surprise there. Hibernate needs reading the image from disk, but if it is an SSD it should also be fast. How much, I don't know personally. That would be interesting to know. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Op donderdag 14 april 2016 11:30:30 CEST schreef Carlos E. R.: > On 2016-04-14 08:49, Knurpht - Gertjan Lettink wrote: > > Op donderdag 14 april 2016 07:01:39 CEST schreef Lindsay Mathieson: > >> On 14/04/2016 3:05 AM, Felix Miata wrote: > >>> I wonder the value of space given how much disks have grown in capacity. > >>> > >>> OTOH, if booting and running from SSD, what point is there to having > >>> swap? > >> > >> Keeping your open applications, documents and layout. I hibernate after > >> the end of every work day, means I'm straight back into things the next > >> day.> > > The point in my case, to be precise: > > - A Kate session with 183 files open > > - Lowriter and Localc with multiple files open > > - Chromium and Firefox with multiple tabs open > > - Kontact open > > - and so on. > > All this in < 2 seconds back from suspend. > > Suspend or hibernate? Suspend, which works on RAM, is bound to restore > fast, no surprise there. Hibernate needs reading the image from disk, > but if it is an SSD it should also be fast. How much, I don't know > personally. That would be interesting to know. Sorry, resume from hibernation that is. I tried a couple of times and it's < 3 seconds, to be fair. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-14 13:25, Knurpht - Gertjan Lettink wrote:
Sorry, resume from hibernation that is. I tried a couple of times and it's < 3 seconds, to be fair.
Wow. Fast. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcQQpYACgkQja8UbcUWM1yqUAD/VNm2N8gv3V+TO0qLfhnaS0k3 Eq8x0oMk9SY02jz8af0A/jxoMHaxaYrueDziTEQ16u6A6K4yxFhOGWp15RoqmNKs =IIhg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 15/04/2016 11:23 AM, Carlos E. R. wrote:
Sorry, resume from hibernation that is. I tried a couple of times
and it's < 3 seconds, to be fair.
Wow. Fast.
Thats about what I get (SSD boot). Turn the PC on and its ready before I sit down. -- Lindsay Mathieson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-15 03:36, Lindsay Mathieson wrote:
On 15/04/2016 11:23 AM, Carlos E. R. wrote:
Sorry, resume from hibernation that is. I tried a couple of times
and it's < 3 seconds, to be fair.
Wow. Fast.
Thats about what I get (SSD boot). Turn the PC on and its ready before I sit down.
With all your programs ready and open files at the same point they were before? In the exact same window positions? Cursors at the same points? In my experience, no, unless you hibernate. That's what Knurpht reported doing with SSD. Talking of a dozen Firefox windows, Thunderbird windows, LibreOffice windows, and other gazillion applications. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcQSOAACgkQja8UbcUWM1wOIQD/bw9tzztaQYLgHmLhTdmI31mZ eckVjkz/tA80LYIA8rwA/2SM/w/2eEw6et4jxbTEhIP0dz6/l7dEdF6gwknkVFmy =3vuQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 15/04/2016 11:50 AM, Carlos E. R. wrote:
With all your programs ready and open files at the same point they were before? In the exact same window positions? Cursors at the same points?
In my experience, no, unless you hibernate. That's what Knurpht reported doing with SSD.
Some confusion perhaps? from hibernation is what I meant and I thought the OP meant. -- Lindsay Mathieson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Apr 14, 2016 at 7:23 PM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-04-14 13:25, Knurpht - Gertjan Lettink wrote:
Sorry, resume from hibernation that is. I tried a couple of times and it's < 3 seconds, to be fair.
Wow. Fast.
I'm skeptical this is Linux resume from hibernate. It takes longer than this for the firmware to get through POST, let alone the bootloader and kernel loading. Less than three seconds is consistent with firmware managed resume from suspend to disk, a.k.a. IRST. And the kernel has support for it, but I'm not aware if anything that initiates suspend (systemd?) is using that sysfs function yet. But this form of firmware managed suspend is only found on UEFI firmware computers, and requires a specific dedicated partition with a defined partition type GUID. It cannot use the Linux swap partition. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ancor Gonzalez Sosa wrote:
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.
I think the best default will be to use an existing swap-partition, if found and of adequate size. Those with a gazillion Linuxi installed will know how to change that. -- Per Jessen, Zürich (9.7°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 13 Apr 2016 20:13, Per Jessen
Ancor Gonzalez Sosa wrote:
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.
I think the best default will be to use an existing swap-partition, if found and of adequate size. Those with a gazillion Linuxi installed will know how to change that.
Just including a warning for multiboot systems with more than Linux would be a big plus. My Idea would be a two lines with a radio button beforehand: [x] Each Linux gets its own private swap [ ] One swap for all Linux installations Please allow for a Help text below that, that gives the pro / contra for each option. IMHO the biggest minus in the implementation of hibernation per se is the non-handling of open files / application states. But that reaches much deeper, to the fact that only a very small number of applications are programmed in a way that includes handling system failure, and implement signal handlers for a 'system stop' event. The more 'modern' a complex application (even DE) is the more prone to catastrophic failure with data-loss in the event of a mishandled wake-up. A filesystem can sync and flush buffers as much as it want when the running apps have no way of saving state-save-files, and are forced to keep the volatile data in RAM (and thus saved to swap). Due to inconsisties in the mains power supply, I can not use suspend alone, hibernate is not as nice but works, but hybrid-sleep is what I use the most. The whole grub situation is dissatisfying, for me the salvage was chain-loading. On this dual boot CentOS 7 / Leap 42 box, I have Leap as the primary UEFI option, and in the Leap menu I have a chain load to the CentOS shim/grub, ditto in reverse, next step was disabling the "osprober". But that is work done by hand, there is not GUI for such a config. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/13/2016 02:13 PM, Per Jessen wrote:
Ancor Gonzalez Sosa wrote:
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. I think the best default will be to use an existing swap-partition, if found and of adequate size. Those with a gazillion Linuxi installed will know how to change that.
mkswap /dev/fd0 ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
13.04.2016 22:34, James Knott пишет:
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.
You never hibernate? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/13/2016 11:19 PM, Andrei Borzenkov wrote:
13.04.2016 22:34, James Knott пишет:
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.
You never hibernate?
No, I keep going over winter. ;-) Actually, I wasn't thinking of hibernating when I wrote that. When you do a shut down, everything in swap is stale. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/14/2016 01:12 PM, James Knott wrote:
On 04/13/2016 11:19 PM, Andrei Borzenkov wrote:
13.04.2016 22:34, James Knott пишет:
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.
You never hibernate?
No, I keep going over winter. ;-)
Wow! It took 20 hours of thread for this joke to appear. I was expecting it much earlier. ;-D Have fun! -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 14/04/2016 1:32 AM, Ancor Gonzalez Sosa wrote:
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.
Go with the safe option, keep them separate. The user can always override in expert mode. -- Lindsay Mathieson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-13 22:59, Lindsay Mathieson wrote:
On 14/04/2016 1:32 AM, Ancor Gonzalez Sosa wrote:
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.
Go with the safe option, keep them separate. The user can always override in expert mode.
But it is not safe. It is more dangerous, in fact. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcOyEwACgkQja8UbcUWM1yX2QD/UfwS3HbAL7yH2fm/yHVZUX0h tJAkj/k20kT7D7ECd+sBAI3aIzoEUK5QSmSTablt8emAQsFdjjdt6B9Zcd/LYicX =zqB4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-14 01:10, Lindsay Mathieson wrote:
On 14/04/2016 8:29 AM, Carlos E. R. wrote:
But it is not safe. It is more dangerous, in fact.
How so?
The proposal says "Having separate swap partitions is safer from the hibernation point of view," but it is not so. Booting system (B) while (A) is hibernated is terribly dangerous because the boot procedure of (B) will run fsck on the already mounted, but hibernated, filesystems that (A) mounted. When, in due time, system (A) thaws, it will try to use what he thinks are open files, on partitions that have run fsck on them meanwhile. The in-memory filesystem structures do not match the on-disk structures. This cycle causes terrible corruption, beyond repair. If you don't believe me, try it, in a virtual environment with two Linuxes that you can afford to destroy. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcO3zwACgkQja8UbcUWM1xTIQEAkeLiBU7qFF+z1DMK2TU1C2yo qBoiCa+FWPmJDmSvVe8BAJyWmCAIt5zO14CF5XGx+nrLiX1I92uhI+IKbSq8zYq/ =Zg/l -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Apr 13, 2016 at 6:07 PM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-04-14 01:10, Lindsay Mathieson wrote:
On 14/04/2016 8:29 AM, Carlos E. R. wrote:
But it is not safe. It is more dangerous, in fact.
How so?
The proposal says "Having separate swap partitions is safer from the hibernation point of view," but it is not so. Booting system (B) while (A) is hibernated is terribly dangerous because the boot procedure of (B) will run fsck on the already mounted, but hibernated, filesystems that (A) mounted. When, in due time, system (A) thaws, it will try to use what he thinks are open files, on partitions that have run fsck on them meanwhile. The in-memory filesystem structures do not match the on-disk structures. This cycle causes terrible corruption, beyond repair.
If you don't believe me, try it, in a virtual environment with two Linuxes that you can afford to destroy.
Yes but that sequence involves multiple instances of sufficiently bad implementation that it's sabotage. Isn't it? - The DE needs permission and capability to make certain there's a bootloader and bootloader configuration that definitely boots the right OS, to ensure resume happens at next boot. That means tacit permission on BIOS systems to overwrite the existing bootloader installation. On UEFI there's already a shared location for bootloaders and their own configuration files, so all the DE needs to do is modify the bootloader configuration file and NVRAM boot next. - In an alternate universe, we only have bootloaders that can read standardized bootloader configuration formats, stored in a standard location which is shared among all distros; this would obviate the need for the DE to overwrite the bootloader each time hibernation is called on a multiboot system. Since neither of those things is apparently true with any certainty, the logical conclusion for any DE that cares about user data, is to not offer hibernation anywhere in the GUI by default. It's the domain of experts only, it's too complicated and fragile to extend this to regular users. So I think the DE's need to hide any reference to hibernation/suspend to disk by default. And the installer should not include resume= as a kernel boot parameter. It's better to drop the hibernation image entirely than for it to get picked up after the file system it applies to has even been mounted, let alone had fsck run on it. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-04-14 03:53, Chris Murphy wrote:
On Wed, Apr 13, 2016 at 6:07 PM, Carlos E. R. <> wrote:
...
If you don't believe me, try it, in a virtual environment with two Linuxes that you can afford to destroy.
Yes but that sequence involves multiple instances of sufficiently bad implementation that it's sabotage. Isn't it?
No. The "sabotage" is bypassing the fact that grub does not allow to choose another system to boot while recovering from hibernation, because the scenario I described is known. On a typical machine with one Linux and Windows there is no issue. With several Linuxes, but a common grub (which is never the case), no issue in this respect either. With UEFI I do not know. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thu, Apr 14, 2016 at 3:37 AM, Carlos E. R.
On 2016-04-14 03:53, Chris Murphy wrote:
On Wed, Apr 13, 2016 at 6:07 PM, Carlos E. R. <> wrote:
...
If you don't believe me, try it, in a virtual environment with two Linuxes that you can afford to destroy.
Yes but that sequence involves multiple instances of sufficiently bad implementation that it's sabotage. Isn't it?
No. The "sabotage" is bypassing the fact that grub does not allow to choose another system to boot while recovering from hibernation, because the scenario I described is known.
I think it's very much approaching sabotage to give users an easy way to corrupt their systems. So if the installer sets up swap and boot parameters to support hibernation, and the desktop environment makes it easy to hibernate (either by default or with an easily discoverable option in the UI), and yet that same DE does not have either the ability to confirm the installed bootloader *will* resume correctly or overwrite the bootloader with one that will, then yes I'd call that sabotage. You're talking about data loss or corruption is the inevitable result. I have a very high burden for how GUI installers and desktop environments behave. I don't care about expert users. The expert users are happy to be left alone and hopefully not have things silently break on them. But regular users need more attention. Breaking their installations isn't fair. So maybe dual boot/multiboot is just too complicated for normal users and it's not possible right now to design something safe for them? And if so, that's fine, then the installer should deny dual boot installations with pre-existing Linux when using the default-automatic partitioning and installation path. Only allow it for custom installations. I mean, this whole idea we'd ever want to foist data damage onto new users because they should learn esoteric bootloader things is silly. That's not required to safely dual boot on Windows or OS X. So I suggest you either deny the user the ease of getting into trouble, or make it fail safe. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-04-15 01:57, Chris Murphy wrote:
I have a very high burden for how GUI installers and desktop environments behave. I don't care about expert users. The expert users are happy to be left alone and hopefully not have things silently break on them. But regular users need more attention. Breaking their installations isn't fair. So maybe dual boot/multiboot is just too complicated for normal users and it's not possible right now to design something safe for them? And if so, that's fine, then the installer should deny dual boot installations with pre-existing Linux when using the default-automatic partitioning and installation path. Only allow it for custom installations.
Agreed, dual Linux booting is complicated. Dual, meaning, one Linux, one Windows, is quite a common thing: most people coming from Windows will want this, so it must be handled. Two Linux is the next step, but how to do it should be an informed decision by the "admin". Not exactly automated. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlcQR6UACgkQja8UbcUWM1w+jQD/bX5tawpGjmNpERx3PVzgZSlP UeeKq/3bUSWCQA6m5ckA/ArBQ1wy07Z6y4OZLxIoaV0Zoey6tQVarDGRTP1SbDUM =Xs1h -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Apr 14, 2016 at 9:45 PM, Carlos E. R.
Agreed, dual Linux booting is complicated. Dual, meaning, one Linux, one Windows, is quite a common thing: most people coming from Windows will want this, so it must be handled.
For those that don't know: Windows 8 and newer have a "off" state where they leave NTFS volumes in a particular unclean state. ntfs-3g is able to recognize that state and it refuses totally to work with those volumes until windows is rebooted and cleanly shutdown. It sounds like Linux needs to add some similar hibernation related locks to dirty filesystems to prevent the data corruption Carlos is talking about. Until that happens, I vote one swap per system. Greg -- Greg Freemyer www.IntelligentAvatar.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Apr 13, 2016 at 9:32 AM, Ancor Gonzalez Sosa
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?
I suggest you keep doing what you've been doing, the path of lease resistance, until there are resources to do this correctly. And to do it correctly means getting distros together and agreeing on scope and details of a bootloader specification or standard. So far there's an insufficient concensus; and GRUB upstream is opposed to the specs as written so far. So until the bootloader upstreams will take multiboot Linux seriously, you pretty much have to continue to give up on this pipe dream. https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ Part of the problem of doing this correctly is that it should be encrypted by default.
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.
Why is it even remotely easy to boot Linux A if Linux B is hibernated? The bootloader should be informed that Linux A will be resumed by default. The filesystem state of Linux B is questionable until resume happens so it's risky to boot Linux A while B is hibernated. How do you negotiate dual boot hibernation even with separate swaps without the two distros communicating system state unambiguously to the bootloader?
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?
Support Intel Rapid Start, which uses its own partition type? I don't even really care about the dual boot scenario. I'd like my Linux only system to have parity with Windows and OS X when it comes to fast resumes from hibernation on modern hardware. The way this is done right now with Linux swap is so slow it's basically faster to just cold boot than do a resume from suspend to disk, that's how bad it is. Another nice thing about Intel Rapid Start is lid closure defaults to suspend to RAM, and only after power getting below a certain amount does the firmware wake up the system and switch to suspend to disk without having to involve the kernel. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
14.04.2016 00:17, Chris Murphy пишет:
I suggest you keep doing what you've been doing, the path of lease resistance, until there are resources to do this correctly. And to do it correctly means getting distros together and agreeing on scope and details of a bootloader specification or standard. So far there's an insufficient concensus; and GRUB upstream is opposed to the specs as written so far.
Reference please. As far as I remember GRUB upstream maintainer did not like specific patch implementing parsing of these specs that is part of Fedora (or at least was proposed there). Nobody ever submitted support for it upstream, so how can you say upstream is opposed to it?
So until the bootloader upstreams will take multiboot Linux seriously, you pretty much have to continue to give up on this pipe dream.
https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/
I assume Microsoft and Apple are also willing to support it?
Part of the problem of doing this correctly is that it should be encrypted by default.
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.
Why is it even remotely easy to boot Linux A if Linux B is hibernated?
Because if Linux B is booted through bootloader manager by Linux A, then Linux B has no way to modify its configuration, it simply is not aware of it. And having common bootloader specs still leaves the question which OS instance manages bootloader *installation* and update. So this requires quite a big change in how this part is managed - and this in every distribution out there. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Apr 13, 2016 at 9:37 PM, Andrei Borzenkov
14.04.2016 00:17, Chris Murphy пишет:
I suggest you keep doing what you've been doing, the path of lease resistance, until there are resources to do this correctly. And to do it correctly means getting distros together and agreeing on scope and details of a bootloader specification or standard. So far there's an insufficient concensus; and GRUB upstream is opposed to the specs as written so far.
Reference please. As far as I remember GRUB upstream maintainer did not like specific patch implementing parsing of these specs that is part of Fedora (or at least was proposed there). Nobody ever submitted support for it upstream, so how can you say upstream is opposed to it?
The spec itself was considered problematic, not just the Fedora implementation of that spec (which departs from the spec in meaningful ways). No direction on how to improve the spec to meet upstream's concerns has been given. http://lists.gnu.org/archive/html/grub-devel/2013-06/msg00023.html The entire point of a boot specification is constraint, so naturally there will be use cases that can't be supported. The spec is a subset of common functionality designed to make things easier for users who will accept standardization via completely automatic, non-customizable, installations. The experts can do things how they've been doing it if they want.
So until the bootloader upstreams will take multiboot Linux seriously, you pretty much have to continue to give up on this pipe dream.
https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/
I assume Microsoft and Apple are also willing to support it?
That's misplaced, they're not going to change. And there isn't a problem on their end anyway. Microsoft and Apple support n and n+1 versions simultaneously installed, and that does work reliably for both of them. They also haven't changed their boot methods in a sufficiently long period of time that they're each defacto standards. The problem really is for the users who want two or more Linux distro-versions. I can name at least one major distro that face plants on setting up boot out of the box for n and n+1, it's that bad. As soon as n+1 is installed, n can't be booted without user intervention. Horrible. Now maybe we should just admit that only experts get to multiboot? Maybe regular users just are just out of luck?
Part of the problem of doing this correctly is that it should be encrypted by default.
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.
Why is it even remotely easy to boot Linux A if Linux B is hibernated?
Because if Linux B is booted through bootloader manager by Linux A, then Linux B has no way to modify its configuration, it simply is not aware of it.
I know, that's my complaint. Windows and OS X have had such mechanisms for a very long time, 20+ years. The mechanism details isn't what matters, it's the fact they designed for this use case. Linux bootloader upstreams and distros haven't. They really simply haven't done that work. It's only accessible by expert users.
And having common bootloader specs still leaves the question which OS instance manages bootloader *installation* and update. So this requires quite a big change in how this part is managed - and this in every distribution out there.
The spec says each OS manages those updates into a common shared location in an unambiguous way for a single (conforming) bootloader to act upon. Since they both can't be running at the same time, it's reasonable to conclude the current boot communicates user intent via a common shared configuration location and file format. And yes, no kidding, big change. Cooperation among distros is like finding water in a desert. Maybe it's even more rare, and the whole idea is just doomed to evaporation and what we have is as good as it's going to get. And if that's true, then I just don't see how we proceed to the next step which is safely supporting hibernation in a multiboot context. If the booting of two or more Linux OS's can't be agreed upon cooperatively I don't see how hibernation of those OS's gets sorted out. Any installer asked to do a multiboot installation should probably configure the system in such a way that the user can't (easily) hibernate the system. Experts will just have to go unhide/enable hibernation manually since they're aware of the risks. It's not fair to do that to regular users asking for automatic installations from a GUI installer. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-04-14 08:47, Chris Murphy wrote:
On Wed, Apr 13, 2016 at 9:37 PM, Andrei Borzenkov <> wrote:
And if that's true, then I just don't see how we proceed to the next step which is safely supporting hibernation in a multiboot context.
Ah. I understand now.
If the booting of two or more Linux OS's can't be agreed upon cooperatively I don't see how hibernation of those OS's gets sorted out. Any installer asked to do a multiboot installation should probably configure the system in such a way that the user can't (easily) hibernate the system. Experts will just have to go unhide/enable hibernation manually since they're aware of the risks. It's not fair to do that to regular users asking for automatic installations from a GUI installer.
Have the selection done at UEFI, not on Grub. But some manufacturers refuse to support multiple systems on UEFI, we saw this recently :-( -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
14.04.2016 09:47, Chris Murphy пишет:
On Wed, Apr 13, 2016 at 9:37 PM, Andrei Borzenkov
wrote: 14.04.2016 00:17, Chris Murphy пишет:
I suggest you keep doing what you've been doing, the path of lease resistance, until there are resources to do this correctly. And to do it correctly means getting distros together and agreeing on scope and details of a bootloader specification or standard. So far there's an insufficient concensus; and GRUB upstream is opposed to the specs as written so far.
Reference please. As far as I remember GRUB upstream maintainer did not like specific patch implementing parsing of these specs that is part of Fedora (or at least was proposed there). Nobody ever submitted support for it upstream, so how can you say upstream is opposed to it?
The spec itself was considered problematic, not just the Fedora implementation of that spec (which departs from the spec in meaningful ways). No direction on how to improve the spec to meet upstream's concerns has been given.
http://lists.gnu.org/archive/html/grub-devel/2013-06/msg00023.html
The entire point of a boot specification is constraint, so naturally there will be use cases that can't be supported. The spec is a subset of common functionality designed to make things easier for users who will accept standardization via completely automatic, non-customizable, installations. The experts can do things how they've been doing it if they want.
Ah, right. OK, there is long distance between using this spec as default configuration and being able to parse it. grub2 supports parsing of legacy menu.lst and syslinux.cfg and I do not see any issue in adding parser for bootloader specification. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2016 10:32 AM, Ancor Gonzalez Sosa wrote:
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?
I would go with reusing the existing swap (if a suitable size). I agree with Carlos and Andrei. The first boot after hibernate should be to the hibernated system. Re-using swap enforces that (or at least encourages that). Full disclosure -- I rarely hibernate. If I want to start the system where it left off, then I leave it running overnight. I tend to see hibernation as a really ugly hack. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJXDre4AAoJEGSXLIzRJwiFicMH/033NHGDQ3x/Ewgg2z5Nj/KS gHaMf+/PJ5++PpJiKSzIez/VgyIro5kGcXP4AV1hwralb9pYkwvRWbnJ6nljD5lX xKOnSMiuifD7zH18OatQ91IkOY+2GlxITTEwmtv0tqnZ5hKx9lfB+LUaWz4dETKi hHxAapNkgy7imzMl27LVW4T5952dQL7cN0n5WFwTG0qOMts8XHR8ayUsTTS82QtO PUtoZXQfUQaaQj966Zv9mlHqxPdco/A9epj23nKfC55+Jmsw/fwl/KGqy2v+CzXD M0Dt2/l7kFQsm/6LCtdc7axLE7sU3POxOJ3hbjc2tkZfI7ZKViFdDCQovmKDaAc= =sATJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/13/2016 05:18 PM, Neil Rickert wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/13/2016 10:32 AM, Ancor Gonzalez Sosa wrote:
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?
I would go with reusing the existing swap (if a suitable size).
I agree with Carlos and Andrei. The first boot after hibernate should be to the hibernated system. Re-using swap enforces that (or at least encourages that).
Full disclosure -- I rarely hibernate. If I want to start the system where it left off, then I leave it running overnight. I tend to see hibernation as a really ugly hack.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQEcBAEBAgAGBQJXDre4AAoJEGSXLIzRJwiFicMH/033NHGDQ3x/Ewgg2z5Nj/KS gHaMf+/PJ5++PpJiKSzIez/VgyIro5kGcXP4AV1hwralb9pYkwvRWbnJ6nljD5lX xKOnSMiuifD7zH18OatQ91IkOY+2GlxITTEwmtv0tqnZ5hKx9lfB+LUaWz4dETKi hHxAapNkgy7imzMl27LVW4T5952dQL7cN0n5WFwTG0qOMts8XHR8ayUsTTS82QtO PUtoZXQfUQaaQj966Zv9mlHqxPdco/A9epj23nKfC55+Jmsw/fwl/KGqy2v+CzXD M0Dt2/l7kFQsm/6LCtdc7axLE7sU3POxOJ3hbjc2tkZfI7ZKViFdDCQovmKDaAc= =sATJ -----END PGP SIGNATURE-----
+1 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
14.04.2016 00:18, Neil Rickert пишет:
Full disclosure -- I rarely hibernate. If I want to start the system where it left off, then I leave it running overnight. I tend to see hibernation as a really ugly hack.
Note that systemd tries hybrid suspend by default which means your system may hibernate on its own ...
On Wednesday, April 13, 2016 5:32:20 PM PDT 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 would recommend adding user-option for either keeping/creating, suggest keep for home user/single user and separate swap where security may be an issue. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2016-04-13 17:32, Ancor Gonzalez Sosa wrote:
Having separate swap partitions is safer from the hibernation point of view,
I would speculate that anyone with hardware capable of battery-backed s2ram is unlikely to use s2disk presuming that cases of low-battery are comparatively rare. So, if you detect a laptop in yast, go with 1-swap-for-all. If you detect a non-laptop, {see other subthreads posted for this topic}. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2016-04-14 at 10:48 +0200, Jan Engelhardt wrote:
On Wednesday 2016-04-13 17:32, Ancor Gonzalez Sosa wrote:
Having separate swap partitions is safer from the hibernation point
of
view,
I would speculate that anyone with hardware capable of battery-backed s2ram is unlikely to use s2disk presuming that cases of low-battery are comparatively rare. So, if you detect a laptop in yast, go with
They are not. Batteries by definition have too little capacity. Regards Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op donderdag 14 april 2016 10:48:21 CEST schreef Jan Engelhardt:
On Wednesday 2016-04-13 17:32, Ancor Gonzalez Sosa wrote:
Having separate swap partitions is safer from the hibernation point of view,
I would speculate that anyone with hardware capable of battery-backed s2ram is unlikely to use s2disk presuming that cases of low-battery are comparatively rare. So, if you detect a laptop in yast, go with 1-swap-for-all. If you detect a non-laptop, {see other subthreads posted for this topic}.
Makes sense to me. +1 -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 13.04.2016 20:32, Ancor Gonzalez Sosa wrote:
...
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.
Hey ! You know what you should do ? Use zram (compressed swap in RAM) when system is installed on SSD (or on non-rotating media in general) and stop caring about hibernation which is an ugly crutch for slow-booting OSes, installed on obsolete hardware. So the effort would be better spent updating "compcache" package into part of YaST partitioner and a default systemd service. You will never satisfy hibernation-lovers, especially those with old laptops under multiple OSes. They only way to sort out this _deprecated_ mess is for bootloader to force the boot of hibernated OS which now is pretty much impossible with whole U/EFI & multiple Linux'es competing for GRUB management.
participants (21)
-
Ancor Gonzalez Sosa
-
Andrei Borzenkov
-
Bruno Friedmann
-
Carlos E. R.
-
Chris Murphy
-
Daniele
-
emanuel
-
Felix Miata
-
Greg Freemyer
-
Hendrik Woltersdorf
-
James Knott
-
Jan Engelhardt
-
Ken Schneider
-
Knurpht - Gertjan Lettink
-
Lindsay Mathieson
-
Neil Rickert
-
Oliver Neukum
-
Per Jessen
-
Roman Bysh
-
Sergey Kondakov
-
Yamaban