Bug 1086754

Summary:	Disk capacity check before Kubic Installation
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Mikhail Kasimov <mikhail.kasimov>
Component:	Kubic	Assignee:	Forgotten User u0-bnvADNc <forgotten_u0-bnvADNc>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	rbrown
Version:	Current
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Mikhail Kasimov 2018-03-25 15:08:13 UTC

Hello!

Have tried to test Kubic on VirtualBox VM and faced with a problem of Kubic installation (see screenshot on Twitter-link below). One knows VirtualBox VM VDI disk is 8 GB by default.

And the problem was that Kubic needs > 16 GB to be successfully installed. 16 GB doesn't work. 17 GB is already OK.

See dialogue here: https://twitter.com/500mk500/status/977722519942762496?s=19

While Kubic is the set of pre-assembled packages with hardly constant minimal HDD requirements instead of classic openSUSE Leap/TW distro, HDD capacity is going to be much more critical for Kubic. And let Kubuc be able to check HDD capacity _before_ its installation process.

Idea for Realization:
=================
The most obvious way is to have an option in boot menu like 'Check Hard Disk Requirements before Installation'. And this option must be first by default and highlighted by cursor.
=================

Expectations:
=================
1. 'Check Hard Disk Requirements before Installation' should start initramfs, udev and hwinfo.

2. Then to parse hdd capacity.

3. If hdd < 17 GB, then return message: "Hard Disk Capacity is %number%. You need to have >=17GB to install openSUSE KubicProject successfully". By clicking OK, system returns to boot menu.

4. If hdd >= 17 GB, then return message: "Hard Disk Capacity is %number%. You can install openSUSE KubicProject successfully from boot menu". By clicking OK, system returns to boot menu.
=================

In general way, 'Check Hard Disk Requirements before Installation' is like to 'More' --> 'Check Installation Media' mechanism to its logic.

Another Way for Realization:
=================
Not to modify boot menu and work on hdd capacity comparison to >=17 GB on hardware detection step, when 'Installation' option is chosen.

If hdd < 17 GB, then return message: "Hard Disk Capacity is %number%. You need to have >=17GB to install openSUSE KubicProject successfully. Installation is stopped. Press any key..." By user's pressing any key, system returns boot menu.
=================

Please, consider! Thanks!

Comment 1 Richard Brown 2018-03-25 18:30:44 UTC

Hi!

Thanks for the bug report

We already have a check in YaST for the required disk size for Kubic

The problem is, the result of that check currently crashes yast

https://bugzilla.opensuse.org/show_bug.cgi?id=1076729

That's the crash you saw, which is how we were able to guess what the problem is

Closing this bug as a duplicate of that one - we can worry about fine tuning the check behaviour when we can read what it's saying without crashing the YaST installer

Thanks again for the report

*** This bug has been marked as a duplicate of bug 1076729 ***

Comment 2 Mikhail Kasimov 2018-03-26 10:41:16 UTC

(In reply to Richard Brown from comment #1)
> Hi!
> 
> Thanks for the bug report
> 
> We already have a check in YaST for the required disk size for Kubic
> 
> The problem is, the result of that check currently crashes yast
> 
> https://bugzilla.opensuse.org/show_bug.cgi?id=1076729
> 
> That's the crash you saw, which is how we were able to guess what the
> problem is
> 
> Closing this bug as a duplicate of that one - we can worry about fine tuning
> the check behaviour when we can read what it's saying without crashing the
> YaST installer
> 
> Thanks again for the report
> 
> *** This bug has been marked as a duplicate of bug 1076729 ***

Hello!

This report seems to be not as a dup of 1076729 as well, but as the second part of it: 1076729 describes the yast's crash, 1086754 describes the ways how to dialogue to user in case, when crash is gone away. So, I'm not entirely sure of closing current report. Reopen?

Comment 3 Richard Brown 2018-03-26 11:12:40 UTC

(In reply to Mikhail Kasimov from comment #2)

> Hello!
> 
> This report seems to be not as a dup of 1076729 as well, but as the second
> part of it: 1076729 describes the yast's crash, 1086754 describes the ways
> how to dialogue to user in case, when crash is gone away. So, I'm not
> entirely sure of closing current report. Reopen?

The crash is a crash while trying to show the dialogue very similar to the kind you're suggesting in this bug report

So I could have closed this bug as INVALID (this feature requested already exists), but it seemed more fair to close the bug as a DUPLICATE, as there is a legitimate issue showing the dialogue at the moment (boo#1076729)

Either way, I don't think we need to reopen the bug, and hope once we fix or workaround 1076729 then all the suggestions in this bug will be more or less handled.

Comment 4 Mikhail Kasimov 2018-03-26 11:17:16 UTC

(In reply to Richard Brown from comment #3)
> (In reply to Mikhail Kasimov from comment #2)
> 
> > Hello!
> > 
> > This report seems to be not as a dup of 1076729 as well, but as the second
> > part of it: 1076729 describes the yast's crash, 1086754 describes the ways
> > how to dialogue to user in case, when crash is gone away. So, I'm not
> > entirely sure of closing current report. Reopen?
> 
> The crash is a crash while trying to show the dialogue very similar to the
> kind you're suggesting in this bug report
> 
> So I could have closed this bug as INVALID (this feature requested already
> exists), but it seemed more fair to close the bug as a DUPLICATE, as there
> is a legitimate issue showing the dialogue at the moment (boo#1076729)
> 
> Either way, I don't think we need to reopen the bug, and hope once we fix or
> workaround 1076729 then all the suggestions in this bug will be more or less
> handled.

OK. Thanks!