[opensuse-autoinstall] Debugging autoyast
During my 12.1 bughunt, I (re-)encountered some inconsistencies that I've been wanting to ask (and nag) about since I started working with autoyast a few years back, and a few new ones: 1. autoyast generates a lot of messages. For an autoyast dev, this might be wonderful, but dumb users like myself are simply lost in tens of thousands of messages. It makes finding errors in the logs really hard, especially when you don't know what string(s) you're looking for. It would be great if there was, for example, an additional warnings-and-errors-only log. 2. autoyast generates a lot of "noise" in diffs. When cloning a system with yast or editing it manually and then running it through yast again to check for errors, yast changes the profile in various ways. This makes it sometimes harder to see the "real" differences. (In general, one could say everything is fine because the inconsistencies below all "converge" towards a final state, but nevertheless I sometimes wonder why these things happen.) 2.a) (this is new in 12.1 and did not happen before:) for some reason the DNS settings are not kept for stage 2, so I need this script in 12.1: <script> <debug config:type="boolean">true</debug> <feedback config:type="boolean">false</feedback> <filename>fixresolv</filename> <interpreter>shell</interpreter> <network_needed config:type="boolean">true</network_needed> <source><![CDATA[resolv=$(cat /etc/resolv.conf) if [ -z "$resolv" ]; then echo "# resolv.conf was empty, ftfy. nameserver a.b.c.d" >> /etc/resolv.conf fi ]]></source> </script> 2.b) <keep_install_network> is _always_ deleted by yast. 2.c) even though a <runlevel> section exists, the package yast2-runlevel is not automatically installed. 2.d) even though mail settings (aliases, mailrelay) exist, the package yast2-mail is not automatically installed. 2.e) When *cloning* an existing system, I see inconsistent and sometimes non-helpful behavior. What happens is that for certain settings (see below), there are different cases that can happen: 1. tag doesn't exist vs. 2. tag exists but is empty vs. 3. tag exists with default/cloned value Of these three, only the last one is really helpful because I can actually see what value the cloned machine had set. Some of the settings where I have seen this in 12.1 are: <languages>, <filesystem_id>, <partition_id>, <displaymanager_shutdown>, <displaymanager_xserver_tcp_port_6000_open>, <run_updatedb_as>, <hibernate_system>, <smtpd_listen_remote>, <dhclient_client_id>, <nss_base_{passwd,group,shadow}>. I have only had my eye really close on the <password_settings> section, the behavior was like this: * random existence of default value or empty tag (this happened for both the complete section or parts of it, depending on which parts of it were set to the default on the cloned machine) * if it did exist with empty values, yast (sometimes) deletes (some of!) those tags * if it did not exist, yast (sometimes) inserts (some of!) those tags with the default (non-empty) values (but *only* if the whole <password_settings> did not exist. if only parts are missing, these are not inserted) In the two former cases (no tag/empty tag), the user has to remove them from the profile, run it through yast again, and only then will the values appear (or it will not be added again by yast and wasn't so important anyway). 2.f) While the sections in the profile seem to be sorted alphabetically by yast, 1. the order of <users> seems to be random, 2. the order of the <*packages> and <*patterns> sections seems to be nonrandom, but isn't nonalphabetic either. Does the order of these sections matter? If not, could the please be sorted deterministically (alphabetically, or, f.e., in order of UIDs for the users)? Right now, when comparing different profiles, the user has to do a lot of "merging" first before he/she can see the real differences. It would be really great if the debugging possibilites in autoyast would be improved. They've been a source of frustration to me over the last weeks. That all sounds so negative. Let me end with a big thank you to all contributors: Thank you. autoyast saves me a lot of time. (: -- Kind regards 686f6c6d / Christopher 'm4z' Holm -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
2.f) While the sections in the profile seem to be sorted alphabetically by yast,
The original author of the merge.xml has written for us some xslt files. Sort XML file $ xsltproc --output node.xml.sorted sort.xslt node.xml Make XML file more human readable $ xsltproc --output node.xml.pretty pretty.xslt node.xml We needed these xslt file to be able todo a merge independent from autoyast. Note: Maybe the CDATA section gets lost .... $ cat sort.xslt <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:param name="order" /> <xsl:output indent="yes" /> <xsl:template match="/*"> <xsl:copy> <xsl:copy-of select="@*" /> <xsl:for-each select="*"> <xsl:sort select="string-length(substring-before($order, name()))" /> <xsl:sort select="name()" /> <xsl:copy-of select="." /> </xsl:for-each> </xsl:copy> </xsl:template> </xsl:stylesheet> $ cat pretty.xslt <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:strip-space elements="*" /> <xsl:output indent="yes" /> <xsl:template match="node()"> <xsl:copy> <xsl:copy-of select="@*" /> <xsl:apply-templates /> </xsl:copy> </xsl:template> </xsl:stylesheet> Hth Hajo
On 19.04.2012 15:50, 686f6c6d wrote:
1. autoyast generates a lot of messages. For an autoyast dev, this might be wonderful, but dumb users like myself are simply lost in tens of thousands of messages. It makes finding errors in the logs really hard, especially when you don't know what string(s) you're looking for. It would be great if there was, for example, an additional warnings-and-errors-only log.
I know what you mean but it's not autoyast that is so verbose, it's yast as whole. If you do a manual installation or an autoinstallation makes no big difference. Especially libstorage and the package resolver are way too verbose. I can not change that easily. The loglines start like this: 2012-04-18 14:18:56 <3> 2012-04-18 14:18:56 <2> 2012-04-18 14:18:56 <1> the 3 means it was logged by y2error a 2 means it's a warning a 1 means, it's just a y2milestone (like a 'I was here' message for devlopers). but I know, reading a y2log file requires some experience
2. autoyast generates a lot of "noise" in diffs. When cloning a system with yast or editing it manually and then running it through yast again to check for errors, yast changes the profile in various ways. This makes it sometimes harder to see the "real" differences. (In general, one could say everything is fine because the inconsistencies below all "converge" towards a final state, but nevertheless I sometimes wonder why these things happen.)
autoyast transforms the XML file into ycp data structures and feeds those to the yast modules. The yast modules works with those and returns data structures back to autoyast where they are transformed into XML again. There is no information about any order that was in the XML file. The yast module often also returns the default values - even if they did not exist in the XML file before. That's important if defaults change. If a key gets lost, it's either not supported anymore or you found a bug.
2.a) (this is new in 12.1 and did not happen before:) for some reason the DNS settings are not kept for stage 2, so I need this script in 12.1:
please open a bug for that
2.b)<keep_install_network> is _always_ deleted by yast.
you mean the UI always drops that value? That's a bug then. Bugzilla please.
2.c) even though a<runlevel> section exists, the package yast2-runlevel is not automatically installed.
that's with every module. Every yast module tells autoyast "In your XML File, I am <bla_bla>" So autoyast knows whom to feed with the data from the XML file. The good thing with that is, AutoYaST itself does not have to know all yast modules that have autoyast support. You can create an autoyast module without changing anything in autoyast for it. The bad thing about that is, that autoyast can not know what to do with unknown sections. If there is a <runlevel> section but no yast2-runlevel module installed, then autoyast does not know what to do with that section - it ignores it then. Maybe an error popup would be nice in that case. Autoyast reads that information from the desktop files in /usr/share/applications/YaST2/
2.d) even though mail settings (aliases, mailrelay) exist, the package yast2-mail is not automatically installed.
same as above AutoYaST itself knows nothing about mail or which module is required to deal with those keys. When you install yast2-mail, then autoyast knows what to do with those keys because the desktop file is there
2.e) When *cloning* an existing system, I see inconsistent and sometimes non-helpful behavior. What happens is that for certain settings (see below), there are different cases that can happen: 1. tag doesn't exist vs.
that's not so nice
2. tag exists but is empty vs.
then the default is an empty string or the system has an empty string configured for that key
settings where I have seen this in 12.1 are: <languages>,<filesystem_id>,<partition_id>,
languages is probably really empty on the system If you don't have secondary languages installed it's empty. That's okay. filesystem_id I should remove partition_id should never be empty - that would be a bug
<displaymanager_shutdown>, <displaymanager_xserver_tcp_port_6000_open>,<run_updatedb_as>, <hibernate_system>,<smtpd_listen_remote>,<dhclient_client_id>, <nss_base_{passwd,group,shadow}>.
okay, those I don't know. They come from different yast modules and different developers. I'd have to check one by one and get in contact with the developer (three different developers in this case)
I have only had my eye really close on the<password_settings> section, the behavior was like this:
if you think you find inconsistency, then please open a bug report. I'll take a look and fix it or assign it to the right developer
2.f) While the sections in the profile seem to be sorted alphabetically by yast, 1. the order of<users> seems to be random,
they are probably stored in a hash in yast internally. So the order is the order the ycp-interpreter has sorted the keys in the hash-map That does not help you but explains why the order is random for the naked eye :)
2. the order of the<*packages> and<*patterns> sections seems to be nonrandom, but isn't nonalphabetic either.
same as 1 maybe. I'd have to take a closer look
Does the order of these sections matter?
no, for users and patterns the order does not matter. But autoyast does not know that, so it can not sort stuff like that by itself (well, for patterns that's not true, that really in the autoyast core) but users must be sorted by yast2-users
If not, could the please be sorted deterministically (alphabetically, or, f.e., in order of UIDs for the users)?
that could be changed for sure in the yast2-users module packages and patterns are handled in the autoyast core which is code that I maintain by myself.
That all sounds so negative. Let me end with a big thank you to all contributors: Thank you. autoyast saves me a lot of time. (:
never mind. Feedback is always appreciated - I don't take anything personal :) I know how frustrating it can be to debug something for days -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net listening to: "Traum vom Tod II" by Subway to Sally -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
On Thu, Apr 19, 2012 at 17:42, Hans-Joachim Ehlers <HansJoachim.Ehlers@eumetsat.int> wrote:
2.f) While the sections in the profile seem to be sorted alphabetically by yast,
The original author of the merge.xml has written for us some xslt files. [...] We needed these xslt file to be able todo a merge independent from autoyast.
I'm not too skilled in XSLT; this basically does the same kind of merging autoyast does, right? On Fri, Apr 20, 2012 at 11:50, Uwe Gansert <ug@suse.de> wrote:
On 19.04.2012 15:50, 686f6c6d wrote:
1. autoyast generates a lot of messages. For an autoyast dev, this might be wonderful, but dumb users like myself are simply lost in tens of thousands of messages. It makes finding errors in the logs really hard, especially when you don't know what string(s) you're looking for. It would be great if there was, for example, an additional warnings-and-errors-only log.
I know what you mean but it's not autoyast that is so verbose, it's yast as whole. [...] > The loglines start like this: 2012-04-18 14:18:56 <3> 2012-04-18 14:18:56 <2> 2012-04-18 14:18:56 <1> the 3 means it was logged by y2error a 2 means it's a warning a 1 means, it's just a y2milestone (like a 'I was here' message for devlopers).
but I know, reading a y2log file requires some experience
Wow, thanks, that is really useful information! I have noticed these numbers before but could never make heads or tails of them. I assumed they were some kind of "yast hierarchy depth" indicator. *leaves to grep "<[23]>" from recent y2log's* *returns grinning*: 199 (<2>) + 91 (<3>) lines are much better to work with than 56575. (:
2. autoyast generates a lot of "noise" in diffs. When cloning a system with yast or editing it manually and then running it through yast again to check for errors, yast changes the profile in various ways. This makes it sometimes harder to see the "real" differences. (In general, one could say everything is fine because the inconsistencies below all "converge" towards a final state, but nevertheless I sometimes wonder why these things happen.)
autoyast transforms the XML file into ycp data structures and feeds those to the yast modules. The yast modules works with those and returns data structures back to autoyast where they are transformed into XML again. There is no information about any order that was in the XML file.
Ah, too bad. So to change this behaviour, the respective yast modules would need to be changed, right?
The yast module often also returns the default values - even if they did not exist in the XML file before. That's important if defaults change. If a key gets lost, it's either not supported anymore or you found a bug.
Ok, I will keep that in mind, investigate further and file bugs accordingly as you suggest below.
2.a) (this is new in 12.1 and did not happen before:) for some reason the DNS settings are not kept for stage 2, so I need this script in 12.1:
please open a bug for that
https://bugzilla.novell.com/show_bug.cgi?id=758539
2.b)<keep_install_network> is _always_ deleted by yast.
you mean the UI always drops that value? That's a bug then. Bugzilla please.
https://bugzilla.novell.com/show_bug.cgi?id=758529
2.c) even though a<runlevel> section exists, the package yast2-runlevel is not automatically installed. [2.d) same for yast2-mail]
that's with every module. Every yast module tells autoyast "In your XML File, I am <bla_bla>" So autoyast knows whom to feed with the data from the XML file. [...] AutoYaST itself knows nothing about mail or which module is required to deal with those keys. When you install yast2-mail, then autoyast knows what to do with those keys because the desktop file is there
(Without any knowledge of *yast code:) If that is the case, couldn't autoyast dynamically create a list of section-to-module entries and add these modules? Ah: Reading your comments below, I think I see the problem: This data is in "/usr/share/applications/YaST2/". The module has to be installed already for those files to exist and for autoyast to know anything about the sections. But on the "profile server" side, when creating a profile with YaST, this is also true, correct? So if I assume I can only add those sections whose modules are already installed on the server, couldn't YaST then add those modules involved to the <packages> section? Or are they pumping their sections into YaST "anonymously"?
The good thing with that is, AutoYaST itself does not have to know all yast modules that have autoyast support. You can create an autoyast module without changing anything in autoyast for it. The bad thing about that is, that autoyast can not know what to do with unknown sections. If there is a <runlevel> section but no yast2-runlevel module installed, then autoyast does not know what to do with that section - it ignores it then. Maybe an error popup would be nice in that case.
Yes please, that would be very helpful indeed (doesn't have to be an error though, I would be fine with a warning, too). We have a lot <remove-packages> because we don't agree with openSUSEs default desktop'ish package selection, and so we often run into transitive depencency problems where "Recommends:" (that's just an uninformed guess) like yast* are not pulled in.
Autoyast reads that information from the desktop files in /usr/share/applications/YaST2/
Looking into those files I don't quite understand how it works. (But don't be bothered by that. I'm not sure if I *want* to know. ^^) (Let me get back to you on 2.e etc. later this month.)
2. the order of the<*packages> and<*patterns> sections seems to be nonrandom, but isn't nonalphabetic either.
same as 1 maybe. I'd have to take a closer look [...]
Does the order of these sections matter?
no, for users and patterns the order does not matter. But autoyast does not know that, so it can not sort stuff like that by itself (well, for patterns that's not true, that really in the autoyast core) but users must be sorted by yast2-users
If not, could the please be sorted deterministically (alphabetically, or, f.e., in order of UIDs for the users)?
that could be changed for sure in the yast2-users module packages and patterns are handled in the autoyast core which is code that I maintain by myself.
That's surely a matter of preference, but I think an alphabetic order is much better suited to human debugging. (But it isn't too much of a hassle. Right now I only have to do a ":<,>sort" on these sections in vim).
That all sounds so negative. Let me end with a big thank you to all contributors: Thank you. autoyast saves me a lot of time. (:
never mind. Feedback is always appreciated - I don't take anything personal :) I know how frustrating it can be to debug something for days
Thank you so much... Did I mention that I hate Asparagus? Incidently, 12.1 is appropriately named. <; -- Kind regards 686f6c6d / Christopher 'm4z' Holm -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
participants (3)
-
686f6c6d -
Hans-Joachim Ehlers -
Uwe Gansert