Bug 1094927 - installer uses a second disk even if told not to do so
installer uses a second disk even if told not to do so
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Installation
Current
Other Other
: P3 - Medium : Normal (vote)
: ---
Assigned To: YaST Team
Jiri Srain
https://trello.com/c/iHloQBFN
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-05-28 17:20 UTC by Giacomo Comes
Modified: 2019-03-26 10:01 UTC (History)
3 users (show)

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


Attachments
requested log (433.34 KB, application/x-xz)
2018-05-29 16:14 UTC, Giacomo Comes
Details
installation log from usb pendrive (436.63 KB, application/x-xz)
2018-06-20 20:45 UTC, Giacomo Comes
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Giacomo Comes 2018-05-28 17:20:42 UTC
I have a efi PC where I want to install tumbleweed. The PC has a new unformatted disk or an old disk with a bios partition table.
I boot the PC with the installer on a USB pen drive.

When I get to the Suggested Partitioning screen I select Guided Setup.
Because the PC now has two disks (the internal one and the USB pen drive), I'm offered with the option to select the disks where I want to install tumbleweed.
I select the internal disk and deselect the USB pen drive.
I select Next and continue until I'm back to the Suggested Partitioning screen with the list of partitions that would be created.

Now everything is on /dev/sda (the internal disk) except /boot/efi which is on the USB pen drive which I told the partitioner not to use.

The result is that, if I proceed with the installation, the installer will write data on /dev/sdb (that I don't want), and no efi boot partition will be created on /dev/sda. The system will only boot if I leave the USB pen drive plugged.

This bug apply to Leap 15.0 as well.
Comment 1 Martin Vidner 2018-05-29 12:08:45 UTC
Thank you for the report!
Please attach the YaST logs: https://en.opensuse.org/openSUSE:Report_a_YaST_bug

(On a system that has been recently installed, the logs should still contain the problematic installation proposal)
Comment 2 Giacomo Comes 2018-05-29 16:14:29 UTC
Created attachment 771717 [details]
requested log
Comment 3 Knut Alejandro Anderssen González 2018-05-31 16:12:04 UTC
It reuses the existent boot/efi partition even when only /dev/sda was selected for the guided proposal.

Confirmed and added it to our internal SCRUM backlog in order to prioritize it for next SCRM sprints.
Comment 4 Ancor Gonzalez Sosa 2018-06-14 06:23:22 UTC
Information extracted from the logs.

This is not real hardware, but a QEMU virtual machine.

It's a network install (getting the distribution from http://192.231.93.104/opensuse/distribution/tumbleweed/repo/oss), not installing from the the sdb "pendrive".

If fact, sdb is not even recognized by the machine as a pendrive. As seen by the virtual machine, it's a regular internal hard disk.

Moreover, sdb is not an openSUSE installation media at all. It's a disk of 500 MiB containing only an ESP EFI partition and nothing else. The typical (open)SUSE installation pendrive would contain a 4 MiB EFI and another partition with the distribution.

I'm mentioning all that because at some point we feared this bug report could be showing a situation in which the installer was trying to reuse the EFI partition from the openSUSE installation pendrive. But that doesn't seem to be the case at all.

If sdb would have been an (open)SUSE pendrive, the disk would be discarded for all operations and the EFI wouldn't have been reused (because it's too small). I have verified that manually.

So back to the original topic: whether the guided setup should try to reuse the valid and properly-sized ESP partition that is on the HARD DISK sdb, even if it was told to install the system in sda. That's actually controversial.

We are considering to change that behavior, but so far we considered that sharing a sane ESP partition detected on the system with any other (potential) operating system installed there was the safer option in order to not confuse the EFI system (which typically works better with a single ESP partition in the system). We are strictly speaking not installing into sdb (specially in the sense that we are not creating/destroying any partition or filesystem there), we are just registering ourselves in an ESP partition that, from a first look, seems to be the one in use by the EFI system of that computer.

But, as mentioned. We are in the process of discussing the criteria for reusing stuff in general. This bug report will be taken into account during the process.
Comment 5 Giacomo Comes 2018-06-20 20:45:02 UTC
Created attachment 774748 [details]
installation log from usb pendrive

In response to comment 4:
this time I have attached an installation log done on a real hardware using a real USB pen drive as installation source.
The PC hard disk (sda) has a GPT partition table but no efi partition. The efi partition is on the USB pen drive (sdb) used to boot the PC.

Final result of the guided setup:
the installer install the OS on sda. It does not create an EFI boot partition on sda and it uses the EFI partition of the USB pen drive to write the boot files.

It looks to me that the final result is the same as with the previous one using the virtual machine, network install, and a small EFI disk image.

The only difference is that this time the guided setup did not give me the option to choose the installation disk. I could not tell it to not use sdb, but it used both available disk.
Comment 6 Steffen Winterfeldt 2019-03-26 10:01:17 UTC
Fixed with

https://github.com/yast/yast-storage-ng/pull/877

(it sticks to a single disk now).