http://bugzilla.suse.com/show_bug.cgi?id=1161331 http://bugzilla.suse.com/show_bug.cgi?id=1161331#c1 --- Comment #1 from Ancor Gonzalez Sosa --- This is the unit test proving the bug exists https://github.com/yast/yast-storage-ng/pull/1027 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1161331 http://bugzilla.suse.com/show_bug.cgi?id=1161331#c2 Ancor Gonzalez Sosa changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Shivani_Changela@dell.com --- Comment #2 from Ancor Gonzalez Sosa --- *** Bug 1161678 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1161331 http://bugzilla.suse.com/show_bug.cgi?id=1161331#c4 --- Comment #4 from Ancor Gonzalez Sosa --- Shivani Changela, I also have a request for you. In bug#1161678 you just attached the y2log file. But there is a lot of useful information that is not there. Could you please do like Nanda did in bug#1120859 and collect the whole YaST logs using save_y2logs? See https://en.opensuse.org/openSUSE:Report_a_YaST_bug Please, attach the resulting file here. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1161331 http://bugzilla.suse.com/show_bug.cgi?id=1161331#c6 Ancor Gonzalez Sosa changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(nanda_kishore_chi | |nna@dell.com), | |needinfo?(Shivani_Changela@ | |dell.com) --- Comment #6 from Ancor Gonzalez Sosa --- (In reply to Ancor Gonzalez Sosa from comment #3)

So my question is: do my explanations fit your expectations about how the proposal should work on top of "virtual disks"?

Setting the needinfo on Shivani Changela and Nanda Kishore again, for them to reply to my questions about expectations and booting from software RAIDs. Talking about expectations, let me clarify two points. First, in the logs attached by Shivani Changela I can see these systems use EFI to boot. So everytime I say "partition of type bios_boot" in comment#3 I should had actually said "an ESP (EFI) partition". All other considerations stay exactly as they are. That being said, in the mentioned logs uploaded by Shivani Changela I can see this: A disk "/dev/sda" with a total size of 220 GiB and GPT partition table It contains a single "/dev/sda1" partition of 100 GiB A disk "/dev/sdb" with a total size of 910 GiB and GPT partition table It contains no partitions A disk "/dev/sdc" with a total size of 440 GiB and GPT partition table It contains a single "/dev/sdc1" partition of 100 GiB A disk "/dev/sdd" fully empty (not even partition table) A software RAID1 called "/dev/md/VirtualDisk01" formed by sda1 and sdc1 It contains a GPT partition table with: - An ESP (EFI) partition - Two Linux partitions formatted with XFS - A swap partition According to what I explained in comment#3, we (the YaST Team) wouldn't expect such system to be able to boot, since there is no ESP partition allocated in any real disk. The only ESP partition is inside a software RAID that is backed by partitions. So my question here is: does such system boot? So far, we had no evidence of S130/S140 controllers being able to boot from a software RAID if the needed partitions were not present in real physical disks. If you can prove that works, we would need to reconsider how the proposal works in those cases. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1161331 http://bugzilla.suse.com/show_bug.cgi?id=1161331#c7 NANDA KISHORE changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(nanda_kishore_chi | |nna@dell.com), | |needinfo?(Shivani_Changela@ | |dell.com) | --- Comment #7 from NANDA KISHORE --- (In reply to Ancor Gonzalez Sosa from comment #6)

(In reply to Ancor Gonzalez Sosa from comment #3)

...

So my question is: do my explanations fit your expectations about how the proposal should work on top of "virtual disks"?

Setting the needinfo on Shivani Changela and Nanda Kishore again, for them to reply to my questions about expectations and booting from software RAIDs.

Talking about expectations, let me clarify two points.

First, in the logs attached by Shivani Changela I can see these systems use EFI to boot. So everytime I say "partition of type bios_boot" in comment#3 I should had actually said "an ESP (EFI) partition". All other considerations stay exactly as they are.

That being said, in the mentioned logs uploaded by Shivani Changela I can see this:

A disk "/dev/sda" with a total size of 220 GiB and GPT partition table It contains a single "/dev/sda1" partition of 100 GiB

A disk "/dev/sdb" with a total size of 910 GiB and GPT partition table It contains no partitions

A disk "/dev/sdc" with a total size of 440 GiB and GPT partition table It contains a single "/dev/sdc1" partition of 100 GiB

A disk "/dev/sdd" fully empty (not even partition table)

A software RAID1 called "/dev/md/VirtualDisk01" formed by sda1 and sdc1 It contains a GPT partition table with: - An ESP (EFI) partition - Two Linux partitions formatted with XFS - A swap partition

According to what I explained in comment#3, we (the YaST Team) wouldn't expect such system to be able to boot, since there is no ESP partition allocated in any real disk. The only ESP partition is inside a software RAID that is backed by partitions.

So my question here is: does such system boot? So far, we had no evidence of S130/S140 controllers being able to boot from a software RAID if the needed partitions were not present in real physical disks. If you can prove that works, we would need to reconsider how the proposal works in those cases.

Ancor, till date, S130/S140/S150 was always working by booting from RAID1 ESP. On SLES15-SP1 is automatically creating ESP on the MDRAID Partition unlike the way you have mentioned in Comment #3 i.e. ESP should be on a physical drive/partition. Attaching the supporting logs from SLES15-SP1 installation(since SP2 we have infinite loop bug):y2logs, suggested paritioning screenshot, post os boot logs. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1161331 http://bugzilla.suse.com/show_bug.cgi?id=1161331#c9 --- Comment #9 from NANDA KISHORE --- Created attachment 829359 --> http://bugzilla.suse.com/attachment.cgi?id=829359&action=edit y2logs_SLES15SP1.tar.xz -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1161331 http://bugzilla.suse.com/show_bug.cgi?id=1161331#c11 --- Comment #11 from Ancor Gonzalez Sosa --- (In reply to Ancor Gonzalez Sosa from comment #1)

This is the unit test proving the bug exists https://github.com/yast/yast-storage-ng/pull/1027

I closed that in favor of https://github.com/yast/yast-storage-ng/pull/1043 The new pull request is based on the SLE-15-SP1 branch and proves the behavior of that release is exactly the one described by Nanda Kishore. So the goal here is not only to avoid the infinite loop but to make sure the same test run with the same result in the SLE-15-SP2 codebase. -- You are receiving this mail because: You are on the CC list for the bug.