[Bug 758539] New: autoyast forgets DNS settings in resolv.conf in stage 2.
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c0
Summary: autoyast forgets DNS settings in resolv.conf in stage
2.
Classification: openSUSE
Product: openSUSE 12.1
Version: Final
Platform: All
OS/Version: openSUSE 12.1
Status: NEW
Severity: Normal
Priority: P5 - None
Component: AutoYaST
AssignedTo: ug@suse.com
ReportedBy: them4z@googlemail.com
QAContact: qa-bugs@suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101
Firefox/11.0
When installing with autoyast (with keep_install_network; with sysvinit, but
unsure if this latter fact matters), /etc/resolv.conf will be empty when stage
2 comes up, resulting in various subsequent errors for profile content that
tries to use DNS (like <add-on>).
Workaround: Add the following script (which also verifies that the resolv.conf
was indeed empty):
---------- 8< ----------
<scripts>
<post-scripts config:type="list">
<script>
<debug config:type="boolean">true</debug>
<feedback config:type="boolean">false</feedback>
<filename>fixresolv</filename>
<interpreter>shell</interpreter>
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c1
Uwe Gansert
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c2
--- Comment #2 from C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c3
C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c4
Uwe Gansert
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c5
Uwe Gansert
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c6
--- Comment #6 from C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c7
C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c8
Uwe Gansert
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c9
Martin Vidner
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c10
Michal Filka
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c11
Michal Filka
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c12
C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c13
Michal Filka
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c14
Thomas Fehr
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c15
Michal Filka
Which yast2 client writes /etc/resolv.conf?
it is "lan_auto.ycp" in this case -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c16
Thomas Fehr
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c17
--- Comment #17 from C. Holm
I've reproduced the bug in 13.1 M4: - /etc/resolv.conf is empty at the end of first stage / begining of second stage
/etc/resolv.conf has proper/expected content when second stage is over.
Ah, interesting. I was never able to test that because our stage 2 fails for various reasons when DNS is unavailable. (And I haven't tested 13.1m4 yet; the following comments have been tested up to 12.3.)
I think, there is nothing what yast2-network can fix. It seems to me as requirement for another order of modules' proposals.
I don't think I understand what you're saying. It worked in the past (but see below), why is this serious change of behaviour considered to be ok?
(Note: according comment#1, requirement was to make dns configuration available earlier for use in addons)
I think you misunderstood me. I'm not talking about some rarely used addons, "<add-on>" is the AutoYAST feature that allows you to install from network repos, a pretty basic feature of AutoYAST. And I don't know and don't really care about *when* the relevant module writes the DNS configuration. I would like it to work the way it worked before. DNS basically *is* "network" to the general population. My stage2 depends on the network and DNS (is this such a crazy idea?), *plus* I'm using "keep_install_network", and, according to http://doc.opensuse.org/projects/autoyast/configuration.html#CreateProfile.N...,
YaST will keep network settings created during installation (via Linuxrc) and/or merge it with network settings from the AutoYaST profile (if defined). AutoYaST settings have higher priority than already present configuration files. […] If there is an empty or no dns and routing section, YaST will keep already present values. Otherwise settings from the profile will be applied.
However, with this bug, this is untrue. Stage2 will have no DNS, and hence if one tries to use it, the install will never be able to complete. (Ironically, in the case of scripts fetched from the network, AutoYAST doesn't recognize they're empty files because the network was down and reports them as having completed successfully. But I should maybe put this into a separate bug report.) Sorry if I sound rude, I don't mean to offend anybody. I just don't have insight into the AutoYAST development process and don't I'm pretty sure I misunderstood some of your comments. It sounds to me like you're saying "it has always been this way (which is untrue) and WONTFIX". -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c18
--- Comment #18 from C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c19
--- Comment #19 from Michal Filka
I think, there is nothing what yast2-network can fix. It seems to me as requirement for another order of modules' proposals.
I don't think I understand what you're saying. It worked in the past (but see below), why is this serious change of behaviour considered to be ok?
It was noted mainly for autoyast maintainer. Autoyast calls yast modules involved in installation in some order. Currently, it seems that this order doesn't fit to your needs. I don't say it is true, it is first idea. I'm still working on the issue but I need to cooperate with AY maintainer.
(Note: according comment#1, requirement was to make dns configuration available earlier for use in addons)
I think you misunderstood me. I'm not talking about some rarely used addons, "<add-on>" is the AutoYAST feature that allows you to install from network repos, a pretty basic feature of AutoYAST. And I don't know and don't really care about *when* the relevant module writes the DNS configuration.
Yes. You don't care. But I have to, when other parts of installation depends on it. Requirement probably wasn't correct word. Something like "dns configuration must be available for following modules and addons" is probably better.
I would like it to work the way it worked before. DNS basically *is* "network" to the general population. My stage2 depends on the network and DNS (is this such a crazy idea?), *plus* I'm using "keep_install_network", and, according to http://doc.opensuse.org/projects/autoyast/configuration.html#CreateProfile.N...,
YaST will keep network settings created during installation (via Linuxrc) and/or merge it with network settings from the AutoYaST profile (if defined). AutoYaST settings have higher priority than already present configuration files. […] If there is an empty or no dns and routing section, YaST will keep already present values. Otherwise settings from the profile will be applied.
However, with this bug, this is untrue. Stage2 will have no DNS, and hence if one tries to use it, the install will never be able to complete.
I don't say, you are wrong. Moreover, I've explicitly agreed (in comment#13) that resolv.conf is empty at the beginning of second stage. However, yast2-network's AY part didn't change much during last year. So, as written above, I need to cooperate with AY maintainer to find out what has changed. He works 400km far from me in different country, so sharing thoughts via bugzilla is easiest for us. That is the sense of Comment#13.
(Ironically, in the case of scripts fetched from the network, AutoYAST doesn't recognize they're empty files because the network was down and reports them as having completed successfully. But I should maybe put this into a separate bug report.)
During my tests I found one funny thing already. When you pass AY profile via AutoYast param, which references some network location (e.g. autoyast=http://<somewhere>/ay.xml) amd you do installation from dvd, you have to use netsetup=1 (or similar) too, otherwise you don't have net connection. Well, (guessing know) it is because linuxrc do not look into autoyast param value ... But it definitely is user unfriendly.
Sorry if I sound rude, I don't mean to offend anybody. I just don't have insight into the AutoYAST development process and don't I'm pretty sure I misunderstood some of your comments. It sounds to me like you're saying "it has always been this way (which is untrue) and WONTFIX".
No, I'm not saying that. I tried to describe current situation or better to say situation which I was able to reproduce. I think, I've never closed any bug as WONTFIX yet. I still work on it, it will probably take some time (AY / Installation bugs always does), but only confirmation from customer that we found working solution makes me happy ;-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c20
Michal Filka
in autoyast I call
LanUdevAuto.Import(Ops.get_map(Profile.current, "networking", {}))
Michal, could there be circumstances where this would create an empty resolf.conf?
LanUdevAuto handles only udev rules. Everything other is done in lan_auto.rb (particularly in "Write" call)
What is strange, is that linuxrc create a resolv.conf if nameserver= is provided on command line even before yast gets started. So it seems something in yast is overwriting resolv.conf with a empty one. If you can reproduce this (I failed with keep_install_network=true), could you let something like
(while true; do date --rfc-3339=ns; cat /etc/resolv.conf; sleep 0.1; done > /tmp/rs)
I'll try to find something. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c21
--- Comment #21 from C. Holm
I think, there is nothing what yast2-network can fix. It seems to me as requirement for another order of modules' proposals.
I don't think I understand what you're saying. It worked in the past (but see below), why is this serious change of behaviour considered to be ok?
It was noted mainly for autoyast maintainer. Autoyast calls yast modules involved in installation in some order. Currently, it seems that this order doesn't fit to your needs. I don't say it is true, it is first idea. I'm still working on the issue but I need to cooperate with AY maintainer.
Ok, thank you very much for clarifying. Previously, I understood your reply as "It seems to me we need to propose a few new modules that fulfill this requirement". Now I get that you mean "It seems to me as if we need to reorder the module execution".
(Note: according comment#1, requirement was to make dns configuration available earlier for use in addons)
I think you misunderstood me. I'm not talking about some rarely used addons, "<add-on>" is the AutoYAST feature that allows you to install from network repos, a pretty basic feature of AutoYAST. And I don't know and don't really care about *when* the relevant module writes the DNS configuration.
Yes. You don't care. But I have to, when other parts of installation depends on it. Requirement probably wasn't correct word. Something like "dns configuration must be available for following modules and addons" is probably better.
Yes, sorry again, I was being snappy because I misunderstood your first paragraph.
I would like it to work the way it worked before. DNS basically *is* "network" to the general population. My stage2 depends on the network and DNS (is this such a crazy idea?), *plus* I'm using "keep_install_network", and, according to http://doc.opensuse.org/projects/autoyast/configuration.html#CreateProfile.N...,
YaST will keep network settings created during installation (via Linuxrc) and/or merge it with network settings from the AutoYaST profile (if defined). AutoYaST settings have higher priority than already present configuration files. […] If there is an empty or no dns and routing section, YaST will keep already present values. Otherwise settings from the profile will be applied.
However, with this bug, this is untrue. Stage2 will have no DNS, and hence if one tries to use it, the install will never be able to complete.
I don't say, you are wrong. Moreover, I've explicitly agreed (in comment#13) that resolv.conf is empty at the beginning of second stage. However, yast2-network's AY part didn't change much during last year. So, as written above, I need to cooperate with AY maintainer to find out what has changed. He works 400km far from me in different country, so sharing thoughts via bugzilla is easiest for us. That is the sense of Comment#13.
I saw that you agreed with me, but i over-interpreted your "/etc/resolv.conf has proper/expected content when second stage is over." as "so this bug is not so bad after all". I apologize. Let's say I've had some frustrating bug report experiences in the past. (;
(Ironically, in the case of scripts fetched from the network, AutoYAST doesn't recognize they're empty files because the network was down and reports them as having completed successfully. But I should maybe put this into a separate bug report.)
During my tests I found one funny thing already. When you pass AY profile via AutoYast param, which references some network location (e.g. autoyast=http://<somewhere>/ay.xml) amd you do installation from dvd, you have to use netsetup=1 (or similar) too, otherwise you don't have net connection. Well, (guessing know) it is because linuxrc do not look into autoyast param value ... But it definitely is user unfriendly.
I think that is expected, autoyast= is not enough, you either need to use netsetup=1 or also include a "networked" repo (install={http,nfs,…}). IIRC, this is only "documented" on the AutoYAST mailinglist, though.
Sorry if I sound rude, I don't mean to offend anybody. I just don't have insight into the AutoYAST development process and don't I'm pretty sure I misunderstood some of your comments. It sounds to me like you're saying "it has always been this way (which is untrue) and WONTFIX".
No, I'm not saying that. I tried to describe current situation or better to say situation which I was able to reproduce.
I think, I've never closed any bug as WONTFIX yet. I still work on it, it will probably take some time (AY / Installation bugs always does), but only confirmation from customer that we found working solution makes me happy ;-)
Thanks for taking the time to calm me down. (; Taking hours to debug an issue until it can be reported, then taking more time to write the report and followups can be frustrating when nothing happens with the report for months, especially when the first reaction after that time sounds like "sorry, you're out of luck". -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c22
Thomas Fehr
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c23
--- Comment #23 from C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c24
--- Comment #24 from C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c25
--- Comment #25 from C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c26
--- Comment #26 from C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c27
--- Comment #27 from Thomas Fehr
From your attached logs, I conclude you use <add-on> section.
If you have a nonempty <add-on> section in your profile, autoyast is completely broken on 13.1 see bnc#846011. So maybe you now hit bnc#846011 instead of the problem originally reported in this bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c28
--- Comment #28 from C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c29
--- Comment #29 from Thomas Fehr
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c30
Thomas Fehr
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c31
C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c32
Thomas Fehr
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c33
C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c34
C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c35
--- Comment #35 from C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c36
--- Comment #36 from C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c37
--- Comment #37 from C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c38
--- Comment #38 from C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c39
C. Holm
https://bugzilla.novell.com/show_bug.cgi?id=758539
https://bugzilla.novell.com/show_bug.cgi?id=758539#c40
Thomas Fehr
participants (1)
-
bugzilla_noreply＠novell.com