[opensuse-support] upgrade problem
This is sort of following on the scanner problem, since the scanner problem (not working any more, and not found by Yast) is more-or-less coincident with an upgrade. Tried this evening to run the latest upgrade, but after a whole batch of stuff was downloaded, it asked for a downloaded install disk version which I don't have. ( I have one from two days later, but that seems to be unacceptable. Specifically, I have the disk from which I installed TW, version, 2020-0826. The dialog from the attempted u[grade follows: Please insert medium [openSUSE-20200824-0] #1 and type 'y' to continue or 'n' to cancel the operation. [yes/no] (no): y Retrieving package libgimp-2_0-0-2.10.20-3.1.x86_64 (185/190), 286.1 KiB (777.3 KiB unpacked) File './x86_64/libgimp-2_0-0-2.10.20-3.1.x86_64.rpm' not found on medium 'cd:/?devices=/dev/disk/by-id/usb-HL-DT-ST_DVDRAM_GP08LU11_P01090612025848-0:0' Please insert medium [openSUSE-20200824-0] #1 and type 'y' to continue or 'n' to cancel the operation. [yes/no] (no): y Failed to mount cd:/?devices=/dev/disk/by-id/usb-HL-DT-ST_DVDRAM_GP08LU11_P01090612025848-0:0 on /var/tmp/AP_0xOAI2zu: Mounting media failed (mount: /var/tmp/AP_0xOAI2zu: no medium found on /dev/sr0.) Please insert medium [openSUSE-20200824-0] #1 and type 'y' to continue or 'n' to cancel the operation. [yes/no] (no): n Problem occurred during or after installation or removal of packages: Installation has been aborted as directed. Please see the above error message for a hint. Question: can I find (where?) a version of libgimp-2_0-0-2.10.20-3.1.x86_64_rpm and put it somewhere--perhaps on a flash-drive--and make the thing happy? Or am I just out of luck? Tried rpm-find but this file not found. Still learning--doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/10/2020 06.43, Doug McGarrett wrote:
This is sort of following on the scanner problem, since the scanner problem (not working any more, and not found by Yast) is more-or-less coincident with an upgrade.
Tried this evening to run the latest upgrade, but after a whole batch of stuff was downloaded, it asked for a downloaded install disk version which I don't have. ( I have one from two days later, but that seems to be unacceptable. Specifically, I have the disk from which I installed TW, version, 2020-0826. The dialog from the attempted u[grade follows:
Ignore all that followed on your post. Instead start yast. Select the "software repositories modules". Find the repository that points to the DVD/USB stick (perhaps named "openSUSE-20200824-0") and remove it. Then you can try the update again. Remember, using "zypper dup" on Tumbleweed. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 10/10/20 6:23 AM, Carlos E. R. wrote:
On 10/10/2020 06.43, Doug McGarrett wrote:
This is sort of following on the scanner problem, since the scanner problem (not working any more, and not found by Yast) is more-or-less coincident with an upgrade.
Tried this evening to run the latest upgrade, but after a whole batch of stuff was downloaded, it asked for a downloaded install disk version which I don't have. ( I have one from two days later, but that seems to be unacceptable. Specifically, I have the disk from which I installed TW, version, 2020-0826. The dialog from the attempted u[grade follows:
Ignore all that followed on your post.
Instead start yast.
Select the "software repositories modules".
Find the repository that points to the DVD/USB stick (perhaps named "openSUSE-20200824-0") and remove it.
Then you can try the update again. Remember, using "zypper dup" on Tumbleweed.
I removed it. This is the result, and it scares me: (And I don't know of any way of putting this deleted entry back!) What now? --doug (Sorry about the top-post, but it seemed most appropriate here.) doug@linux1:~> su - Password: linux1:~ # zypper dup Loading repository data... Reading installed packages... Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Computing distribution upgrade... Problem: lsb-4.0.fake-1.5.x86_64 requires /sbin/pidof, but this requirement cannot be provided deleted providers: sysvinit-tools-2.96-1.3.x86_64 not installable providers: busybox-sysvinit-tools-1.32.0-11.1.noarch[https-download.opensuse.org-2dfdf701] busybox-sysvinit-tools-1.32.0-11.1.noarch[https-download.opensuse.org-31b27617] busybox-sysvinit-tools-1.32.0-11.1.noarch[repo-oss] Solution 1: Following actions will be done: deinstallation of sysvinit-tools-2.96-1.3.x86_64 deinstallation of xorg-x11-essentials-7.6_1-16.10.noarch Solution 2: deinstallation of lsb-4.0.fake-1.5.x86_64 Solution 3: keep obsolete sysvinit-tools-2.96-1.3.x86_64 Solution 4: break lsb-4.0.fake-1.5.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/4/c/d/?] (c): ^Clinux1:~ # -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/10/2020 18.46, Doug McGarrett wrote:
On 10/10/20 6:23 AM, Carlos E. R. wrote:
On 10/10/2020 06.43, Doug McGarrett wrote:
This is sort of following on the scanner problem, since the scanner problem (not working any more, and not found by Yast) is more-or-less coincident with an upgrade.
Tried this evening to run the latest upgrade, but after a whole batch of stuff was downloaded, it asked for a downloaded install disk version which I don't have. ( I have one from two days later, but that seems to be unacceptable. Specifically, I have the disk from which I installed TW, version, 2020-0826. The dialog from the attempted u[grade follows:
Ignore all that followed on your post.
Instead start yast.
Select the "software repositories modules".
Find the repository that points to the DVD/USB stick (perhaps named "openSUSE-20200824-0") and remove it.
Then you can try the update again. Remember, using "zypper dup" on Tumbleweed.
I removed it. This is the result, and it scares me: (And I don't know of any way of putting this deleted entry back!)
Do not put that entry back.
What now?
doug@linux1:~> su - Password: linux1:~ # zypper dup Loading repository data... Reading installed packages... Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Computing distribution upgrade...
Problem: lsb-4.0.fake-1.5.x86_64 requires /sbin/pidof, but this requirement cannot be provided deleted providers: sysvinit-tools-2.96-1.3.x86_64 not installable providers: busybox-sysvinit-tools-1.32.0-11.1.noarch[https-download.opensuse.org-2dfdf701]
busybox-sysvinit-tools-1.32.0-11.1.noarch[https-download.opensuse.org-31b27617]
busybox-sysvinit-tools-1.32.0-11.1.noarch[repo-oss] Solution 1: Following actions will be done: deinstallation of sysvinit-tools-2.96-1.3.x86_64 deinstallation of xorg-x11-essentials-7.6_1-16.10.noarch Solution 2: deinstallation of lsb-4.0.fake-1.5.x86_64 Solution 3: keep obsolete sysvinit-tools-2.96-1.3.x86_64 Solution 4: break lsb-4.0.fake-1.5.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/4/c/d/?] (c): ^Clinux1:~ #
You need an answer from somebody that uses TW and can verify what versions they have of those packages. I don't use TW. So, wait for an answer. Do not go ahead on your own, some of the alternatives are dangerous. Meanwhile, please post the result of these commands - it is a web link: zypper lr --details > somefile.txt susepaste -n "Doug" -t "repo list" -e 40320 somefile.txt Also: rpm -q sysvinit-tools If the result of the last one is empty, do not reboot. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 10/10/20 1:45 PM, Carlos E. R. wrote:
On 10/10/2020 18.46, Doug McGarrett wrote:
On 10/10/20 6:23 AM, Carlos E. R. wrote:
On 10/10/2020 06.43, Doug McGarrett wrote:
This is sort of following on the scanner problem, since the scanner problem (not working any more, and not found by Yast) is more-or-less coincident with an upgrade.
Tried this evening to run the latest upgrade, but after a whole batch of stuff was downloaded, it asked for a downloaded install disk version which I don't have. ( I have one from two days later, but that seems to be unacceptable. Specifically, I have the disk from which I installed TW, version, 2020-0826. The dialog from the attempted u[grade follows:
Ignore all that followed on your post.
Instead start yast.
Select the "software repositories modules".
Find the repository that points to the DVD/USB stick (perhaps named "openSUSE-20200824-0") and remove it.
Then you can try the update again. Remember, using "zypper dup" on Tumbleweed.
I removed it. This is the result, and it scares me: (And I don't know of any way of putting this deleted entry back!)
Do not put that entry back.
What now?
doug@linux1:~> su - Password: linux1:~ # zypper dup Loading repository data... Reading installed packages... Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Computing distribution upgrade...
Problem: lsb-4.0.fake-1.5.x86_64 requires /sbin/pidof, but this requirement cannot be provided deleted providers: sysvinit-tools-2.96-1.3.x86_64 not installable providers: busybox-sysvinit-tools-1.32.0-11.1.noarch[https-download.opensuse.org-2dfdf701]
busybox-sysvinit-tools-1.32.0-11.1.noarch[https-download.opensuse.org-31b27617]
busybox-sysvinit-tools-1.32.0-11.1.noarch[repo-oss] Solution 1: Following actions will be done: deinstallation of sysvinit-tools-2.96-1.3.x86_64 deinstallation of xorg-x11-essentials-7.6_1-16.10.noarch Solution 2: deinstallation of lsb-4.0.fake-1.5.x86_64 Solution 3: keep obsolete sysvinit-tools-2.96-1.3.x86_64 Solution 4: break lsb-4.0.fake-1.5.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/4/c/d/?] (c): ^Clinux1:~ #
You need an answer from somebody that uses TW and can verify what versions they have of those packages. I don't use TW.
So, wait for an answer. Do not go ahead on your own, some of the alternatives are dangerous.
Meanwhile, please post the result of these commands - it is a web link:
zypper lr --details > somefile.txt susepaste -n "Doug" -t "repo list" -e 40320 somefile.txt
Also:
rpm -q sysvinit-tools
If the result of the last one is empty, do not reboot.
doug@linux1:~> su Password: linux1:/home/doug # zypper lr --details > somefile.txt linux1:/home/doug # susepaste -n "Doug" -t "repo list" -e 40320 somefile.txt Pasted as: https://susepaste.org/14396174 https://paste.opensuse.org/14396174 Link is also in your clipboard. linux1:/home/doug # rpm -q sysvinit-tools sysvinit-tools-2.96-1.3.x86_64 Thanx for your assistance--doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/10/2020 22.43, Doug McGarrett wrote:
On 10/10/20 1:45 PM, Carlos E. R. wrote:
On 10/10/2020 18.46, Doug McGarrett wrote:
They are talking about lsb-4.0-fake on IRC, by the way.
You need an answer from somebody that uses TW and can verify what versions they have of those packages. I don't use TW.
So, wait for an answer. Do not go ahead on your own, some of the alternatives are dangerous.
Meanwhile, please post the result of these commands - it is a web link:
zypper lr --details > somefile.txt susepaste -n "Doug" -t "repo list" -e 40320 somefile.txt
Ok. I do not know what is the effect of your repositories 3 and 4. # 3 worries me: openSUSE:Factory -> https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/ #4 may be a repeat of #9 openSUSE:Tumbleweed --> https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ Numbers 5 and 6 are duplicated, you should delete one. IMHO, you should delete both. KDE:Extra --> https://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/
Also:
rpm -q sysvinit-tools
If the result of the last one is empty, do not reboot.
doug@linux1:~> su Password: linux1:/home/doug # zypper lr --details > somefile.txt linux1:/home/doug # susepaste -n "Doug" -t "repo list" -e 40320 somefile.txt Pasted as: https://susepaste.org/14396174 https://paste.opensuse.org/14396174 Link is also in your clipboard. linux1:/home/doug # rpm -q sysvinit-tools sysvinit-tools-2.96-1.3.x86_64
Ok. Good. Then you can power off or reboot. But do not update till somebody that knows about TW tells what to do, but I suspect you are not the only one with this problem. However, your list of repositories worries me. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 10/10/20 5:14 PM, Carlos E. R. wrote:
On 10/10/2020 22.43, Doug McGarrett wrote:
On 10/10/20 1:45 PM, Carlos E. R. wrote:
On 10/10/2020 18.46, Doug McGarrett wrote:
They are talking about lsb-4.0-fake on IRC, by the way.
You need an answer from somebody that uses TW and can verify what versions they have of those packages. I don't use TW.
So, wait for an answer. Do not go ahead on your own, some of the alternatives are dangerous.
Meanwhile, please post the result of these commands - it is a web link:
zypper lr --details > somefile.txt susepaste -n "Doug" -t "repo list" -e 40320 somefile.txt
Ok.
I do not know what is the effect of your repositories 3 and 4. # 3 worries me:
openSUSE:Factory -> https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/
#4 may be a repeat of #9
openSUSE:Tumbleweed --> https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/
Numbers 5 and 6 are duplicated, you should delete one. IMHO, you should delete both.
KDE:Extra --> https://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/
Also:
rpm -q sysvinit-tools
If the result of the last one is empty, do not reboot.
doug@linux1:~> su Password: linux1:/home/doug # zypper lr --details > somefile.txt linux1:/home/doug # susepaste -n "Doug" -t "repo list" -e 40320 somefile.txt Pasted as: https://susepaste.org/14396174 https://paste.opensuse.org/14396174 Link is also in your clipboard. linux1:/home/doug # rpm -q sysvinit-tools sysvinit-tools-2.96-1.3.x86_64
Ok. Good. Then you can power off or reboot. But do not update till somebody that knows about TW tells what to do, but I suspect you are not the only one with this problem.
However, your list of repositories worries me.
I will wait until someone who can tell me authoritatively what to do next. I had that list of repositories open. Tried to delete #6. It's still there, but I get a warning /bin/bash crashed! Closed that window. Stopping all playing around until I hear what to do next. I appreciate the kind answers. Does this sort of thing happen often, or am I just under a dark cloud? --doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
However, your list of repositories worries me.
I will wait until someone who can tell me authoritatively what to do next. I had that list of repositories open. Tried to delete #6. It's still there, but I get a warning /bin/bash crashed! Closed that window. Stopping all playing around until I hear what to do next. I appreciate the kind answers. Does this sort of thing happen often, or am I just under a dark cloud? --doug
again, (as carlos told) start: su yast2 (yast 2 is the graphical yast) select "software repositories" delete 3 | https-download.opensuse.org-2dfdf701 | openSUSE:Factory | Yes | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/ (never as unexpieriend user as i think you are use something from factory) delte also one of the kde extra repos. (better both, if you do not know why they are here) same is for the education repo. if you do not want to delete completely, you could deactivate it, there are 2 checkboxes below "properties": "enabled" "automatic refresh" uncheck at least "enabled". you do not loose the entrys but they do not harm your system any more. after disabled or removed, try again a zypper dup AS I WROTE BEFORE in some other mails, you have after update to do a rpmconfigcheck !!!!! if you do not like this DO NOT USE tumbleweed !!!!!!!!! you will run into problems if you are not able to handle the rpmconfigcheck results. =============================================== here additional info: in the yast2 module "softwaremanagement" if you do "view" , "repositories" you could see what package is available from the selected repos and if you at lower side of screen klick on "versions" you see what versions of the highlighted software- package are installed at your system and from where. if possible you should switch packages you have installed from factory and kde extra back to opensuse-tumbleweed / opensuse-oss / opensuse-non-oss if you have at "view" " repositories" there is a blue text "switch system packages" over the list of packages. here you have a easy posibility to switch back a lot of packages with one klick to a specific repo. as i told you in some other mails, as more repos you enable, as more update problems you will get in tumbleweed. this is not a standart list you show here, i think you have used some of the "one klick install" things. better not do that, it will add repos which will later make trouble. better add in yast a specific repo you think you need, then install from this repo the software you need, after this disable the repo. if you MUST install something from a other repo and you are only able to do so by the "one cklick", maybe for you easyest way is BEFORE you do that, check your repo list. then install it. and after install disable all new repos. make updates, after updates, enable the special repo (you have needed for only a single programm) and check if there is a update for that programm there. ALL INSIDE YAST2 !!! then disable the repo again. this is not a good solution, but it will save you from installing / updateing something from an unwanted repo. again, much better is NOT to install such repos with the "one klick install" at all. and as i told you before, maybe only packman repo is needed in addition to the standard for a flawless running tumbleweed system. and the info: if your native language is not english, you could start yast2 like this: LANGUAGE=en_us yast2 to have it in english, so you will find the words i wrote here: "versions" "view" "repositories" ...... simoN -- www.becherer.de -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 11/10/2020 01.17, Doug McGarrett wrote:
On 10/10/20 5:14 PM, Carlos E. R. wrote:
On 10/10/2020 22.43, Doug McGarrett wrote:
However, your list of repositories worries me.
I will wait until someone who can tell me authoritatively what to do next. I had that list of repositories open. Tried to delete #6. It's still there, but I get a warning /bin/bash crashed! Closed that window.
I can not imagine what happened there.
Stopping all playing around until I hear what to do next. I appreciate the kind answers. Does this sort of thing happen often, or am I just under a dark cloud?
You should have this List of repos - notice the "*NO*" I wrote in the table: # | Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI | Service ---+--------------------------------------+-----------------------------+---------+-----------+---------+----------+--------+-------------------------------------------------------------------------------------+-------- 1 | SoftMaker_Office_Repository | SoftMaker Office Repository | Yes | (r ) Yes | Yes | 99 | rpm-md | http://shop.softmaker.com/repo/rpm | 2 | education-x86_64 | education-x86_64 | *NO* | (r ) Yes | No | 99 | rpm-md | https://ftp.lysator.liu.se/pub/opensuse/repositories/Education/openSUSE_Tumb... | 3 | https-download.opensuse.org-2dfdf701 | openSUSE:Factory | *NO* | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/ | 4 | https-download.opensuse.org-31b27617 | openSUSE:Tumbleweed | *NO* | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ | 5 | https-download.opensuse.org-be2dd36a | KDE:Extra | *NO* | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/ | 6 | https-download.opensuse.org-d780716b | KDE:Extra | *NO* | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/ | 7 | repo-debug | openSUSE-Tumbleweed-Debug | No | ---- | ---- | 99 | NONE | http://download.opensuse.org/debug/tumbleweed/repo/oss/ | 8 | repo-non-oss | openSUSE-Tumbleweed-Non-Oss | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/tumbleweed/repo/non-oss/ | 9 | repo-oss | openSUSE-Tumbleweed-Oss | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/tumbleweed/repo/oss/ | 10 | repo-source | openSUSE-Tumbleweed-Source | No | ---- | ---- | 99 | NONE | http://download.opensuse.org/source/tumbleweed/repo/oss/ | 11 | repo-update | openSUSE-Tumbleweed-Update | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/update/tumbleweed/ | I think you added "education-x86_64" to get artha. Artha is currently an official package, you should not need extra repos for it. Thus disable this repo. openSUSE:/Tumbleweed/standard/ is a duplicate of "oss", so disable it. openSUSE:/Factory/snapshot/ will give you trouble, so disable it. "KDE:Extra" you have twice, so at least remove one. And unless you know why you have it, remove (or disable) both. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 10/11/20 1:19 PM, Carlos E. R. wrote:
On 11/10/2020 01.17, Doug McGarrett wrote:
On 10/10/20 5:14 PM, Carlos E. R. wrote:
On 10/10/2020 22.43, Doug McGarrett wrote:
However, your list of repositories worries me.
I will wait until someone who can tell me authoritatively what to do next. I had that list of repositories open. Tried to delete #6. It's still there, but I get a warning /bin/bash crashed! Closed that window. I can not imagine what happened there.
Stopping all playing around until I hear what to do next. I appreciate the kind answers. Does this sort of thing happen often, or am I just under a dark cloud? You should have this List of repos - notice the "*NO*" I wrote in the table:
# | Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI | Service ---+--------------------------------------+-----------------------------+---------+-----------+---------+----------+--------+-------------------------------------------------------------------------------------+-------- 1 | SoftMaker_Office_Repository | SoftMaker Office Repository | Yes | (r ) Yes | Yes | 99 | rpm-md | http://shop.softmaker.com/repo/rpm | 2 | education-x86_64 | education-x86_64 | *NO* | (r ) Yes | No | 99 | rpm-md | https://ftp.lysator.liu.se/pub/opensuse/repositories/Education/openSUSE_Tumb... | 3 | https-download.opensuse.org-2dfdf701 | openSUSE:Factory | *NO* | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/ | 4 | https-download.opensuse.org-31b27617 | openSUSE:Tumbleweed | *NO* | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ | 5 | https-download.opensuse.org-be2dd36a | KDE:Extra | *NO* | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/ | 6 | https-download.opensuse.org-d780716b | KDE:Extra | *NO* | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/ | 7 | repo-debug | openSUSE-Tumbleweed-Debug | No | ---- | ---- | 99 | NONE | http://download.opensuse.org/debug/tumbleweed/repo/oss/ | 8 | repo-non-oss | openSUSE-Tumbleweed-Non-Oss | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/tumbleweed/repo/non-oss/ | 9 | repo-oss | openSUSE-Tumbleweed-Oss | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/tumbleweed/repo/oss/ | 10 | repo-source | openSUSE-Tumbleweed-Source | No | ---- | ---- | 99 | NONE | http://download.opensuse.org/source/tumbleweed/repo/oss/ | 11 | repo-update | openSUSE-Tumbleweed-Update | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/update/tumbleweed/ |
I think you added "education-x86_64" to get artha. Artha is currently an official package, you should not need extra repos for it. Thus disable this repo.
openSUSE:/Tumbleweed/standard/ is a duplicate of "oss", so disable it.
openSUSE:/Factory/snapshot/ will give you trouble, so disable it.
"KDE:Extra" you have twice, so at least remove one. And unless you know why you have it, remove (or disable) both.
I cannot seem to get that output now. I forget how I got it, and I have checked the earlier emails. I did get software repositories in Yast, but not this complete picture. I deleted (I hope) the names you wrote NO on in a previous post, but I'm not sure I have the correct ones, or all of them. I will try the upgrade again, and see what happens. Wish me luck 1 --doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 11/10/2020 22.15, Doug McGarrett wrote:
On 10/11/20 1:19 PM, Carlos E. R. wrote:
I cannot seem to get that output now. I forget how I got it, and I have checked the earlier emails. I did get software repositories in Yast, but not this complete picture. I deleted (I hope) the names you wrote NO on in a previous post, but I'm not sure I have the correct ones, or all of them. I will try the upgrade again, and see what happens. Wish me luck
Just repeat the command: zypper lr --details > somefile.txt susepaste -n "Doug" -t "repo list" -e 40320 somefile.txt -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Op zaterdag 10 oktober 2020 23:14:54 CEST schreef Carlos E. R.:
openSUSE:Factory -> https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/
#4 may be a repeat of #9
openSUSE:Tumbleweed --> https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ Factory != Tumbleweed.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 11/10/2020 01.22, Knurpht-openSUSE wrote:
Op zaterdag 10 oktober 2020 23:14:54 CEST schreef Carlos E. R.:
openSUSE:Factory -> https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/
#4 may be a repeat of #9
openSUSE:Tumbleweed --> https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ Factory != Tumbleweed.
Then it is worse, but you don't explain what it is. 3 | openSUSE:Factory | https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/ 4 | openSUSE:Tumbleweed | https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ 9 | repo-oss | openSUSE-Tumbleweed-Oss | http://download.opensuse.org/tumbleweed/repo/oss/ -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Carlos E. R.
On 11/10/2020 01.22, Knurpht-openSUSE wrote:
Op zaterdag 10 oktober 2020 23:14:54 CEST schreef Carlos E. R.:
openSUSE:Factory -> https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/
#4 may be a repeat of #9
openSUSE:Tumbleweed --> https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ Factory != Tumbleweed.
Then it is worse, but you don't explain what it is.
3 | openSUSE:Factory | https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/
4 | openSUSE:Tumbleweed | https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/
9 | repo-oss | openSUSE-Tumbleweed-Oss | http://download.opensuse.org/tumbleweed/repo/oss/
files residing in Factory have not been released to Tumbleweed, ie: Factory != Tumbleweed in other words, factory repos should not be used in Tumbleweed, especially by someone as lacking in linux savvy as the OP. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 11/10/2020 05.15, Patrick Shanahan wrote:
* Carlos E. R.
[10-10-20 21:58]: On 11/10/2020 01.22, Knurpht-openSUSE wrote:
Op zaterdag 10 oktober 2020 23:14:54 CEST schreef Carlos E. R.:
openSUSE:Factory -> https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/
#4 may be a repeat of #9
openSUSE:Tumbleweed --> https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ Factory != Tumbleweed.
Then it is worse, but you don't explain what it is.
3 | openSUSE:Factory | https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/
4 | openSUSE:Tumbleweed | https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/
9 | repo-oss | openSUSE-Tumbleweed-Oss | http://download.opensuse.org/tumbleweed/repo/oss/
files residing in Factory have not been released to Tumbleweed, ie: Factory != Tumbleweed
Ah, ok. Yes, absolutely, he should not have the Factory repo. What about Tumbleweed/standard/? I thought that was a duplicate of "oss".
in other words, factory repos should not be used in Tumbleweed, especially by someone as lacking in linux savvy as the OP.
I wonder how he got it there. My guess is he doesn't know, meaning he is using again the "direct install" button or one click. I just did an experiment. Search for a package (dolphin) https://search.opensuse.org/ --> https://search.opensuse.org/packages/ --> https://software.opensuse.org/search?q=dolphin&baseproject=openSUSE%3AFactory --> https://software.opensuse.org/package/dolphin If I click on "direct install" I get "dolphin.ymp" which contains: <url>http://download.opensuse.org/tumbleweed/repo/oss/</url> Which is correct. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Carlos E. R.
On 11/10/2020 05.15, Patrick Shanahan wrote:
* Carlos E. R.
[10-10-20 21:58]: On 11/10/2020 01.22, Knurpht-openSUSE wrote:
Op zaterdag 10 oktober 2020 23:14:54 CEST schreef Carlos E. R.:
openSUSE:Factory -> https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/
#4 may be a repeat of #9
openSUSE:Tumbleweed --> https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ Factory != Tumbleweed.
Then it is worse, but you don't explain what it is.
3 | openSUSE:Factory | https://download.opensuse.org/repositories/openSUSE:/Factory/snapshot/
4 | openSUSE:Tumbleweed | https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/
9 | repo-oss | openSUSE-Tumbleweed-Oss | http://download.opensuse.org/tumbleweed/repo/oss/
files residing in Factory have not been released to Tumbleweed, ie: Factory != Tumbleweed
Ah, ok. Yes, absolutely, he should not have the Factory repo.
What about Tumbleweed/standard/? I thought that was a duplicate of "oss".
appears it is just an "alias" for "oss", they present the same page.
in other words, factory repos should not be used in Tumbleweed, especially by someone as lacking in linux savvy as the OP.
I wonder how he got it there. My guess is he doesn't know, meaning he is using again the "direct install" button or one click.
His system leave a lot to "guess" about.
I just did an experiment.
Search for a package (dolphin)
https://search.opensuse.org/ --> https://search.opensuse.org/packages/ --> https://software.opensuse.org/search?q=dolphin&baseproject=openSUSE%3AFactory --> https://software.opensuse.org/package/dolphin
If I click on "direct install" I get "dolphin.ymp" which contains:
<url>http://download.opensuse.org/tumbleweed/repo/oss/</url>
Which is correct.
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/11/20 6:01 AM, Carlos E. R. wrote:
On 11/10/2020 05.15, Patrick Shanahan wrote:
long snip
Which is correct.
I understand that y'all are trying to dig OP out of repo hell at the moment. However . . . This all started after OP's scanner stopped working following an upgrade. I took a look at the installation package that OP used to install the scanner software. It uses a shell script to install 4 rpm's, including a required network component (even if the machine is not networked) as well as a proprietary component. The scanner software is separate from the Epson driver package, presumably due to its (Seiko) license. Proprietary code can break with an update, particularly to the kernel. Doug should try booting a previous kernel to check that possibility. Failing that, try reinstalling the scanner software. --dg -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 11/10/2020 16.40, DennisG wrote:
On 10/11/20 6:01 AM, Carlos E. R. wrote:
On 11/10/2020 05.15, Patrick Shanahan wrote:
long snip
Which is correct.
I understand that y'all are trying to dig OP out of repo hell at the moment. However . . .
This all started after OP's scanner stopped working following an upgrade. I took a look at the installation package that OP used to install the scanner software. It uses a shell script to install 4 rpm's, including a required network component (even if the machine is not networked) as well as a proprietary component. The scanner software is separate from the Epson driver package, presumably due to its (Seiko) license.
Proprietary code can break with an update, particularly to the kernel. Doug should try booting a previous kernel to check that possibility. Failing that, try reinstalling the scanner software.
Or simply keep to Leap, as we have said a myriad times. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 10/11/20 1:07 PM, Carlos E. R. wrote:
On 11/10/2020 16.40, DennisG wrote:
On 10/11/20 6:01 AM, Carlos E. R. wrote:
On 11/10/2020 05.15, Patrick Shanahan wrote:
>>long snip
Which is correct.
I understand that y'all are trying to dig OP out of repo hell at the moment. However . . .
This all started after OP's scanner stopped working following an upgrade. I took a look at the installation package that OP used to install the scanner software. It uses a shell script to install 4 rpm's, including a required network component (even if the machine is not networked) as well as a proprietary component. The scanner software is separate from the Epson driver package, presumably due to its (Seiko) license.
Proprietary code can break with an update, particularly to the kernel. Doug should try booting a previous kernel to check that possibility. Failing that, try reinstalling the scanner software.
Or simply keep to Leap, as we have said a myriad times.
Except in this case it is possible that a Leap update could have done the same. Proprietary code requires hand-holding. --dg -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2020-10-11 a las 18:13 -0400, DennisG escribió:
On 10/11/20 1:07 PM, Carlos E. R. wrote:
On 11/10/2020 16.40, DennisG wrote:
On 10/11/20 6:01 AM, Carlos E. R. wrote:
On 11/10/2020 05.15, Patrick Shanahan wrote:
...
networked) as well as a proprietary component. The scanner software is separate from the Epson driver package, presumably due to its (Seiko) license.
Proprietary code can break with an update, particularly to the kernel. Doug should try booting a previous kernel to check that possibility. Failing that, try reinstalling the scanner software.
Or simply keep to Leap, as we have said a myriad times.
Except in this case it is possible that a Leap update could have done the same. Proprietary code requires hand-holding.
Yes, but there are no kernel changes inside a release of Leap. On other things, the API or the ABI should not change. It is an LTS - -- Cheers Carlos E. R. (from openSUSE 15.1 (Legolas)) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCX4Oxxhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVQxQAoIiC7hb+AAqlmQRkZgll Si9X577dAJ99CNCvDsvZT4pI2pNWDKzapdi6+w== =ab6B -----END PGP SIGNATURE-----
On Sun, Oct 11, 2020, 18:30 Carlos E. R.
Yes, but there are no kernel changes inside a release of Leap. On other things, the API or the ABI should not change. It is an LTS .
It probably makes no difference, but ... Kernel 5.4 is LTS, not 15.2's 5.3 kernel. Same non LTS applies to TW. -Tomas
On 12/10/2020 04.35, Tomas Kuchta wrote:
On Sun, Oct 11, 2020, 18:30 Carlos E. R. <<>> wrote:
Yes, but there are no kernel changes inside a release of Leap. On other things, the API or the ABI should not change. It is an LTS .
It probably makes no difference, but ...
Kernel 5.4 is LTS, not 15.2's 5.3 kernel. Same non LTS applies to TW.
It is Leap itself which is LTS ;-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 10/11/20 10:41 PM, Carlos E.R. wrote:
On 12/10/2020 04.35, Tomas Kuchta wrote:
On Sun, Oct 11, 2020, 18:30 Carlos E. R. <<>> wrote:
Yes, but there are no kernel changes inside a release of Leap. On other things, the API or the ABI should not change. It is an LTS .
It probably makes no difference, but ...
Kernel 5.4 is LTS, not 15.2's 5.3 kernel. Same non LTS applies to TW.
It is Leap itself which is LTS ;-)
I'm confused. There have been more than a dozen kernel changes in 15.1 (I haven't upgraded yet). So e.g., if I am using the scripted version of the nvidia driver (as some do, vs the repo version), I must reinstall the driver with each of the kernel updates. --dg -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 12/10/2020 19.05, DennisG wrote:
On 10/11/20 10:41 PM, Carlos E.R. wrote:
On 12/10/2020 04.35, Tomas Kuchta wrote:
On Sun, Oct 11, 2020, 18:30 Carlos E. R. <<>> wrote:
Yes, but there are no kernel changes inside a release of Leap. On other things, the API or the ABI should not change. It is an LTS .
It probably makes no difference, but ...
Kernel 5.4 is LTS, not 15.2's 5.3 kernel. Same non LTS applies to TW.
It is Leap itself which is LTS ;-)
I'm confused. There have been more than a dozen kernel changes in 15.1 (I haven't upgraded yet). So e.g., if I am using the scripted version of the nvidia driver (as some do, vs the repo version), I must reinstall the driver with each of the kernel updates.
I think it is related to being a proprietary package. It _seems_ as if the kernel changes things that the NVidia driver uses anytime and the driver stops working or building till it is adapted (patched). And then there are minimal changes that require a compilation. I can not give a technical explanation for this one. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 10/12/20 1:27 PM, Carlos E. R. wrote:
On 12/10/2020 19.05, DennisG wrote:
On 10/11/20 10:41 PM, Carlos E.R. wrote:
On 12/10/2020 04.35, Tomas Kuchta wrote:
On Sun, Oct 11, 2020, 18:30 Carlos E. R. <<>> wrote:
Yes, but there are no kernel changes inside a release of Leap. On other things, the API or the ABI should not change. It is an LTS .
It probably makes no difference, but ...
Kernel 5.4 is LTS, not 15.2's 5.3 kernel. Same non LTS applies to TW.
It is Leap itself which is LTS ;-)
I'm confused. There have been more than a dozen kernel changes in 15.1 (I haven't upgraded yet). So e.g., if I am using the scripted version of the nvidia driver (as some do, vs the repo version), I must reinstall the driver with each of the kernel updates.
I think it is related to being a proprietary package. It _seems_ as if the kernel changes things that the NVidia driver uses anytime and the driver stops working or building till it is adapted (patched).
And then there are minimal changes that require a compilation. I can not give a technical explanation for this one.
That was my meaning, i.e., because the scanner uses proprietary code installed by a proprietary script, it is vulnerable to kernel updates, including on Leap. OP's scanner situation is analogous to using the compiled (non-repo) version of the nvidia driver which must be re-installed with each kernel update. --dg -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 12/10/2020 20.16, DennisG wrote:
On 10/12/20 1:27 PM, Carlos E. R. wrote:
On 12/10/2020 19.05, DennisG wrote:
On 10/11/20 10:41 PM, Carlos E.R. wrote:
On 12/10/2020 04.35, Tomas Kuchta wrote:
On Sun, Oct 11, 2020, 18:30 Carlos E. R. <<>> wrote:
Yes, but there are no kernel changes inside a release of Leap. On other things, the API or the ABI should not change. It is an LTS .
It probably makes no difference, but ...
Kernel 5.4 is LTS, not 15.2's 5.3 kernel. Same non LTS applies to TW.
It is Leap itself which is LTS ;-)
I'm confused. There have been more than a dozen kernel changes in 15.1 (I haven't upgraded yet). So e.g., if I am using the scripted version of the nvidia driver (as some do, vs the repo version), I must reinstall the driver with each of the kernel updates.
I think it is related to being a proprietary package. It _seems_ as if the kernel changes things that the NVidia driver uses anytime and the driver stops working or building till it is adapted (patched).
And then there are minimal changes that require a compilation. I can not give a technical explanation for this one.
That was my meaning, i.e., because the scanner uses proprietary code installed by a proprietary script, it is vulnerable to kernel updates, including on Leap. OP's scanner situation is analogous to using the compiled (non-repo) version of the nvidia driver which must be re-installed with each kernel update.
I see what you mean. However, does the scanner software needs to access the kernel? It is "remote", over the network, so it just need standard network functions to transmit and receive data. The proprietary part would be in the processing of that data, and in sending packages that are commands to the scanner. No need to interface with the computer hardware at all. Even if the driver uses usb, I suppose the situation would be similar, but maybe less so. Interesting. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 10/12/20 3:19 PM, Carlos E. R. wrote:
On 12/10/2020 20.16, DennisG wrote:
On 10/12/20 1:27 PM, Carlos E. R. wrote:
On 12/10/2020 19.05, DennisG wrote:
On 10/11/20 10:41 PM, Carlos E.R. wrote:
snip
That was my meaning, i.e., because the scanner uses proprietary code installed by a proprietary script, it is vulnerable to kernel updates, including on Leap. OP's scanner situation is analogous to using the compiled (non-repo) version of the nvidia driver which must be re-installed with each kernel update.
I see what you mean.
However, does the scanner software needs to access the kernel?
It is "remote", over the network, so it just need standard network functions to transmit and receive data. The proprietary part would be in the processing of that data, and in sending packages that are commands to the scanner. No need to interface with the computer hardware at all.
Even if the driver uses usb, I suppose the situation would be similar, but maybe less so.
Interesting.
Good question. I don't know. And in all honesty, I don't see any benefit in digging into the Epson installation package again. IIRC there are 4 rpm's, one of which includes proprietary code under the Seiko license. The dependencies indicate it gets compiled at installation. There is a network component which is required whether or not the device is networked. And there is an end-user management app in there, too. In any event, checking whether a kernel update is the source of the problem is relatively easy: Boot from the previous kernel; does the scanner now work? Or re-install the software; does the scanner now work? Not foolproof, but seems to me the first things to try. If either of these simple tasks isn't the solution (and which AFAICT, the OP has not tried), OP is probably stuck because it is doubtful anyone can find/unwind which TW update (or something else) it was that borked the device. --dg -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/12/20 5:10 PM, DennisG wrote:
On 10/12/20 3:19 PM, Carlos E. R. wrote:
On 12/10/2020 20.16, DennisG wrote:
On 10/12/20 1:27 PM, Carlos E. R. wrote:
On 12/10/2020 19.05, DennisG wrote:
On 10/11/20 10:41 PM, Carlos E.R. wrote:
snip
That was my meaning, i.e., because the scanner uses proprietary code installed by a proprietary script, it is vulnerable to kernel updates, including on Leap. OP's scanner situation is analogous to using the compiled (non-repo) version of the nvidia driver which must be re-installed with each kernel update.
I see what you mean.
However, does the scanner software needs to access the kernel?
It is "remote", over the network, so it just need standard network functions to transmit and receive data. The proprietary part would be in the processing of that data, and in sending packages that are commands to the scanner. No need to interface with the computer hardware at all.
Even if the driver uses usb, I suppose the situation would be similar, but maybe less so.
Interesting.
Good question. I don't know. And in all honesty, I don't see any benefit in digging into the Epson installation package again.
IIRC there are 4 rpm's, one of which includes proprietary code under the Seiko license. The dependencies indicate it gets compiled at installation. There is a network component which is required whether or not the device is networked. And there is an end-user management app in there, too.
In any event, checking whether a kernel update is the source of the problem is relatively easy: Boot from the previous kernel; does the scanner now work? Or re-install the software; does the scanner now work? Not foolproof, but seems to me the first things to try. If either of these simple tasks isn't the solution (and which AFAICT, the OP has not tried), OP is probably stuck because it is doubtful anyone can find/unwind which TW update (or something else) it was that borked the device.
--dg I would be happy to try that if I knew how. And the only previous kernel I have is on the install disk--2020-0826, which ought to be early enough, but how do I boot from that and now trigger a complete reinstall? Thanx for your assistance! --doug PS: There is now another update: should I install it? -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Doug McGarrett
On 10/12/20 5:10 PM, DennisG wrote:
On 10/12/20 3:19 PM, Carlos E. R. wrote:
On 12/10/2020 20.16, DennisG wrote:
On 10/12/20 1:27 PM, Carlos E. R. wrote:
On 12/10/2020 19.05, DennisG wrote:
On 10/11/20 10:41 PM, Carlos E.R. wrote:
snip
That was my meaning, i.e., because the scanner uses proprietary code installed by a proprietary script, it is vulnerable to kernel updates, including on Leap. OP's scanner situation is analogous to using the compiled (non-repo) version of the nvidia driver which must be re-installed with each kernel update.
I see what you mean.
However, does the scanner software needs to access the kernel?
It is "remote", over the network, so it just need standard network functions to transmit and receive data. The proprietary part would be in the processing of that data, and in sending packages that are commands to the scanner. No need to interface with the computer hardware at all.
Even if the driver uses usb, I suppose the situation would be similar, but maybe less so.
Interesting.
Good question. I don't know. And in all honesty, I don't see any benefit in digging into the Epson installation package again.
IIRC there are 4 rpm's, one of which includes proprietary code under the Seiko license. The dependencies indicate it gets compiled at installation. There is a network component which is required whether or not the device is networked. And there is an end-user management app in there, too.
In any event, checking whether a kernel update is the source of the problem is relatively easy: Boot from the previous kernel; does the scanner now work? Or re-install the software; does the scanner now work? Not foolproof, but seems to me the first things to try. If either of these simple tasks isn't the solution (and which AFAICT, the OP has not tried), OP is probably stuck because it is doubtful anyone can find/unwind which TW update (or something else) it was that borked the device.
--dg I would be happy to try that if I knew how. And the only previous kernel I have is on the install disk--2020-0826, which ought to be early enough, but how do I boot from that and now trigger a complete reinstall? Thanx for your assistance! --doug PS: There is now another update: should I install it?
That you feel the need to ask is evidence you should go back to Leap and alter your machine as little as possible. The questions is impossible for anyone but you to answer and since you do not know the answer, ... Tumbleweed is an ever changing environment which has great system stability but must be administered with understanding and knowledge. The requirements for Leap in that respect are similar but much less. The likelihood of your machine(s) being compromised is(are), or becoming of them becoming unusable is great! -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/14/20 3:09 PM, Doug McGarrett wrote:
On 10/12/20 5:10 PM, DennisG wrote:
On 10/12/20 3:19 PM, Carlos E. R. wrote:
On 12/10/2020 20.16, DennisG wrote:
On 10/12/20 1:27 PM, Carlos E. R. wrote:
On 12/10/2020 19.05, DennisG wrote:
On 10/11/20 10:41 PM, Carlos E.R. wrote:
snip
That was my meaning, i.e., because the scanner uses proprietary code installed by a proprietary script, it is vulnerable to kernel updates, including on Leap. OP's scanner situation is analogous to using the compiled (non-repo) version of the nvidia driver which must be re-installed with each kernel update.
I see what you mean.
However, does the scanner software needs to access the kernel?
It is "remote", over the network, so it just need standard network functions to transmit and receive data. The proprietary part would be in the processing of that data, and in sending packages that are commands to the scanner. No need to interface with the computer hardware at all.
Even if the driver uses usb, I suppose the situation would be similar, but maybe less so.
Interesting.
Good question. I don't know. And in all honesty, I don't see any benefit in digging into the Epson installation package again.
IIRC there are 4 rpm's, one of which includes proprietary code under the Seiko license. The dependencies indicate it gets compiled at installation. There is a network component which is required whether or not the device is networked. And there is an end-user management app in there, too.
In any event, checking whether a kernel update is the source of the problem is relatively easy: Boot from the previous kernel; does the scanner now work? Or re-install the software; does the scanner now work? Not foolproof, but seems to me the first things to try. If either of these simple tasks isn't the solution (and which AFAICT, the OP has not tried), OP is probably stuck because it is doubtful anyone can find/unwind which TW update (or something else) it was that borked the device.
--dg I would be happy to try that if I knew how. And the only previous kernel I have is on the install disk--2020-0826, which ought to be early enough, but how do I boot from that and now trigger a complete reinstall? Thanx for your assistance! --doug PS: There is now another update: should I install it?
Once again Doug, please do not use personal email addresses in your posts to the list. I should not need to explain this. I fired off the above before remembering that you are using TW. (I know, how could I forget?) AFAIK the multi-kernel feature is only supported for Leap. Why? Because TW is a rolling release. If you want to use a previous kernel, probably the best place to get it would be from the Community listing from the OBS (software.opensuse.org). However, given your skill level and the potential risk, I for one will not school you on how to take this any further. Maybe a TW user will help. I presume when you write "if I knew how", that you are only referring to the kernel. You should definitely try re-installing the scanner software. When I looked at the Epson package for you, I don't recall there being an "uninstall" option with the script. (Doesn't mean there isn't one, only that I don't remember one.) You probably can simply run the installation script again and it will likely just write over any previous files it created. For added safety, first run the script with the --dry-run parameter (check the documentation, I may not remember the syntax exactly, but I'm sure it is there). Maybe you'll get lucky. As far as running another update, I am going to try this one (and only one) more time: Get off TW. You aren't looking into each update to see if there is something "newer" that you want, which was your reason for using TW in the first place. But of course, there will be many orders of magnitude of updates that you as an end-user don't care about, don't understand, and don't know how to deal with when something goes awry - which will definitely happen, as it already has with the scanner. But as a TW user, you do need to at least periodically update because if you let those updates stack up you are looking at higher risk once you do update. You are in way over your head, and that has nothing to do with smarts or age, so please don't play those cards again. It's about experience - years of it, hands-on. And I'm not talking about the tinker-toy distro you used before, either. So for the last time, switch to Leap, learn how to use the add-on and OBS repo's to keep your favored apps fresh, and use the Forums (sorry, Knurpht) which has a vast store of searchable past user experiences and moderators who help users at your skill level all the time, which the mailing list has neither of. Stop flogging the donkey! I'm done with this. --dg
On 10/14/20 3:09 PM, Doug McGarrett wrote:
On 10/12/20 5:10 PM, DennisG wrote:
On 10/12/20 3:19 PM, Carlos E. R. wrote:
On 12/10/2020 20.16, DennisG wrote:
On 10/12/20 1:27 PM, Carlos E. R. wrote:
On 12/10/2020 19.05, DennisG wrote:
On 10/11/20 10:41 PM, Carlos E.R. wrote:
snip
That was my meaning, i.e., because the scanner uses proprietary code installed by a proprietary script, it is vulnerable to kernel updates, including on Leap. OP's scanner situation is analogous to using the compiled (non-repo) version of the nvidia driver which must be re-installed with each kernel update.
I see what you mean.
However, does the scanner software needs to access the kernel?
It is "remote", over the network, so it just need standard network functions to transmit and receive data. The proprietary part would be in the processing of that data, and in sending packages that are commands to the scanner. No need to interface with the computer hardware at all.
Even if the driver uses usb, I suppose the situation would be similar, but maybe less so.
Interesting.
Good question. I don't know. And in all honesty, I don't see any benefit in digging into the Epson installation package again.
IIRC there are 4 rpm's, one of which includes proprietary code under the Seiko license. The dependencies indicate it gets compiled at installation. There is a network component which is required whether or not the device is networked. And there is an end-user management app in there, too.
In any event, checking whether a kernel update is the source of the problem is relatively easy: Boot from the previous kernel; does the scanner now work? Or re-install the software; does the scanner now work? Not foolproof, but seems to me the first things to try. If either of these simple tasks isn't the solution (and which AFAICT, the OP has not tried), OP is probably stuck because it is doubtful anyone can find/unwind which TW update (or something else) it was that borked the device.
--dg I would be happy to try that if I knew how. And the only previous kernel I have is on the install disk--2020-0826, which ought to be early enough, but how do I boot from that and now trigger a complete reinstall? Thanx for your assistance! --doug PS: There is now another update: should I install it?
Once again Doug, please do not use personal email addresses in your posts to the list. I should not need to explain this. I fired off the above before remembering that you are using TW. (I know, how could I forget?) AFAIK the multi-kernel feature is only supported for Leap. Why? Because TW is a rolling release. If you want to use a previous kernel, probably the best place to get it would be from the Community listing from the OBS (software.opensuse.org). However, given your skill level and the potential risk, I for one will not school you on how to take this any further. Maybe a TW user will help. I presume when you write "if I knew how", that you are only referring to the kernel. You should definitely try re-installing the scanner software. When I looked at the Epson package for you, I don't recall there being an "uninstall" option with the script. (Doesn't mean there isn't one, only that I don't remember one.) You probably can simply run the installation script again and it will likely just write over the previous files it created. For added safety, first run the script with the --dry-run parameter (check the documentation, I may not remember the syntax exactly, but I'm sure the parm is there). Maybe you'll get lucky. As far as running another update, I am going to try this one (and only one) more time: Get off TW. You aren't looking into each update to see if there is something "newer" that you want, which was your reason for using TW in the first place. But of course, there will be many orders of magnitude of updates that you as an end-user don't care about, don't understand, and don't know how to deal with when something goes awry - which will definitely happen, as it already has with the scanner. It's only a matter of time. You are in way over your head, and that has nothing to do with smarts or age, so please don't play those cards again. It's about experience - years of it, hands-on. And I'm not talking about the tinker-toy distro you used before, either. So for the last time, switch to Leap, learn how to use the add-on and OBS repo's to keep your favored apps fresh, and use the Forums (sorry, Knurpht) which has a vast store of searchable past user experiences and moderators who help users at your skill level all the time, which the mailing list has neither of. Stop flogging the donkey! I'm done with this. --dg -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* DennisG
I fired off the above before remembering that you are using TW. (I know, how could I forget?) AFAIK the multi-kernel feature is only supported for Leap.
no, multi-kernel is utilized by Tw. I keep 4. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/15/20 1:52 PM, Patrick Shanahan wrote:
* DennisG
[10-15-20 13:14]: [...] I fired off the above before remembering that you are using TW. (I know, how could I forget?) AFAIK the multi-kernel feature is only supported for Leap. no, multi-kernel is utilized by Tw. I keep 4.
Right, thanks. The documentation only ref's to Leap. So are you volunteering to help OP with this? :) --dg -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* DennisG
On 10/15/20 1:52 PM, Patrick Shanahan wrote:
* DennisG
[10-15-20 13:14]: [...] I fired off the above before remembering that you are using TW. (I know, how could I forget?) AFAIK the multi-kernel feature is only supported for Leap. no, multi-kernel is utilized by Tw. I keep 4.
Right, thanks. The documentation only ref's to Leap.
So are you volunteering to help OP with this? :)
I have already provided very similar instruction pertaining to the OP's familiarity with linux and necessary skill levels to use Tumbleweed and the overwhelming evidence that he would return to Leap ##. More effort appears wasted electrons. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/15/20 2:06 PM, Patrick Shanahan wrote:
* DennisG [...]
I fired off the above before remembering that you are using TW. (I know, how could I forget?) AFAIK the multi-kernel feature is only supported for Leap. no, multi-kernel is utilized by Tw. I keep 4.
Right, thanks. The documentation only ref's to Leap.
So are you volunteering to help OP with this? :) I have already provided very similar instruction pertaining to the OP's familiarity with linux and necessary skill levels to use Tumbleweed and
* DennisG On 10/15/20 1:52 PM, Patrick Shanahan wrote: the overwhelming evidence that he would return to Leap ##.
More effort appears wasted electrons.
All right. You all win. I will reinstall Leap on my other computer, with no updates or anything except epkowa and see if the scanner can be found and installed. However, my download of Leap is about the same time as the problem on TW began, so if there is a problem in that version of the software, it will probably show up on Leap also. OTH, if it work,s I will bite the bullet and install LEAP on this computer and stop bothering all of you. What bothers me, OpenSUSE installs do not seem to provide for a /home partition, so I will lose everything on a reinstall. (I too am tired of this--I just want to USE the computer, not futz with it continually.) --doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/15/20 3:09 PM, Doug McGarrett wrote:
On 10/15/20 2:06 PM, Patrick Shanahan wrote:
* DennisG [...]
I fired off the above before remembering that you are using TW. (I know, how could I forget?) AFAIK the multi-kernel feature is only supported for Leap. no, multi-kernel is utilized by Tw. I keep 4.
Right, thanks. The documentation only ref's to Leap.
So are you volunteering to help OP with this? :) I have already provided very similar instruction pertaining to the OP's familiarity with linux and necessary skill levels to use Tumbleweed and
* DennisG On 10/15/20 1:52 PM, Patrick Shanahan wrote: the overwhelming evidence that he would return to Leap ##.
More effort appears wasted electrons.
All right. You all win. I will reinstall Leap on my other computer, with no updates or anything except epkowa and see if the scanner can be found and installed. However, my download of Leap is about the same time as the problem on TW began, so if there is a problem in that version of the software, it will probably show up on Leap also. OTH, if it work,s I will bite the bullet and install LEAP on this computer and stop bothering all of you. What bothers me, OpenSUSE installs do not seem to provide for a /home partition, so I will lose everything on a reinstall. (I too am tired of this--I just want to USE the computer, not futz with it continually.) --doug
Did you or did you not install the scanner software as downloaded from the Epson site? --dg -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 15/10/2020 21.09, Doug McGarrett wrote: ...
What bothers me, OpenSUSE installs do not seem to provide for a /home partition, so I will lose everything on a reinstall.
Of course openSUSE does provide for a /home partition. When it offers you a partition setup, don't accept it and click on "guided setup". In there, you can tell it what disk and even what partitions to use. You can also click to say that you want a separate /home and/or swap (or a big swap for hibernation). It will then make a proposal. If that proposal is not exactly to your liking, you click on the "expert partitioner" where you can choose exactly what to do, manually. Verify that your home partition is listed to be mounted and *not* formatted.
(I too am tired of this--I just want to USE the computer, not futz with it continually.)
Understandable. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Am Montag, 12. Oktober 2020, 19:05:59 CEST schrieb DennisG:
On 10/11/20 10:41 PM, Carlos E.R. wrote:
On 12/10/2020 04.35, Tomas Kuchta wrote:
It probably makes no difference, but ... Kernel 5.4 is LTS, not 15.2's 5.3 kernel. Same non LTS applies to TW.
It is Leap itself which is LTS ;-)
I'm confused. There have been more than a dozen kernel changes in 15.1 (I haven't upgraded yet). So e.g., if I am using the scripted version of the nvidia driver (as some do, vs the repo version), I must reinstall the driver with each of the kernel updates.
And? Thats why we have repos for the nvidia-drivers. Esp for Leap this is very convenient - for TW one has to take a closer look, as nvidia lags a bit behind on new kernel versions, and changes to the API (5.9 was released today...) The Leap kernels are maintained by the SUSE kernel team, that grants the long- term-support. Cheers Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/12/20 1:30 PM, Axel Braun wrote:
Am Montag, 12. Oktober 2020, 19:05:59 CEST schrieb DennisG:
On 12/10/2020 04.35, Tomas Kuchta wrote:
It probably makes no difference, but ... Kernel 5.4 is LTS, not 15.2's 5.3 kernel. Same non LTS applies to TW. It is Leap itself which is LTS ;-) I'm confused. There have been more than a dozen kernel changes in 15.1 (I haven't upgraded yet). So e.g., if I am using the scripted version of the nvidia driver (as some do, vs the repo version), I must reinstall
On 10/11/20 10:41 PM, Carlos E.R. wrote: the driver with each of the kernel updates. And? Thats why we have repos for the nvidia-drivers. Esp for Leap this is very convenient - for TW one has to take a closer look, as nvidia lags a bit behind on new kernel versions, and changes to the API (5.9 was released today...)
The Leap kernels are maintained by the SUSE kernel team, that grants the long- term-support.
Cheers Axel
I understand that. And I use that repo, btw. I just used the compile version of the nvidia driver as an example because . . . The origination of this problem is with a scanner that stopped working after an update. The scanner software includes proprietary code (not open-sourced) installed with a script provided by the manufacturer, i.e., it is analogous to using the nvidia compiled (not repo) version which requires re-installation with each kernel update. --dg -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Op zondag 11 oktober 2020 05:15:01 CEST schreef Patrick Shanahan:
files residing in Factory have not been released to Tumbleweed, ie: Factory != Tumbleweed
in other words, factory repos should not be used in Tumbleweed, especially by someone as lacking in linux savvy as the OP. That expresses it perfectly, like I've done numerous times to the OP.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Op zaterdag 10 oktober 2020 22:43:17 CEST schreef Doug McGarrett:
doug@linux1:~> su Password: linux1:/home/doug # zypper lr --details > somefile.txt linux1:/home/doug # susepaste -n "Doug" -t "repo list" -e 40320 somefile.txt Pasted as: https://susepaste.org/14396174 https://paste.opensuse.org/14396174 Link is also in your clipboard. linux1:/home/doug # rpm -q sysvinit-tools sysvinit-tools-2.96-1.3.x86_64 Not good, you should not have that Factory repo.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/10/2020 18.46, Doug McGarrett wrote:
Problem: lsb-4.0.fake-1.5.x86_64 requires /sbin/pidof, but this requirement cannot be provided
Why do you need "lsb-4.0.fake"?
deleted providers: sysvinit-tools-2.96-1.3.x86_64 not installable providers: busybox-sysvinit-tools-1.32.0-11.1.noarch[https-download.opensuse.org-2dfdf701]
Why do you need "busybox-sysvinit-tools"? Or is it a side effect of something else that is missing, perhaps sysvinit-tools? It is a question mostly to others, not you. Doug: do not reboot, do not power off. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Am 10.10.20 um 18:46 schrieb Doug McGarrett: Problem: lsb-4.0.fake-1.5.x86_64 requires /sbin/pidof, but this requirement cannot be provided deleted providers: sysvinit-tools-2.96-1.3.x86_64 ================================================================ from factory list: Am 13.10.20 um 11:16 schrieb Marcus Meissner:
On Tue, Oct 13, 2020 at 11:12:38AM +0200, Johannes Weberhofer wrote:
Since last week, my Tumbleweed installation has some on updating. Any idea, what's wrong? It works fine, as long as I keep sysvinit-tools-2.96-1.3.x86_64, but doesn't really solve the problem.
Best regards, Johannes
Problem: lsb-4.0.fake-1.5.x86_64 benötigt /sbin/pidof, kann jedoch nicht zur Verfügung gestellt werden ================================================================= Gelöschte Anbieter: sysvinit-tools-2.96-1.3.x86_64 =============================================================== Nicht installierbare Anbieter: busybox-sysvinit-tools-1.32.0-11.1.noarch[repo-oss] Lösung 1: Folgende Aktionen werden ausgeführt: Deinstallation von sysvinit-tools-2.96-1.3.x86_64 Deinstallation von xorg-x11-essentials-7.6_1-16.10.noarch Deinstallation von NetworkManager-openvpn-lang-1.8.12-2.3.noarch Deinstallation von xorg-x11-7.6_1-16.10.noarch Deinstallation von gdm-lang-3.36.3-2.1.noarch Deinstallation von gdm-branding-openSUSE-15.1-2.6.noarch Deinstallation von lightdm-gtk-greeter-branding-openSUSE-2.0-3.2.noarch Lösung 2: Folgende Aktionen werden ausgeführt: Deinstallation von lsb-4.0.fake-1.5.x86_64 Deinstallation von atom-1.51.0-0.1.x86_64 Lösung 3: veraltetes sysvinit-tools-2.96-1.3.x86_64 beibehalten Lösung 4: lsb-4.0.fake-1.5.x86_64 durch Ignorieren einiger Abhängigkeiten brechen
https://bugzilla.suse.com/show_bug.cgi?id=1177540
is marked as resolved for one of the next snapshots.
lsb-4.0.fake-2.1.x86_64.rpm
is built there already, so it will be the fix.
Ciao, Marcus
simoN -- www.becherer.de -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
participants (9)
-
Axel Braun
-
Carlos E. R.
-
Carlos E.R.
-
DennisG
-
Doug McGarrett
-
Knurpht-openSUSE
-
Patrick Shanahan
-
Simon Becherer
-
Tomas Kuchta