[Bug 966870] New: LVM+LUKS encrypted root partition created by Tumbleweed (and Leap) has on 10 GB space
http://bugzilla.suse.com/show_bug.cgi?id=966870 Bug ID: 966870 Summary: LVM+LUKS encrypted root partition created by Tumbleweed (and Leap) has on 10 GB space Classification: openSUSE Product: openSUSE Tumbleweed Version: 2015* Hardware: x86-64 OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Installation Assignee: yast2-maintainers@suse.de Reporter: peter.simons@suse.com QA Contact: jsrain@suse.com Found By: --- Blocker: --- Last week I installed two machines with Tumbleweed and Leap 42.1, respectively, and in both cases I chose an LVM/LUKS-encrypted installation using ext4 and no separate /home partition. The installation process worked fine. However, in both cases the installer created an install plan that reserved only 10 GB of space for the system's (encrypted) root partition -- leaving some ~450 GB of available disk space unused. That choice seems odd to me. I realize that it's a good idea to have some free space available on an LVM-managed disk so that people can create additional partitions, performs snapshots, etc. From that point of view, I think it's fine that the root partition didn't take up *all* the remaining disk space despite the fact that I chose the "use the entire disk" option. However, allocating only 10 GB for the root disk seems way too conservative, and I reckon that many users will not be happy with that default (like myself). My suggestion would be to implement behavior in the installer that works the other way round: rather than allocating a default partition that's minimal and trust that people will enlarge it when required, I'd rather see the installer create a root partition that's maximal and trust that people will shrink it if they want additional volumes in the /system group. In any case, 10GB for the root disk seems like an odd choice that's not going to work out for virtually anyone. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=966870 Arvin Schnell <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aschnell@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=966870 Peter Simons <peter.simons@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|LVM+LUKS encrypted root |LVM+LUKS encrypted root |partition created by |partition created by |Tumbleweed (and Leap) has |Tumbleweed (and Leap) has |on 10 GB space |only 10 GB space -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=966870 http://bugzilla.suse.com/show_bug.cgi?id=966870#c1 Gabriele Mohr <gs@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |shundhammer@suse.com Flags| |needinfo?(shundhammer@suse. | |com) --- Comment #1 from Gabriele Mohr <gs@suse.com> --- Stefan, probably this will be solved with new proposal? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=966870 http://bugzilla.suse.com/show_bug.cgi?id=966870#c2 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(shundhammer@suse. | |com) | --- Comment #2 from Stefan Hundhammer <shundhammer@suse.com> --- This can be configured by the product manager in the product's control.xml file: Minimum and base size (the normal desired size) of the root file system as well as how much of the system volume group's disk space remains unallocated. I agree that these days a mere 10 GB is very small for a root file system, so this root base size might be increased somewhat. But this is a config parameter outside the scope of YaST. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=966870 http://bugzilla.suse.com/show_bug.cgi?id=966870#c3 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|yast2-maintainers@suse.de |lnussel@suse.com --- Comment #3 from Stefan Hundhammer <shundhammer@suse.com> --- Reassigning to Leap PM. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=966870 http://bugzilla.suse.com/show_bug.cgi?id=966870#c4 Ludwig Nussel <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@suse.com Assignee|lnussel@suse.com |yast2-maintainers@suse.de --- Comment #4 from Ludwig Nussel <lnussel@suse.com> --- TW and Leap behave differently here. On TW the maximum root fs size is 20GB while on Leap it's 10. The leap setting is inherited from SLE. With BTRFS the numbers change again. There we have a multiplication factor which is two for TW and four for Leap. So with BTRFS we get 40GB in both cases. Default size 20 and multiplication factor 2 might be more reasonable indeed. And now for the funny part which seems to be a bug. According to the documentation (https://github.com/yast/yast-storage/blob/master/doc/config.xml.description#...) the root filesystem maximum is meant to be applied only in case a separate home partition is proposed. Without separate home root would consume all space. Indeed that is the case without lvm. When enabling lvm the root size limit is applied even though no separate home is proposed. So whatever one may think about good default settings, at least the behavior is not consistent with the documentation :-) Back to YaST. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=966870 http://bugzilla.suse.com/show_bug.cgi?id=966870#c5 Imobach Gonzalez Sosa <igonzalezsosa@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |igonzalezsosa@suse.com Flags| |needinfo?(shundhammer@suse. | |com) --- Comment #5 from Imobach Gonzalez Sosa <igonzalezsosa@suse.com> --- Stefan, please, could you take a look to Ludwig's comment? Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=966870 http://bugzilla.suse.com/show_bug.cgi?id=966870#c6 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(shundhammer@suse. | |com) | --- Comment #6 from Stefan Hundhammer <shundhammer@suse.com> --- AFAIK this clashes with the 'vm_desired_size' parameter. Not sure if the documentation for that one is 100% correct or even misleading; as I understood that one, it specifies how much of the total available volume group should be used for the proposal. The general idea is to not use all the available space so there is some available to resize any of the logical volumes. Arvin? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=966870 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(aschnell@suse.com | |) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=966870 http://bugzilla.suse.com/show_bug.cgi?id=966870#c7 Arvin Schnell <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(aschnell@suse.com | |) | --- Comment #7 from Arvin Schnell <aschnell@suse.com> --- AFAIS with LVM the root_base_size and root_max_size value is always used. So the documentation is wrong and should be fixed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=966870 http://bugzilla.suse.com/show_bug.cgi?id=966870#c11 --- Comment #11 from Marc collin <marc.collin@laboiteaprog.com> --- don't think severity should be enhancement with hd, ssd who are easily over 256gig... no being able to use all space of the hd... it's a big lost don't think majority of user will be able to resize -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=966870 http://bugzilla.suse.com/show_bug.cgi?id=966870#c12 Ancor Gonzalez Sosa <ancor@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED CC| |ancor@suse.com Resolution|--- |FIXED --- Comment #12 from Ancor Gonzalez Sosa <ancor@suse.com> --- The desired/max/min sizes has been adapted for both Tumbleweed and Leap. Hopefully, having all provided feedback (like this bug) into account. So I'm closing this. Please reopen if you think this is still wrong in Leap 15.1 or in the current Tumbleweed. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com