|
Bugzilla – Full Text Bug Listing |
| Summary: | [Build 20190824] installation fails on setting uuid of btrfs | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Rodion Iafarov <riafarov> |
| Component: | AutoYaST | Assignee: | YaST Team <yast-internal> |
| Status: | VERIFIED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | ancor, aschnell, dgonzalez, emiura, jeriveramoya |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://trello.com/c/XibWb5sb | ||
| See Also: | http://bugzilla.suse.com/show_bug.cgi?id=1152535 | ||
| Whiteboard: | https://openqa.opensuse.org/tests/1018539/modules/installation/steps/5 | ||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
YaST logs
autoinst.xml used in testing (created from a fresh sle15sp1 install) |
||
|
Description
Rodion Iafarov
2019-08-28 07:03:36 UTC
libstorage-ng supports setting the UUID only for swap. FMPOV cloning should never try to clone any UUIDs since it would make UUIDs not unique. (In reply to Arvin Schnell from comment #2) > libstorage-ng supports setting the UUID only for swap. FMPOV cloning > should never try to clone any UUIDs since it would make UUIDs not unique. Well, setting the UUID via AutoYaST was possible in SLE-12 (and likely 11), as far as I can see in the documentation. So no matter whether it's a good practice or not, it should keep working in SLE-15. We can of course enhance the documentation to warm about the risks, but we must not fail. Also in libstorage I can only find code to set the UUID for swap. There are actually two use-cases: 1. Cloning As already stated UUID is, well, unique, so the default behavior should not be to export configuration using UUID. While comparing the probability, it's not that likely that the same UUID will be present. Of course, it may happen. And for that reason ... 2. AutoInstallation All ways of (supported) defining a disk / partition should be available also for AutoYaST. In other words, Import must be able to accept UUID. For instance, rules/classes could be used to identify the hardware and thus the customer is actually able to know which UUID is there. It's even easier in VMs. Bug reached SLE 15 SP2: https://openqa.suse.de/tests/3381986# *** Bug 1152535 has been marked as a duplicate of this bug. *** Looking at the full picture, there are several problems here. 1) The AutoYaST documentation about the uuid attribute is confusing, not to say plain wrong. 2) Cloning the system should never include the uuid field in the <partition> sections (since that value is only useful to reuse existing partitions). This is only broken in TW and the upcoming 15.2. In 15.1 the uuid field is not exported to the profile. 3) The process should not fail if the profile includes the uuid field for a new device (i.e. a device that is not being reused). That's what the bug report was about originally. This was already broken in 15.1 (it also fails if a surplus uuid field is included), but it has not been observed before because (2) works ok in 15.1, so we were not autogenerating wrong profiles. 4) While checking this, we found out that reusing devices by UUID (the only thing for which the uuid field is useful) is not working. That was also already broken in 15.1. I'm already working in fixing the four problems in all the affected branches. (In reply to Ancor Gonzalez Sosa from comment #9) > Looking at the full picture, there are several problems here. Fixing (1): https://github.com/SUSE/doc-sle/pull/483 Fixing (3) and (4) in 15.1: https://github.com/yast/yast-storage-ng/pull/976 More to come. (In reply to Ancor Gonzalez Sosa from comment #10) > Fixing (3) and (4) in 15.1: > https://github.com/yast/yast-storage-ng/pull/976 Corresponding maintenance request: https://build.suse.de/request/show/202407 Fixing (2), (3) and (4) in the master branch (that is, 15.2 and TW): https://github.com/yast/yast-storage-ng/pull/977 (In reply to Ancor Gonzalez Sosa from comment #12) > Fixing (2), (3) and (4) in the master branch (that is, 15.2 and TW): > https://github.com/yast/yast-storage-ng/pull/977 Corresponding SR to TW: https://build.opensuse.org/request/show/735289 Corresponding SR to SLE-15-SP2 (and Leap 15.2): https://build.suse.de/request/show/202431 With that, we can consider the bug as fixed (for all images including yast2-storage-ng >= 4.2.46). (In reply to Ancor Gonzalez Sosa from comment #9) Just some final notes for extra fun. That's what I managed to find via digital archeology. Maybe I'm wrong at some point. > 1) The AutoYaST documentation about the uuid attribute is confusing, not to > say plain wrong. The uuid attribute was added to the documentation (with a misleading description) many years ago (6 at least). But as far as I was able to discover, it was never part of the AutoYaST schema definition and was never used for anything in the AutoYaST code. Neither for setting the UUID of the created device or for searching for devices to reuse. So, for years, the attribute only existed in the documentation! > 4) While checking this, we found out that reusing devices by UUID (the only > thing for which the uuid field is useful) is not working. That was also > already broken in 15.1. As said before, reusing by UUID was actually never implemented before (I just did it for the first time in my mentioned requests). The first reference to the possibility of using the UUID to indicate the device to reuse was introduced in the documentation in Dec 2017 (https://github.com/SUSE/doc-sle/commit/6e1294c1e1ad3ffb4fc270138c1d7bf9a0133988). And after talking to Imobach I just found it was kind of an accident. Likely he meant "label" instead. :-) Anyway, since we introduced that in the documentation by mistake... now we support it. And at least the attribute "uuid" is used for something now, after years of being in the documentation for no reason. :-) Fixed in 20191009, thanks for the patch! Hello. Would you have an example autoinst.xml for this test? I was using the attached autoinst.xml, but it didn't succeeded on keeping the uuid after the installation (no messages complaining about the uuid tag, though).\ I have loaded the updated yast2-storage-ng and yast2-installer using a dud. Created attachment 822445 [details]
autoinst.xml used in testing (created from a fresh sle15sp1 install)
(In reply to Ednilson Miura from comment #18) > Hello. Would you have an example autoinst.xml for this test? I was using the > [...] but it didn't succeeded on keeping the uuid after the > installation (no messages complaining about the uuid tag, though). That's because cloning the UUID has never been a real possibility. That defeats the purpose of the UUID (being unique). As explained in previous comments, the presence of the uuid field in the AutoYaST profile is kind of an historical accident and it has never worked to enforce the UUID in the final system. After the latest changes, the uuid field can be used to look for a device in order to reuse it. But that's it. SUSE-RU-2019:3322-1: An update that has 8 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1130988,1136463,1139808,1141006,1148477,1149011,1151075,1152535 CVE References: Sources used: SUSE Linux Enterprise Module for Basesystem 15-SP1 (src): yast2-installation-4.1.47-3.6.18, yast2-storage-ng-4.1.90-3.16.11 SUSE Linux Enterprise Installer 15-SP1 (src): yast2-installation-4.1.47-3.6.18, yast2-storage-ng-4.1.90-3.16.11 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. openSUSE-RU-2019:2705-1: An update that has 8 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1130988,1136463,1139808,1141006,1148477,1149011,1151075,1152535 CVE References: Sources used: openSUSE Leap 15.1 (src): yast2-installation-4.1.47-lp151.2.6.1, yast2-storage-ng-4.1.90-lp151.2.9.1 |