Bug 779397

Maciej,

Sorry I still unclear about your issue. You can add the iso as a repo, then upgrade the system.

Is it related to network? Thanks!

> Is it related to network? 

No, because the files are located on hard disk drive which runs inside a computer.

Yes -- bug -- because installer/upgrader from DVD needs internet connection to access local hard disk drive repository and treats such local hard disk drive repo as remote (network-based) one.

Maciej,

 Thanks for your quick reply.

It's not in my area, reassign it.

@Maciej: 
Please attach the yast logfiles (see http://en.opensuse.org/openSUSE:Bugreport_YaST). Without these logs we can't tell where the suspicious _NETWORK_ message actually came from. From your description I would rather expect some 'is not a directory' message from the /mnt/INSTALLCD repo. 


Related to your /INSTALLCD problem: I suppose you added the repos as local directory 'dir:/mnt/INSTALLCD'. A better choice may have been using a disk volume (subdir on a partition):

  hd:/INSTALLCD?device=/dev/...

This will always prefix the path with the devices current mount point.

Created attachment 512506 [details]
y2logs

> Without these logs we can't tell where the suspicious _NETWORK_ message actually came from.

It is enough to add local repo, and then update the system to newer version.

> I suppose you added the repos as local directory 'dir:/mnt/INSTALLCD'

Nope. You can do it yourself. Add local repo, browse and point to desired directory. The rest is handled by Yast. 

So it is not better or worse choice of path, I simply rely totally on Yast. Nothing else -- what Yast does internally, and how it converts path is beyond my choice or actions (I guess it converts all "/something/foobar" into "dir:///something/foobar").

I'm uncertain about this _NETWORK_ message, but it seems to be a YaST issue anyway. Most probably:

[y2log-2.gz]
2012-09-07 17:33:24 <1> linux(2809) [YCP] clients/inst_upgrade_urls.ycp:761
 Probed repository: dir:///INSTALLCD type: NONE
2012-09-07 17:33:24 <3> linux(2809) [YCP] Report.ycp:523  
 Cannot add repository Install CD URL: dir:///INSTALLCD

Maybe Report.ycp simply assumes it's network?


---(I guess in yast-installation/src/clients/inst_upgrade_urls.ycp)
In instsys YaST had to temporarily fix dir:/ URLs taken from the system, or reject them.

  dir:/INSTALLCD
  iso:/?iso=CD1.iso&url=dir:/INSTALLISOS

And obviously fixed URLs must never be synched back to the system.

Reassigned to maintainer of yast2-installation

$["autorefresh":0, "baseurl":"dir:///INSTALLCD", "enabled":1, "id":"Install_CD", "keeppackages":0, "name":"Install CD", "path":"/", "type":"yast2"]

was read from system (/mnt/etc/zypp/repos.d//Install_CD.repo). You mean that the format of Install_CD.repo was wrong and needs to be transfered?

(BTW, there really does not look anything like 'local repo is recognized as a remote (network) one'. I do not see any errors about repo being network one, just that URL: dir:///INSTALLCD cannot be added.)

Yes, if this repo should be _used_ within the instsys and the original system is mounted at /mnt, it needs to use /mnt/INSTALLCD. If the repo stays disabled, it's no problem.

Ah, you mean that /mnt prefix, of course...

I'm not sure if we actually support adding local repository during the installation.

Maciej, do you really need that local repo _during_ installation? Isn't it enought to have it disabled and re-enable it manually after upgrade?

Jiri, here and now, I don't need data from it, but I need no error message. As for now, if I leave it enabled, I will get error. So at very least this should be fixed.

Disabling and enabling it is a workaround, ugly -- it is yet another hoop to jump through for user. And there are too many of them right now for quality product.

I hope I answered your question.

(In reply to comment #14)
> Jiri, here and now, I don't need data from it, but I need no error message. As
> for now, if I leave it enabled, I will get error. So at very least this should
> be fixed.

What do you mean, 'leave it enabled'? 

AFAIK old repositories are deleted by default during the upgrade so in order to have it enabled, you already have to access the table with repositories and change the status. You can change the status to disabled as well.

Oh well, with the upgrade there is so many problems, that is hard to even start. It would be really good to outline a design, how things should work, and then decide if something is a bug, or not. Because looking in every particular report alone could cause the notion that this, this, this, and so on, reports are invalid.

Anyway, back to this one:

* the fact repos are deleted is VERY bad -- reported AFAIR, think of TW, why this repo should be deleted, it is always relevant by its definition

* only enabled, non-accessible repos are deleted

* when I have entire DVD copied to INSTALLCD prior to upgrade, I would like to use it

* I am not that sure, that by default repos are disabled, I think they are enabled actually, or, first I am asked about repos (disable/enable), and then the network is checked, and then they are deleted (if enabled). 

Anyway, there are 3 modes -- enabled, delete, disabled. Delete means "delete". Thus enabled should not mean -- delete. In other words, enabled non-accessible repo should cause an error, but not deletion.

Look, you are contradicting yourself:

(In reply to comment #14)
> Jiri, here and now, I don't need data from it, but I need no error message.


(In reply to comment #16)

> * when I have entire DVD copied to INSTALLCD prior to upgrade, I would like to
> use it


But I assume your intention really is to use local repo for upgrade. There's no network related problem in this part, actually.

Patch like this (or similar, not tested yet) would prepend /mnt to local sources. However, I have to save such source with correct path at the end (comment 7).

Lukas, do you remember when are the repositories actually saved?


--- a/src/clients/inst_upgrade_urls.ycp
+++ b/src/clients/inst_upgrade_urls.ycp
@@ -759,6 +759,15 @@ If you skip it, the repository will not be added.
 
                string repo_type = Pkg::RepositoryProbe (one_url, "/");
                y2milestone ("Probed repository: %1 type: %2", one_url, repo_type);
+
+               if ((repo_type == nil || repo_type == "NONE") &&
+                    substring (one_url, 0, 4) == "dir:")
+                {
+                    one_url   = "dir:/mnt" + substring (one_url, 4);
+                    repo_type = Pkg::RepositoryProbe (one_url, "/");
+                    y2milestone ("Probed possible local repository again: %1 type: %2", one_url, repo_type);
+                    // FIXME remove /mnt before saving!!!
+                }

There are several places in installation where sources are saved

cd /usr/share/YaST2/clients
grep Pkg::SourceSaveAll * | grep "_finish\|inst_"
inst_congratulate.ycp:          Pkg::SourceSaveAll ();
inst_congratulate.ycp:    Pkg::SourceSaveAll();
inst_extrasources.ycp:  Pkg::SourceSaveAll();
inst_productsources.ycp:            Pkg::SourceSaveAll();
inst_upgrade_urls.ycp:  if (ret == `next) Pkg::SourceSaveAll();
pkg_finish.ycp:    Pkg::SourceSaveAll ();
umount_finish.ycp:    Pkg::SourceSaveAll();

All are after the user has accepted the installation/upgrade proposal
and let YaST/libzypp do it's work.

So, if you change inst_upgrade_urls modify all dir:/-based repositories
to use /mnt, you will have to also add another code that would change it
back at the end of the installation. For instance doing that in pkg_finish
might be a good idea.

(In reply to comment #20)
> There are several places in installation where sources are saved
> 
> cd /usr/share/YaST2/clients
> grep Pkg::SourceSaveAll * | grep "_finish\|inst_"
> inst_congratulate.ycp:          Pkg::SourceSaveAll ();
> inst_congratulate.ycp:    Pkg::SourceSaveAll();
> inst_extrasources.ycp:  Pkg::SourceSaveAll();
> inst_productsources.ycp:            Pkg::SourceSaveAll();
> inst_upgrade_urls.ycp:  if (ret == `next) Pkg::SourceSaveAll();
> pkg_finish.ycp:    Pkg::SourceSaveAll ();
> umount_finish.ycp:    Pkg::SourceSaveAll();
> 

2nd stage is too late
pkg_finish calls inst_extrasources in case of update (before saving sources), so extrasources client seems to be the one

(In reply to comment #21)

> pkg_finish calls inst_extrasources in case of update (before saving sources),
> so extrasources client seems to be the one

No, umount_finish is even earlier.

OK, fix is on the way. Try with next (pre-)release.

This is an autogenerated message for OBS integration:
This bug (779397) was mentioned in
https://build.opensuse.org/request/show/144367 Factory / yast2-installation