Bugzilla – Bug 163791
Build905 - Can't install packages via YaST2 sw_single
Last modified: 2006-04-18 07:38:49 UTC
Can't install packages via YaST2 sw_single, it got a popup about not matching media, added as attachment. Also added y2log. Stano, said Marius might have changed the media handling?
Created attachment 76698 [details] Screenshot of the error popup
Created attachment 76703 [details] y2log Also via: http://w3.suse.de/~hmuelle/SL101-Build905-logs/
It has nothing to do with "%2f", because in this particular case the Url is valid in both cases (without %2f means relative to ftp default dir [e.g. user's home] and it is "/" in the server). The reason seems to be a different one: The "file:/" url in MediaDIR, that was rejected. Klaus fixed it in rev 2962 (submitted to STABLE).
As I can see in Attachment #76703 [details], there seems to be a further problem with the media verifier, that reports invalid media: 2006-04-05 17:15:32 [source] SourceImpl.cc(provideFile):196 Going to try provide file /suse/i586/perl-Net_SSLeay-1.30-8.i586.rpm from 1 [media] MediaManager.cc(attach):532 attach(id=1) [...] [media] MediaCurl.cc(doGetFileCopy):584 /media.1/media [media] MediaCurl.cc(doGetFileCopy):617 URL: ftp://10.10.0.5/CDs/SUSE-Linux-10.1-Build_905-i386/CD1/media.1/media [media] MediaCurl.cc(doGetFileCopy):674 dest: /var/adm/mount/AP_0x00000001/media.1/media [media] MediaCurl.cc(doGetFileCopy):675 temp: /var/adm/mount/AP_0x00000001/media.1/media.new.zypp.lfFWsf 2006-04-05 17:15:33 [zypp] PathInfo.cc(_Log_Result):291 rename /var/adm/mount/AP_0x00000001/media.1/media.new.zypp.lfFWsf -> /var/adm/mount/AP_0x00000001/media.1/media [media] MediaHandler.cc(provideFile):912 provideFile(/media.1/media) [media] MediaManager.cc(checkDesired):103 checkDesired(1): not desired [base] Exception.cc(log):94 MediaManager.cc(checkDesired):106 THROW: Unfortunatelly the change of the verifier are not logged (I'll add some logging). Stano, do you have an idea?
Harald, we need a retest with a newer build.
I am missing an installation source in the installed system. But I am able to select a package but afterwards ask for media 0. I will add a screenshot, but it is german. I heard it could be related to an issue syncing an FTP installation source between zmd/yast - but I haven't found a bug for it. y2log and screenshot follows.
Created attachment 77866 [details] screenshot of error popup
Created attachment 77867 [details] y2log
Really nice logs - seems url rewriting is broken, ...: 2006-04-11 16:55:57 <1> aks(26785) [YCP] PackageCallbacks.ycp:699 SourceChange (1, 0) 2006-04-11 16:55:57 <1> aks(26785) [YCP] SlideShow.ycp:1667 SetCurrentCdNo() - src: 1 , CD: 0 2006-04-11 16:55:57 <3> aks(26785) [YCP] SlideShow.ycp:644 SlideShow::SanityCheck(): Illegal values for current_src (1) or current_cd (0) 2006-04-11 16:55:57 <1> aks(26785) [YCP] SlideShow.ycp:646 total sizes: [[0]] 2006-04-11 16:55:57 <3> aks(26785) [YCP] SlideShow.ycp:644 SlideShow::SanityCheck(): Illegal values for current_src (1) or current_cd (0) 2006-04-11 16:55:57 <1> aks(26785) [YCP] SlideShow.ycp:646 total sizes: [[0]] 2006-04-11 16:55:57 <3> aks(26785) [YCP] SlideShow.ycp:644 SlideShow::SanityCheck(): Illegal values for current_src (1) or current_cd (0) 2006-04-11 16:55:57 <1> aks(26785) [YCP] SlideShow.ycp:646 total sizes: [[0]] 2006-04-11 16:55:57 <0> aks(26785) [source] MediaSet.cc(rewriteUrl):159 Rewriting url http://ftp.leo.org/ 2006-04-11 16:55:57 <1> aks(26785) [media] MediaAccess.cc(open):109 Trying scheme 'http' 2006-04-11 16:55:57 <3> aks(26785) [media] MediaHandler.cc(MediaHandler):71 Provided attach point is not a absolute directory: /pub/comp/os/unix/linux/suse/suse/ 2006-04-11 16:55:57 <1> aks(26785) [media] MediaCurl.cc(MediaCurl):117 MediaCurl::MediaCurl(http://ftp.leo.org/, /pub/comp/os/unix/linux/suse/suse/update/10.1) 2006-04-11 16:55:57 <1> aks(26785) [media] MediaAccess.cc(open):142 Opened: http(http://ftp.leo.org/ not attached; localRoot "") 2006-04-11 16:55:57 <0> aks(26785) [media] MediaManager.cc(open):412 Opened new media access using id 2 to http://ftp.leo.org/ 2006-04-11 16:55:57 <1> aks(26785) [source] MediaSet.cc(getMediaAccessId):135 Adding media verifier 2006-04-11 16:55:57 <0> aks(26785) [media] MediaManager.cc(delVerifier):536 MediaVerifier change: id=2, verifier=zypp::media::NoVerifier 2006-04-11 16:55:57 <0> aks(26785) [media] MediaManager.cc(addVerifier):520 MediaVerifier change: id=2, verifier=zypp::media::NoVerifier 2006-04-11 16:55:57 <0> aks(26785) [source] SourceImpl.cc(provideFile):235 Going to try provide file ./rpm/i586/libxml-1.8.17-382.i586.rpm from 0 2006-04-11 16:55:57 <0> aks(26785) [media] MediaManager.cc(attach):557 attach(id=2) 2006-04-11 16:55:57 <0> aks(26785) [media] MediaHandler.cc(createAttachPoint):335 Trying to create attach point in /var/adm/mount 2006-04-11 16:55:57 <0> aks(26785) [zypp] PathInfo.cc(_Log_Result):291 mkdir /var/adm/mount/AP_0x00000001 00755 2006-04-11 16:55:57 <1> aks(26785) [media] MediaHandler.cc(createAttachPoint):312 Created default attach point /var/adm/mount/AP_0x00000001 Note also the broken Url: 2006-04-11 14:54:03 <1> linux(4476) [YCP] Packages.ycp:501 Initialize Package Manager: ftp://10.10.0.5/%2f%252fCDs/SUSE-Linux-10.1-Build_911-i386/CD1
> Note also the broken Url: > 2006-04-11 14:54:03 <1> linux(4476) [YCP] Packages.ycp:501 Initialize Package > Manager: ftp://10.10.0.5/%2f%252fCDs/SUSE-Linux-10.1-Build_911-i386/CD1 This one sounds like bug #163784 ;-)
BTW: Fixed reassign. Yes, you may be right. YaST seems to prepend a / also if it is not needed. Further I would guess, it does not decode the path it takes from url and puts into the path input box, and encodes it, when it is put into the new url. Jiri, the "/" after the authority (the host[:port]) is not just a separator, but allways _belongs_ to the path. But this is only one of the problems in the above logs - invalid media id 0 and the url rewriting in source/MediaSet.cc seems to be broken now (the url path used as attach point).
The media id is fixed now - bug #164879 Jiri, please, take a look at the superfluous /
*** Bug 163784 has been marked as a duplicate of this bug. ***
Marius, it is not clear tom me how should we handle the user input: 1. user enters server name (armstrong.suse.de) and path (download) - yast currently concatenates this to armstrong.suse.de/download 2. user enters server name and absolute path (/download): - yast currently concatenates it the same way (adding / automatically) to armstrong.suse.de//download - this is passed to zypp and media handler uses %2f there. If I add a check for already existing "/" at the beginning of the path and add a slash only when it is missing, it would result in the same url with armstrong.suse.de/download in both cases - which is probably something we don't want, ok? So, how should YaST differentiate these cases? Should behave differently for different protocols?
Comment on attachment 77866 [details] screenshot of error popup grr
bug 163784 comment 15 says that libzypp r3062 does not escape the leading / anymore, except for FTP URLs. That is fine since the resulting double slash should not hurt.
(In reply to comment #17) libzypp _never_ encoded the leading slash. (In reply to comment #15) > Marius, it is not clear tom me how should we handle the user input: I can't say you how to implement / handle it. You have to decide it and then make sure, it works. That's all. > 1. user enters server name (armstrong.suse.de) and path (download) > > - yast currently concatenates this to armstrong.suse.de/download This is OK, since "/" at the begin of the path is required. Another alternative would be to reject the path and to force the user to use either "/download" or "//download" to specifiy the special case of the absolute ftp path. See this url: 2006-04-11 14:54:03 <1> linux(4476) [YCP] Packages.ycp:501 Initialize Package Manager: ftp://10.10.0.5/%2f%252fCDs/SUSE-Linux-10.1-Build_911-i386/CD1 Do you have an idea how (and where) this happens? It seems, that the Url was splitted (without decoding) and the path was "//%2fCDs/..." originally. Then it was put back into an url, that encoded the path again to "/%2f%252fCDs/" and prepended a "/". The same thing would happen, if you do something like: zypp::Url url("ftp://10.10.0.5//%2fCDs"); string path = url.getPathName(E_ENCODED); url.setPathName(path); // E_DECODED
OK, I'm leaving the concatenation as it is (see comment #15) for ftp sources. For non-ftp, "/" is not used between server and directory part if the directory already begins with it.
*** Bug 163829 has been marked as a duplicate of this bug. ***
Does not work for FTP sources in RC1. See #166248
So let's solve it there.
*** This bug has been marked as a duplicate of 166248 ***