As seamless as the upgrade from openSUSE Leap 15.2 to 15.3 may have been for ordinary users, I stumbled across some pitfalls in the Autoyast parts.
The thing is, I had no issues with my rather simple Autoyast control files for public VMs but the one for my VM host caused some trouble. Admittedly it uses some more sophisticated functionality such as pre-scripts detecting the device nodes to actually use.
Profile failed validation due to <keep_unknown_lv> element
At first, Yast would fail to validate the very same control file that worked without problems under openSUSE Leap 15.2, with an only partially helpful error message:
It turned out that
<keep_unknown_lv> was the culprit. keep_unknown_lv is supposed to tell the Yast partitioning code to leave alone any possibly existing logical volumes (LVs) in a volume group (VG) unless they have been explicitly specified in the control file’s partitioning section. This is useful e.g. in upgrade situations where the administrator might have created additional LVs for data storage, which, for heaven’s sake, should be left alone by Yast. Only after I removed this element would Yast accept the control file.
The reason for this is that
<keep_unknown_lv> is actually missing in the XML schema used to validate the control file, as one can verify by looking at the files in
/usr/share/YaST2/schema/autoyast/rng/. I reported this as bugzilla.opensuse.org bug #1191968.
The really funny part about this is that it’s not like it has accidentally been dropped between openSUSE Leap 15.2 and 15.3 — it’s missing in openSUSE 15.2’s schema files as well, for the simple reason that it has never been added to the schema at all!
But why did the control file then work with openSUSE Leap 15.2? In 15.2 the helper function
Yast::XML.XMLToYCPString (which in spite of its name parses a string representation of XML into a hash structure) used older built-in functionality (
SCR.Read) that was more relaxed than the newer code which now uses Nokogiri, a standard libxml2/libxslt-based Ruby module for dealing with XML. Nokogiri enforces coverage of the control file by the schema on Yast’s behalf, seemingly for the first time requiring full conformance.
Obviously, the proper fix for this issue would be for the openSUSE project to either supplement an updated installation system with an Autoyast schema that includes
<keep_unknown_lv> or to at least remove it from the Autoyast documentation — which would then mean that this functionality remains inaccessible to Autoyast control files.
Error handling for pre-scripts has been tightened
In openSUSE 15.2 this pre-script:
<script> <filename>stop_raid_resync_stage1_pre.sh</filename> <notification>Stopping any ongoing RAID-1 resync...</notification> <interpreter>shell</interpreter> <source> <![CDATA[ mdadm -D /dev/md0 | grep "resyncing" && echo "frozen" >/sys/block/md0/md/sync_action ]]> </source> </script>
simply ran even if
/dev/md0 was not available, in openSUSE 15.3 it triggered an error popup:
The obvious fix here was to modify the script to test for existance of
“No widget with ID contents” error shown shortly after pre-scripts ran
This one is the kinda bug that really surprises me for apparently having gone unnoticed so far. After pre scripts ran I got this:
Huh? Through trial and error I found out that this error message only appeared when using a
<notification> together with a pre-script. No idea why but I reported it as bugzilla.opensuse.org bug #1191972. So no
<notification> messages for the time being…
Internal error due to obsoleted <is_lvm_group> parameter
Yast would now show an “internal error” when trying to create partition plans:
This was because for volume groups an
<is_lvm_group> element was used. Some time ago it has been dropped in favor of a
construct (documented here).
The dropping itself was documented in the SLES 15 SP1 AutoYast guide but not the current (15.3) openSUSE AutoYast guide. It was mentioned in the openSUSE Leap 15.2 AutoYast guide, however, but, as mentioned above, 15.2’s more relaxed control file validation wouldn’t make me notice earlier.
At this point my control file now worked successfully, however I had to fix one more aspect that is unrelated to Autoyast, yet interesting because it relates to the change described above. I would now get this error message:
It turned out this error came from my custom yast-libvirt-import Yast module. What happened was that my code had to parse libvirt XML such as
and used said
Yast::XML.XMLToYCPString function described above for this, because under 15.2 Nokogiri wasn’t part of the installation system and all Yast code used that function instead. Now under 15.3, validation is enforced which means the
type attribute is expected to be one of the valid types for Autoyast control file elements (
symbol etc.)! There might be ways to supplement Yast’s XML function so it’s not restricted to Autoyast’s schema but since it’s already using Nokogiri below the hood, why not just use it directly, which is exactly what I did.