Bug 1096142

*** Bug 1096143 has been marked as a duplicate of this bug. ***

*** Bug 1096145 has been marked as a duplicate of this bug. ***

(In reply to uli fuerst from comment #0)
> I have saved the y2log file but I cannot see a way to attach it.

Use the "Add Attachment" option.

The attachment is over 80KB so therefore the connection refused. That was the reason for the duplicates of this bug - I thought the bug report did not get through either. Sorry about that.

Original forum report:
https://forums.opensuse.org/showthread.php/531481-upgrade-problems-cannot-mount-root-partition

I still don't know how to attach a 80Kb y2log-...tar.xz file and I don't know if it is possible to find the problem without the log file.

80 KiB should be no problem for bugzilla. Hmm https://xkcd.com/949/
If that does not work for you locally please find an alternative.

Created attachment 773067 [details]
save_y2logs file

Must have been a problem with my computer. It worked from a different one to send the attachment.

clearing needinfo flag

I found out that it crashes when YaST wants to copy /etc/resolv.conf from the inst-sys to /mnt (https://github.com/yast/yast-update/blob/75eaa6da6bf61188c7864a7d4e3cf9ebf6578eec/src/modules/RootPart.rb#L1722)

The error message is: Operation not permitted @ rb_sysopen - /mnt/etc/resolv.conf' (Errno::EPERM).

Do you use some special permissions or options for /etc (or /) in the system? What's the old system you are upgrading? Or any idea why that file could not be written?

Bug reporters are CC'd whether they want to be or not in all versions of bugzilla software since the beginning of time. Expressly adding the reporter's email address to the CC list is unnecessary conflation.

AS mentioned in the report, the system is Leap42.3, I didn't change any permissions so I presume they are standard. Here are the results or ls -l for /etc and /etc/resolv.conf. Hope that helps
drwxr-xr-x 149 root root   20480 Jun  8 12:26 etc
-rw-r--r--  1 root root       162 Dec 21  2016 resolv.conf

Something is strange - I have a whole lot of files /etc/resolv.conf, here are a few from the le -l command:
-rw-r--r--  1 root root       162 Dec 21  2016 resolv.conf
-rw-r--r--  1 root root       807 Oct 28  2012 resolv.conf.0bwWRT
-rw-r--r--  1 root root       807 Sep 27  2012 resolv.conf.0NRBtG
-rw-r--r--  1 root root       807 May 18  2012 resolv.conf.0QwUrc
-rw-r--r--  1 root root         0 Jan 31  2013 resolv.conf.1fu66V
-rw-r--r--  1 root root       807 May  6  2012 resolv.conf.2eVqir
-rw-r--r--  1 root root       807 Jan 22  2013 resolv.conf.2SBgUK
-rw-------  1 root root         0 Aug  1  2013 resolv.conf.3FXkqm
-rw-------  1 root root         0 Feb  7  2013 resolv.conf.4j7JUA
-rw-r--r--  1 root root       807 Dec 20  2012 resolv.conf.5AFNu5
-rw-r--r--  1 root root       849 Jun 18  2012 resolv.conf.5PJszp
-rw-r--r--  1 root root       807 Jan 14  2013 resolv.conf.6RcCWb
-rw-r--r--  1 root root         0 Jun 10  2013 resolv.conf.8cKkji
It goes on for a while, the current file is:
:~> cat /etc/resolv.conf
# IPv4 name servers OpenDNS:
nameserver 208.67.222.222
nameserver 208.67.220.220

# IPv6 name servers OpenDNS:
nameserver 2620:0:ccc::2
nameserver 2620:0:ccd::2

re: "a few" - Do any of them have recent or current timestamps? They shouldn't.

If you can reproduce this:

		# lsattr /etc/resolv.conf
		----i--------e-- /etc/resolv.conf

(It's the "i" that matters -> it shouldn't be there.)

then you need to do this:
		# chattr -i /etc/resolv.conf

to produce ~this:
		# lsattr /etc/resolv.conf
		-------------e-- /etc/resolv.conf

All those 2012 and 2013 files can be deleted. Config files in such form as those are created as part of an incomplete upgrade process, one that prohibited writing to the original file.

Thanks, Felix, none have recent timestamp and they are deleted now, and the chattr -i command did the trick. Afterwards the upgrade went without a hitch!

(In reply to Felix Miata from comment #15)
> If you can reproduce this:
> 
> 		# lsattr /etc/resolv.conf
> 		----i--------e-- /etc/resolv.conf
 

Ah, good point Felix! So the file attribute was set to "immutable"!

The question is who set this attribute? Comment #13 suggests it was not changed manually.


On my older 42.3 testing system the file has no extra attributes:

# lsattr /etc/resolv.conf 
---------------- /etc/resolv.conf

I installed all online updates and the attributes were not changed. Even switching from the Wicked backend to the Network Manager did not change the attributes.

Any idea how that was changed? Is that a common problem?

(In reply to uli fuerst from comment #14)

Something is strange - I have a whole lot of files /etc/resolv.conf, here are a few from the le -l command:
-rw-r--r--  1 root root       162 Dec 21  2016 resolv.conf
-rw-r--r--  1 root root       807 Oct 28  2012 resolv.conf.0bwWRT

I guess there is some script or service running in background updating the /etc/resolv.conf and sometimes it left a temporary file (or backup).

> It goes on for a while, the current file is:
> :~> cat /etc/resolv.conf
> # IPv4 name servers OpenDNS:
> nameserver 208.67.222.222
> nameserver 208.67.220.220

So you are using the OpenDNS server for name resolution. How did you set that up?

/etc/resolv.conf.netconfig.s122.big41.01 from openSUSE 12.2 on host big41:

### /etc/resolv.conf file autogenerated by netconfig!
#
# Before you change this file manually, consider to define the
# static DNS configuration using the following variables in the
# /etc/sysconfig/network/config file:
#     NETCONFIG_DNS_STATIC_SEARCHLIST
#     NETCONFIG_DNS_STATIC_SERVERS
#     NETCONFIG_DNS_FORWARDER
# or disable DNS configuration updates via netconfig by setting:
#     NETCONFIG_DNS_POLICY=''
#
# See also the netconfig(8) manual page and other documentation.
#
# Note: Manual change of this file disables netconfig too, but
# may get lost when this file contains comments or empty lines
# only, the netconfig settings are same with settings in this
# file and in case of a "netconfig update -f" call.
#
### Please remove (at least) this line when you modify the file!
nameserver 8.8.8.8

It is probably similar to most of those extra resolv.conf.* files in comment 14, while the zero byte balance of those others suggest name resolution went through a period of trouble in 12.2, which was solved six years ago, and no longer remembered, by locking down a working resolv.conf with the immutable attribute. Online upgrades since then could have been successful, and only now offline blocked.

Just to clarify what I have done:
1) at some stage I set the network configuration from wicked to network manager, simply because I want to see a confirmation that the network is up in the system tray. Wicked does not show any icons there.
2) Some problems (slowness) with the dns servers from my ISP caused me to change to opendns. I changed it in YAST to manually and entered the dns servers for IPv4 and IPv6 manually in /etc/resolv.conf. (Yast hadn't enough fields for IVv4 and IPv6)
3) When visiting my daughter I could not get onto the internet as their ISP only accepts their own dns servers and nothing else. (I had an IP address but the nslookup command timed out as there was no contact to a dns server). So I either had to change back Yast to autoconfig (or however this is called) or I had to manually enter their ISP's dns servers. This switching backwards and forwards happened at least twice a year.

I don't know what set the attribute to immutable but the above goes back at least 5 years (may be back to version 12.2 as Felix suggests?). During this time I have only upgraded on this computer.

Oh, upgrading since 12.2... That is quite rare scenario I guess so I do not expect many affected users with this issue.

On the other hand I googled a bit and found out that the immutable trick was quite often suggested as a solution to avoid overwriting the file.

I'll add handling the Errno::EPERM exception into the code...

Ladislav, taking in account #21 I will assign it directly to you. Feel free to reassign it to yast2-maintainers in case you prefer to create a Trello Card adding it to our Incoming board in order to prioritize it.

Just for the record WIP PR: https://github.com/yast/yast-update/pull/103

fix merged.