Bug 1099187 - Don't delete the partition for Intels' Rapid Start Technology during installation
Don't delete the partition for Intels' Rapid Start Technology during installa...
Status: RESOLVED FEATURE
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Installation
Current
Other Other
: P5 - None : Enhancement (vote)
: ---
Assigned To: E-mail List
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-06-26 15:40 UTC by Jürgen Löhel
Modified: 2019-04-15 12:20 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jürgen Löhel 2018-06-26 15:40:48 UTC
Hello,

the proposal for the partitioning during the installation process provides that a partition of the type 0x84 or with the GUID D3BFE2DE-3DAF-11DF-BA-40-E3A556D89593 should be marked for deletion. This partition is necessary for Intels Rapid Start Technology[1] and should be not marked for deletion.
Moreover it would be great to create a partition of the this type manually during the installation process.

Best regards
Jürgen

[1] https://software.intel.com/en-us/articles/what-is-intel-rapid-start-technology
Comment 1 Stefan Hundhammer 2018-06-27 09:53:23 UTC
We'll see what we can do here.

Please notice that the automated storage proposal is just that - a proposal. You may or may not choose to accept it. In this special scenario, right now it is probably more useful to use the "guided setup" where you can choose the partitions to delete to make room for the Linux installation, and simply keep that special partition.

We will have to discuss internally how to handle this; most likely, we will have to start a whitelist with partitions that we should not touch in the storage proposal. I guess there will be more than just this type.

As for creating those special partitions: Creating the partition is just one step. Surely there must be some data content on it to be useful; how should the YaST installer handle that? Where would we get those data from? We'll look into the specs you posted (thanks for that!) to find out what makes sense here.
Comment 2 Stefan Hundhammer 2018-06-27 10:04:10 UTC
More info on that technology:

  https://mjg59.dreamwidth.org/26022.html
Comment 3 Stefan Hundhammer 2018-06-27 10:06:33 UTC
Summary:

- It's waking up from suspend-to-RAM just before the battery dies completely, then suspending to disk

- The partition is typically empty - no content to copy to it

- It only works with SSDs (?)
Comment 4 Stefan Hundhammer 2018-06-27 10:09:30 UTC
IMHO this is an interesting feature, but it will need to be decided on a higher level. Please open a FATE request for this and refer to this bug, and please also add the FATE number to this bug.
Comment 5 Oliver Neukum 2018-06-27 11:10:17 UTC
(In reply to Stefan Hundhammer from comment #4)
> IMHO this is an interesting feature, but it will need to be decided on a
> higher level. Please open a FATE request for this and refer to this bug, and
> please also add the FATE number to this bug.

Deleting the partition also breaks to an extent the current installation of other OSes. So are you sure that the mere preservation of the partition as opposed to creating it requires a FATE?
Comment 7 Stefan Dirsch 2018-06-27 13:12:28 UTC
Well, the intention of this bugreport was not enabling this feature on Linux, but just not to mark such a partiion as to be deleted in the proposal any longer, if a Windows partition is detected as well. I assume here, that we don't mark Windows partition as to be deleted in our proposal by default, right? I believe we want to be good citizens and are not interested into killing the "Rapid Start Technology" feature on Windows either when not killing the Windows partition.