* don fisher [08-05-18 21:16]:

On 08/04/2018 11:05 PM, David C. Rankin wrote:

...

On 08/04/2018 10:43 PM, don fisher wrote:

...

I have read discussions concerning the wisdom of Opensuse not running current kernels. But I recently purchased an Alienware 13 3 that is near EOL, so it is not real bleeding edge technology. Neither the wireless nor Ethernet are supported, and now I find the the graphics chipset is not supported either. I was able to use a USB wireless transmitter, but I cannot get around the display hardware.

message about wireless in dmesg is: ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2

Qualcomm Atheros Killer E2500 Gigabit Ethernet Controller is not configurable, except with a patch into the /sys directory found on the internet.

Message about the graphics chipset from the Nouveau list is:

"GP106 is supported, you must be using an older kernel (since yours says "unknown chipset")".

How dangerous is it to download on of the kernels from the Opensuse search site. Kernel.org says the latest stable release is 4.17.12. Under search/42.3/community packages, there are a few offerings shown at this revision level. How bad is it to install one of these kernels?

Don

Don,

It's not dangerous at all. openSuSE has long had the KOTD (kernel of the day) repository and the stable repository that offer the latest kernels. You can simply add the repo to your yast repositories and install and test the kernel, e.g.

https://download.opensuse.org/repositories/Kernel:/stable/standard

You can check your /etc/zypp/zypp.conf and make sure you have multiversion for the kernel enabled (I believe it is by default). That way when you install the new kernel from stable -- you will still have your current kernel installed on your machine. If things go south, just select the old kernel at the boot screen by selecting (I forget what the link is called, it is something like "Advanced Options" that is listed either below, or when you expand the highlighted boot entry at the boot screen). The 8sec countdown timer will stop when you do, so you can take your time and pick through the available kernels to boot.

Just confirm in /etc/zypp/zypp.conf you have:

multiversion = provides:multiversion(kernel)

and

multiversion.kernels = latest,latest-1,running

which keeps the running kernel, the kernel with the highest version, and the kernel with the next highest version by my read of the comments (though it is unclear if 'running' and 'latest' apply to the same kernel, the setting is evaluated by /sbin/purge-kernels, not libzypp)

Either way, you will still have your current and stable installed -- which you can boot to your old kernel in case of emergency and just delete the new stable one if it doesn't work out.

I checked and stable is 4.17.12 -- so if your hardware is supported by the latest kernel -- you will be in luck. Good luck.

I am afraid I failed. I was able to add the repo and download a 4.17.12-2 kernel, but not even the serial port or mouse would work. I used Yast to remove the package, but that did not work either because it still shows up as the default kernel to boot.

I choose a 4.14.60-1 kernel from the 42.3 search options, and at least the Ethernet works. Wireless still is on the rocks, and I do not know how to evaluate the video in Linux. The external port still dead. Are there any NVIDIA packages for linux that allow evaluation?

you can always install the nvidia package and then remove it using the install scriptas root: sh ./<NVIDIA-package>.run -aqs --install-libglvnd sh ./<NVIDIA-package>.run --uninstall like: sh ./NVIDIA-Linux-x86_64-390.67.run -aqs --install-libglvnd and there is sh ./<NVIDIA-package>.run --help sh ./<NVIDIA-package>.run -A --help

Is there a clean way to get rid of the 4.17.12-2 kernel parts left in /boot and /lib/modules? I can just delete them, but I am always afraid grub will get angry with me.

zypper -v rm 'rpm -q kernel |grep 4.17.12' the system will update grub. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* don fisher [08-08-18 19:52]:

On 08/05/2018 07:20 PM, Patrick Shanahan wrote:

...

* don fisher [08-05-18 21:16]:

...

On 08/04/2018 11:05 PM, David C. Rankin wrote:

...

On 08/04/2018 10:43 PM, don fisher wrote:

...

I have read discussions concerning the wisdom of Opensuse not running current kernels. But I recently purchased an Alienware 13 3 that is near EOL, so it is not real bleeding edge technology. Neither the wireless nor Ethernet are supported, and now I find the the graphics chipset is not supported either. I was able to use a USB wireless transmitter, but I cannot get around the display hardware.

message about wireless in dmesg is: ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2

Qualcomm Atheros Killer E2500 Gigabit Ethernet Controller is not configurable, except with a patch into the /sys directory found on the internet.

Message about the graphics chipset from the Nouveau list is:

"GP106 is supported, you must be using an older kernel (since yours says "unknown chipset")".

How dangerous is it to download on of the kernels from the Opensuse search site. Kernel.org says the latest stable release is 4.17.12. Under search/42.3/community packages, there are a few offerings shown at this revision level. How bad is it to install one of these kernels?

Don

Don,

It's not dangerous at all. openSuSE has long had the KOTD (kernel of the day) repository and the stable repository that offer the latest kernels. You can simply add the repo to your yast repositories and install and test the kernel, e.g.

https://download.opensuse.org/repositories/Kernel:/stable/standard

You can check your /etc/zypp/zypp.conf and make sure you have multiversion for the kernel enabled (I believe it is by default). That way when you install the new kernel from stable -- you will still have your current kernel installed on your machine. If things go south, just select the old kernel at the boot screen by selecting (I forget what the link is called, it is something like "Advanced Options" that is listed either below, or when you expand the highlighted boot entry at the boot screen). The 8sec countdown timer will stop when you do, so you can take your time and pick through the available kernels to boot.

Just confirm in /etc/zypp/zypp.conf you have:

multiversion = provides:multiversion(kernel)

and

multiversion.kernels = latest,latest-1,running

which keeps the running kernel, the kernel with the highest version, and the kernel with the next highest version by my read of the comments (though it is unclear if 'running' and 'latest' apply to the same kernel, the setting is evaluated by /sbin/purge-kernels, not libzypp)

Either way, you will still have your current and stable installed -- which you can boot to your old kernel in case of emergency and just delete the new stable one if it doesn't work out.

I checked and stable is 4.17.12 -- so if your hardware is supported by the latest kernel -- you will be in luck. Good luck.

I am afraid I failed. I was able to add the repo and download a 4.17.12-2 kernel, but not even the serial port or mouse would work. I used Yast to remove the package, but that did not work either because it still shows up as the default kernel to boot.

I choose a 4.14.60-1 kernel from the 42.3 search options, and at least the Ethernet works. Wireless still is on the rocks, and I do not know how to evaluate the video in Linux. The external port still dead. Are there any NVIDIA packages for linux that allow evaluation?

you can always install the nvidia package and then remove it using the install scriptas root: sh ./<NVIDIA-package>.run -aqs --install-libglvnd sh ./<NVIDIA-package>.run --uninstall

like: sh ./NVIDIA-Linux-x86_64-390.67.run -aqs --install-libglvnd

and there is sh ./<NVIDIA-package>.run --help sh ./<NVIDIA-package>.run -A --help

...

Is there a clean way to get rid of the 4.17.12-2 kernel parts left in /boot and /lib/modules? I can just delete them, but I am always afraid grub will get angry with me.

zypper -v rm 'rpm -q kernel |grep 4.17.12'

the system will update grub.

Could you please include more details. I do not appear to have any of the .run packages on my system, so do not know which directory to be in to execute the above scripts.

you need to download one matching your gpu from: http://download.nvidia.com/XFree86/Linux-x86_64/

As I mentioned previously, I attempted to download kernels from the opensuse search/kernel page, but did not achieve much success. The system would not allow a log off,

I have absolutely no idea what you are talking about.

and I found in the /lib/modules directory, many of the files in /new-kernel/weak-updates/updates/ were unresolved symbolic links. So I removed all if these kernel upgrades.

how did you remove them? zypper se -s kernel-default zypper --help zypper se --help

But I still find them listed in Yast2 as candidates for installation. I would also like to know how to clean up the Yast2 candidates list.

I don't use yast for installing/updateing. I use zypper from the command line. if I told you something about yast installing and/or updateing, it would probably not be correct. I find zypper so much more comprehensive and better suited, and easy to operate. I also feel your level of expertise is perhaps not up to the task you face and maybe you should question before acting as in "removed all if these kernel upgrades". after many years of linux, os2, cp\m, dos and others, I frequently need to research actions or ask questions before performing the act. and I frequently find that things I remember have changed or I really did not understand. man pages are a great reference although frequently cryptic and difficult to comprehend. or old age makes memories incorrect. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

ALERT! ALERT! DANGER WIL ROBERTSON! On 08/08/18 09:57 PM, don fisher wrote:

...

I have tried to perform research on the desired actions, and I have asked many questions on this list. Also, the way I have removed the unwanted kernel upgrades was to grep on my entire system for any files containing the version number of the undesired installed kernel. Then I deleted all of these files and reran grub2-mkconfig.

Nononono Don't do it that way. You end up with an inconsistent system and indeterminate results an. Do it all with zypper. 1. add the repository 2. install using zypper. let zypper take care of consistency and rebuilding grub in a consistent manner 3. remove things using zypper

This part all appears to work, except for the appearance of the deleted kernels in the Yast2 GUI candidates window.

that's an inadequate statement. By definition, yast will show you everything available. So what? It is what it has marked as install or not that matters. And if you've screwed around by deleting files manually it means your RPM database, which is what zypper and yast (and the underlying libraries they have in common) base their knowledge one, no longer matches what you have installed. That translates to: YOU'VE SCREWED UP YOUR SYSTEM In the meantime, try to limit or repair it by running 'zypper verify'

I downloaded these kernels from the page:

https://software.opensuse.org/package/kernel-default,

Nononono. You add that to your repositories (using 'zypper addrepo' (try 'zypper help addrepo' for details)) You then use 'zypper in --from' specifying that repository (use 'zypper help in' for details). DO NOT UNDER ANY CIRCUMSTANCES TRY ADDING OR DELETING FILES DIRECTLY YOU WILL MAKE YOUR SYSTEM INCONSISTENT ... or worse, and may not be able to recover from the damage you've caused by your manual intervention.

under the "Opensuse 42.3", "show community packages". It shows "1 click install" for the suggested kernels. This method of installing desired software has been suggested many times on this list. What is different here?

Using the web based search is great for finding things that you can't find because they are not in a Well Known Repository. THAT IS NOT THE CASE HERE What is different is that you are not following a tried and trued method and because you didn't do that you are not trying a shotgun approach. The web search is a superb tool but we are dealing with a Well Known Repository and one that has been discussed and recommended very often on this list.

I am trying to learn more, but have found that sometimes experimentation is all that works. I have read the entire zipper man page, but still do not understand how all the parts fit together.

Zypper does everything that Yast in sw-single mode does and bit more, They are both front ends for the relevant libraries. GUIs are a bit more 'idiot stick' since they have all the icons. Both are 'Swiss army knives' with lots of blades. When you run 'zypper help' it gives you all the possible first order commands. I always use zypper; but then I don't use about 85% of the possible commands. And of the 15% I do use, about 3% I have to look at the 'help' 'cos I don't use them often enough to remember the syntax. But the circumstances I use yast are very very very very very rare. Compared to zypper it is too slow, to unresponsive, to much fiddle-faddle in the way of getting Things Done. In Yast those map to various icons.

The last time I was required to build kernels they were first downloaded from kernel.org, configured and then compiled.

Gee, I don't thing I've done that since the beginning of the 1990s with Slackware. Too much aggravation. It turned me off Linux and I went back to using SCO.

I have been trying to learn how to do things the Opensuse way.

Manually deleting files so as to upset the consistency of the RPM database is certainly NOT the OpenSUSE way! ===================================================== At this point, I think that I and Patrick might like to know just what repositories you DO have configured. So, can you please show us the output of running, as root, 'zypper lr' -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/08/2018 09:09 PM, Anton Aylward wrote:

ALERT! ALERT! DANGER WIL ROBERTSON!

On 08/08/18 09:57 PM, don fisher wrote:

...

...

I have tried to perform research on the desired actions, and I have asked many questions on this list. Also, the way I have removed the unwanted kernel upgrades was to grep on my entire system for any files containing the version number of the undesired installed kernel. Then I deleted all of these files and reran grub2-mkconfig.

Nononono Don't do it that way. You end up with an inconsistent system and indeterminate results an.

Do it all with zypper.

1. add the repository 2. install using zypper. let zypper take care of consistency and rebuilding grub in a consistent manner 3. remove things using zypper

...

This part all appears to work, except for the appearance of the deleted kernels in the Yast2 GUI candidates window.

that's an inadequate statement. By definition, yast will show you everything available. So what? It is what it has marked as install or not that matters.

And if you've screwed around by deleting files manually it means your RPM database, which is what zypper and yast (and the underlying libraries they have in common) base their knowledge one, no longer matches what you have installed. That translates to:

YOU'VE SCREWED UP YOUR SYSTEM

In the meantime, try to limit or repair it by running 'zypper verify'

...

I downloaded these kernels from the page:

https://software.opensuse.org/package/kernel-default,

Nononono.

You add that to your repositories (using 'zypper addrepo' (try 'zypper help addrepo' for details))

You then use 'zypper in --from' specifying that repository (use 'zypper help in' for details).

DO NOT UNDER ANY CIRCUMSTANCES TRY ADDING OR DELETING FILES DIRECTLY YOU WILL MAKE YOUR SYSTEM INCONSISTENT

... or worse, and may not be able to recover from the damage you've caused by your manual intervention.

...

under the "Opensuse 42.3", "show community packages". It shows "1 click install" for the suggested kernels. This method of installing desired software has been suggested many times on this list. What is different here?

Using the web based search is great for finding things that you can't find because they are not in a Well Known Repository. THAT IS NOT THE CASE HERE

What is different is that you are not following a tried and trued method and because you didn't do that you are not trying a shotgun approach.

The web search is a superb tool but we are dealing with a Well Known Repository and one that has been discussed and recommended very often on this list.

...

I am trying to learn more, but have found that sometimes experimentation is all that works. I have read the entire zipper man page, but still do not understand how all the parts fit together.

Zypper does everything that Yast in sw-single mode does and bit more, They are both front ends for the relevant libraries. GUIs are a bit more 'idiot stick' since they have all the icons. Both are 'Swiss army knives' with lots of blades.

When you run 'zypper help' it gives you all the possible first order commands.

I always use zypper; but then I don't use about 85% of the possible commands. And of the 15% I do use, about 3% I have to look at the 'help' 'cos I don't use them often enough to remember the syntax.

But the circumstances I use yast are very very very very very rare. Compared to zypper it is too slow, to unresponsive, to much fiddle-faddle in the way of getting Things Done. In Yast those map to various icons.

...

The last time I was required to build kernels they were first downloaded from kernel.org, configured and then compiled.

Gee, I don't thing I've done that since the beginning of the 1990s with Slackware. Too much aggravation. It turned me off Linux and I went back to using SCO.

...

I have been trying to learn how to do things the Opensuse way.

Manually deleting files so as to upset the consistency of the RPM database is certainly NOT the OpenSUSE way!

=====================================================

At this point, I think that I and Patrick might like to know just what repositories you DO have configured.

So, can you please show us the output of running, as root, 'zypper lr'

With your notes, and the opensuse ref manual section "Installing/Removing Multiple Kernel Versions with Zypper" I thought I had made progress, but reboot was still a problem. I still find broken links in the directory /lib/modules/4.17.13-2.g9079348-default/weak-updates/updates/drivers/net/wireless/realtek/rtl8xxxu. I have one of these devices. zypper se -si 'kernel*' showed nothing strange. sudo zypper refresh executed without errors. As requested, the output of zypper repos is, showint the addition of my kernel-std-repo: A list of my repositories is: # | Alias | Name | Enabled | GPG Check | Refresh ---+-------------------------------------+-----------------------------------------+---------+-----------+-------- 1 | download.opensuse.org-non-oss | Main Repository (NON-OSS) | Yes | (r ) Yes | Yes 2 | download.opensuse.org-non-oss_1 | Update Repository (Non-Oss) | Yes | (r ) Yes | Yes 3 | download.opensuse.org-oss | Main Repository (OSS) | Yes | (r ) Yes | Yes 4 | download.opensuse.org-oss_1 | Main Update Repository | Yes | (r ) Yes | Yes 5 | http-download.opensuse.org-07b77dbf | home:nuklly | Yes | (r ) Yes | Yes 6 | http-download.opensuse.org-121621ad | home:so_it_team | Yes | (r ) Yes | Yes 7 | http-download.opensuse.org-56bf35aa | home:Ximi1970:openSUSE:Extra | Yes | (r ) Yes | Yes 8 | http-download.opensuse.org-5dbaf090 | home:winski | Yes | (r ) Yes | Yes 9 | http-download.opensuse.org-68d87445 | devel:languages:perl:CPAN-G | Yes | (r ) Yes | Yes 10 | http-download.opensuse.org-6fae2c22 | X11:windowmanagers | Yes | (r ) Yes | Yes 11 | http-download.opensuse.org-9721b024 | openSUSE:Leap:42.3:Update | Yes | (r ) Yes | Yes 12 | kernel-std-repo | kernel-std-repo | Yes | (r ) Yes | No 13 | openSUSE-Leap-42.3-0 | openSUSE-Leap-42.3-0 | No | ---- | ---- 14 | repo-debug | openSUSE-Leap-42.3-Debug | No | ---- | ---- 15 | repo-debug-non-oss | openSUSE-Leap-42.3-Debug-Non-Oss | No | ---- | ---- 16 | repo-debug-update | openSUSE-Leap-42.3-Update-Debug | No | ---- | ---- 17 | repo-debug-update-non-oss | openSUSE-Leap-42.3-Update-Debug-Non-Oss | No | ---- | ---- 18 | repo-source | openSUSE-Leap-42.3-Source | No | ---- | ---- 19 | repo-source-non-oss | openSUSE-Leap-42.3-Source-Non-Oss | No | ---- | ---- Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-09 7:25 p.m., don fisher wrote:

...

With your notes, and the opensuse ref manual section "Installing/Removing Multiple Kernel Versions with Zypper" I thought I had made progress, but reboot was still a problem.

I still find broken links in the directory /lib/modules/4.17.13-2.g9079348-default/weak-updates/updates/drivers/net/wireless/realtek/rtl8xxxu.

Could you detail those, please. "Broken'? Where would they point to that is missing? Earlier in this thread someone explained how to use 'rpm -qf' to find the package to which the file belongs. Would you please try accounting for the package for those links and what their destination would have been. I'm pretty shure this is a result of you manually deleting files rather than using zypper to delete the package. It may be that the RPM database thinks the files that make up a package it know about (aka was installed) are there but they are not because you manually deleted them. Cleaning that up and then rerunning MkInitrd/Dracut should elimiante some of your problems. At some point, however, it may be simpler to wipe it all and start from scratch. But I suspect you're jinxed. Some people are. Contrariwise some people never seem to have any of these problems and can can do elaborate multi-systems install that dazzle the rest of us. Then again, you see some amazing skateboarders and skiers, and skaters and then there are klutzes like me who does great damage to the front of my face whenever I try. I'm going to try macramé one day ... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-09 9:51 p.m., don fisher wrote:

The package is shown by zypper se -s 'kernel*', kernel-default-base-4.17.13-2.1.g9079348, that I installed using zypper:

That invocation of the search function only tells you what the repositories know abut. You need zypper se -i 'kernel*' to interrogate the RPM database to see what you actually have installed. Then, knowing that, you can run 'rpm -ql ' to see what files the RPM database thinks should exist. Then you can do a step and repeat to see if they actually exist Actually you might do it in a simpler fashion; go directly to the RPM database and query that: rpm -qa| grep 'kernel*' using that I get kernel-firmware-20180730-35.1.noarch kernel-docs-pdf-4.11.8-1.1.g42bd7a0.noarch kernel-default-4.17.12-2.1.gef4920c.x86_64 kernel-default-4.17.11-3.1.g9155e12.x86_64 kernel-default-4.17.11-4.1.g6676306.x86_64 kernel-macros-4.17.13-2.1.g9079348.noarch kernel-default-4.17.10-3.1.gf604b8a.x86_64 kernel-default-4.17.13-2.1.g9079348.x86_64 kernel-default-4.17.11-5.1.g6676306.x86_64 I then step and repeat, for example running: rpm -ql kernel-default-4.17.13-2.1.g9079348 | xargs ls -l and see that there are no errors.

zypper dist-upgrade --from kernel-std-repo. I think it has nothing to do with me deleting files in other directories.

No, just what did you delete then?

I tried to start over, but as described in another email, the damn Leap 15 DVD install program would not boot. The Leap 42.3 DVD boots without any problems. This can have absolutely nothing to do with my installed system.

Given that your DVD has no errors ((when you downloaded the ISO did you do the MD5 check?) (when you burnt it did you do an integrity and md5 check?)) then it sounds like you have either a reader tolerance problem or a BIOS problem. In my time I've seen both. I've also seen situations where re-burning the DVD worked, where re-downloading and re-burning the DVD worked. Laser readers are better than floppy drives as far as tolerance go, but there are still many cases ... (I'm assuming that both disks ARE DVD and you are using a DVD reader. Some disks do fit on a CD, such as the "LiveCD' versions or the Net Install versions.) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-10 5:15 p.m., don fisher wrote:

...

The only files I deleted were in /boot/ and the /lib/modules that were specific to the kernel.

Yes, that I read, that's what I believed. That's what you did wrong. That's what got you out of sync with the RPM database. That's not the way to 'uninstall' things. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

how did a message in this thread get reduced to less than 200 lines? Frustration?

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* don fisher [08-10-18 22:36]:

On 08/10/2018 02:35 PM, Anton Aylward wrote:

...

On 2018-08-10 5:15 p.m., don fisher wrote:

...

...

The only files I deleted were in /boot/ and the /lib/modules that were specific to the kernel.

Yes, that I read, that's what I believed. That's what you did wrong. That's what got you out of sync with the RPM database. That's not the way to 'uninstall' things.

Maybe we should take this discussion private so as not to burden the list. I do not understand the significance of staying in sync with the RPM database. And where does this database live?

The rpm database keeps track of your installed apps, where and what versions and how to remove them and what they depend on and ... man rpm

I was trying to address a problem I ended up having trying do add later version kernels. I plan research this further on my own. Nobody has explained why deleting the old kernel files should cause the problems I experienced. The laptop hardware appears to have a lot of problems. There are only two USB ports with an additional pair of USB C ports. Adding standard USB devices through a USB to USB C adapter does not appear to be reliable.

have you bothered to investigate the openSUSE distro package management?

The only reason I wanted the later kernel is that the Nouveau list responded that my kernel was not late enough to support the hardware. I will put this problem on hold until I get other aspects of the system working.

?? Nouveau list ?? telling you about openSUSE packages including nouveau and kernels? the main differences between the many distros are their package management methods and how up-to-date their aps and the numbers of apps. ps: personal replies and not the norm here and may invoke loud exception. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-10 11:31 p.m., Felix Miata wrote:

Staying in sync is a fundamental requirement of the package management system. Break it, and break your installation. Don't mess with it under penalty of irreparable problems.

Zypper and YaST know how to use it properly. You need not be concerned with "keeping in sync" if you stick to using them according to instructions.

And as Patrick said:

the main differences between the many distros are their package management methods

I *is* possible to use Zypper (i woudln't want to try with yast) to install a package from another distribution ... MAYBE. It would have to be a RPM or converted to a RPM. Even so, there's no guarantee it CAN be installed or that if it was that it would work. Similarly trying to install a repository from another distribution is ... 'not recommended'. Patrick has given sound advice on the ways to enable nVidia driver on openSUSE. James Knott might be able to advise on your USB problems, but I suspect, googling around and looking at some kernel sites, that you have created this problem yourself, Don, possible by the way you are engaging/load the USB drivers. Sadly you don't give adequate details of your /etc/modules-load.d/ and your modprobe values and parameters. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/10/2018 11:40 PM, Basil Chupin wrote:

You haven't responded to my earlier post suggesting to you to start afresh: format your HD and install whatever version of openSUSE you have -- I think you are able to install 42.3. Do that and then after you have this running we can go then walk you thru on how to install the latest, new, kernel. OK?

BC

I have ordered a new PCIe NVMe - M.2 Internal SSD to build a new system on. No std hard drives in this system. The SSD is not due to arrive for a week or so. I would be anxious to try the walk thru you suggest at that time. I am not against the RPM database concept. I just did not realize it was used to keep track of installed versions etc. I once asked on this list for documentation describing the system architecture and did not receive any relevant responses. RPM originally stood for Red Hat Package Manager. I started under Red Hat and did not realize RPM was critical to opensuse. I would gladly have used the rpm --erase if I had known it was relevant. It is certainly easier than deleting all of the files in /boot and repairing the links. Thanks, and please have patience. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/11/2018 03:20 PM, don fisher wrote:

I have ordered a new  PCIe NVMe - M.2 Internal SSD to build a new system on. No std hard drives in this system. The SSD is not due to arrive for a week or so. I would be anxious to try the walk thru you suggest at that time. I am not against the RPM database concept. I just did not realize it was used to keep track of installed versions etc. I once asked on this list for documentation describing the system architecture and did not receive any relevant responses. RPM originally stood for Red Hat Package Manager. I started under Red Hat and did not realize RPM was critical to opensuse. I would gladly have used the rpm --erase if I had known it was relevant. It is certainly easier than deleting all of the files  in /boot and repairing the links.

Thanks, and please have patience.

Don

If there is any confusion YUM is "Yellowdog Update Manager" which is used on many distribution beyond Yellowdog Linux.... All Linux distribution (with a few tiny exceptions) use a package manager to keep the all files installed on the system under a management system that provides dependency checking, version tracking, and conflict protection across all files installed on a system. When you willy-nilly add or remove files from your system without using the package manager, you destroy the ability for the package manager to validate the set of files installed on your system will actually run as intended. Once you get to the point where the package manager can no longer do it's job, the solution is simply to *reformat* and *reinstall*. A basic reformat and reinstall takes no longer than a regular install. You could install, break, reinstall a dozen times a day if you were really ambitious. If there is any questions in your mind about what RPM does or how to use it, go read Learn Linux, 101: RPM and YUM package management http://www.ibm.com/developerworks/library/l-lpic1-102-5/ An Introduction to Package Management http://ftp.rpm.org/max-rpm/ch-intro-to-rpm.html YaST Software Management https://en.opensuse.org/YaST_Software_Management Package management https://en.opensuse.org/Package_management -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-11 4:20 p.m., don fisher wrote:

I once asked on this list for documentation describing the system architecture and did not receive any relevant responses.

because (a) it's an INCREDIBLY open-ended question and almost every facet of it is out there on the 'net of you google for it and follow links. You have about a year or more worth of reading. Did you expect a reply in less than 100 million word? that's the sort of thing that you have to look out for yourself because any answer you might get is based on how the person replying decides to interpret your request. For example, there is a LINUX Standard File System Structure which openSUSE adheres to and build on but what gets to be part of the "builds on" depends on version and what packages you install. And a LOT of the answer gets back to the basics of Linux and the heritage from UNIX and What is GNU? and Who Is Henry Spenser?

RPM originally stood for Red Hat Package Manager.

"Yes, it used to be, but we changed all that".

I started under Red Hat

MISTAKE! You need to have Read Lewis Carrol and Alfred Korzybski. The Name of a Thing is not The Thing. Oh, wait, that was Gerry Weinberg. "The Secrets of Consulting"

and did not realize RPM was critical to opensuse. I would gladly have used the rpm --erase if I had known it was relevant. It is certainly easier than deleting all of the files in /boot and repairing the links.

Part of the answer to your question about architecture is ... RTFM As Patrick pointed out, there is the RPM man page.. And there is also the Zypper man page. I would NEVER use 'rpm --erase'; I would use 'zypper rm' instead to make sure all the dependencies were enforced. Patience, Grasshopper. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 13 Aug 2018 18:02:50 +0200 "Carlos E. R." wrote:

On Linux, when you tell YaST to install/update/remove something, it _thinks_. What is already installed, what is needed to do to obtain what the user is requesting. And to do so it queries the database of installed packages, and updates it with the changes. Every single file that was installed from a package is listed there (exceptions are files created locally by installation scripts).

Thus if you delete a file manually YaST/zypper/rpm will think that the file is still there and the decisions it takes will be based on that knowledge, that happens to be wrong because you deleted something.

I'm curious. It would seem fairly simple for a package manager to actually check for the presence of file that it thought were installed (perhaps separately as part of a 'verify' operation or perhaps as part of its general operation). Do any package managers actually have that ability, do you know? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 13/08/2018 21:32, Dave Howorth wrote:

On Mon, 13 Aug 2018 18:02:50 +0200 "Carlos E. R." wrote:

...

On Linux, when you tell YaST to install/update/remove something, it _thinks_. What is already installed, what is needed to do to obtain what the user is requesting. And to do so it queries the database of installed packages, and updates it with the changes. Every single file that was installed from a package is listed there (exceptions are files created locally by installation scripts).

Thus if you delete a file manually YaST/zypper/rpm will think that the file is still there and the decisions it takes will be based on that knowledge, that happens to be wrong because you deleted something.

I'm curious. It would seem fairly simple for a package manager to actually check for the presence of file that it thought were installed (perhaps separately as part of a 'verify' operation or perhaps as part of its general operation). Do any package managers actually have that ability, do you know?

Verify mode. But there is no "repair mode". -- Saludos/Cheers, Carlos E.R. (Minas-Morgul - W10) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-10 10:34 p.m., don fisher wrote:

There are only two USB ports with an additional pair of USB C ports. Adding standard USB devices through a USB to USB C adapter does not appear to be reliable.

And the drivers you have for those are? Someone suggested using 'ixni' but we didn't see you report the output of that. I'd like to know the hardware USB configuration the kernel sees. Rather than just dmesg | grep -i usb we might also see lsmod | grep usb ... with and without that adapter and the cascaded devices ... For example, my keyboard is USB, but it also has a couple of USB socket of its own ... [ 6.956028] usb 3-2.1: new full-speed USB device number 4 using uhci_hcd [ 7.121537] usb 3-2.1: New USB device found, idVendor=04b3, idProduct=301b, bcdDevice= 1.00 [ 7.133623] usb 3-2.1: New USB device strings: Mfr=1, Product=3, SerialNumber=0 [ 7.145911] usb 3-2.1: Product: USB Productivity Option Keyboard( has the hub in # 1 ) [ 7.157995] usb 3-2.1: Manufacturer: Lite-On Technology [ 7.180049] input: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ) as /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.0/0003:04B3:301B.0002/input/input4 [ 7.264187] hid-generic 0003:04B3:301B.0002: input,hidraw1: USB HID v1.10 Keyboard [Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 )] on usb-0000:00:1a.0-2.1/input0 [ 7.295963] input: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ) as /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.1/0003:04B3:301B.0003/input/input5 [ 7.380083] hid-generic 0003:04B3:301B.0003: input,hidraw2: USB HID v1.10 Device [Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 )] on usb-0000:00:1a.0-2.1/input1 You should be seeing something like that for your cascaded devices. Please show us the details. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/08/18 10:49, don fisher wrote:

On 08/08/2018 09:09 PM, Anton Aylward wrote:

...

ALERT!     ALERT! DANGER WIL ROBERTSON!

On 08/08/18 09:57 PM, don fisher wrote:

<pruned>

...

...

I have been trying to learn how to do things the Opensuse way.

Manually deleting files so as to upset the consistency of the RPM database is certainly NOT the OpenSUSE way!

=====================================================

At this point, I think that I and Patrick might like to know just what repositories you DO have configured.

So, can you please show us the output of running, as root, 'zypper lr'

I tried to upgrade to Leap 15 and the DVD upgrade stalled at the first entry, examining USB devices. It had already loaded USB devices during boot, so am a bit confused. I cannot get almost anything to work on this laptop:-(.

Don

Don, As my sig states- <quote> There comes a time in the affairs of a man when he has to take the bull by the tail and face the situation.                          W C Fields </quote> I think that it is time for you to format the HD which is in that laptop you bought and start from scratch: install Leap 15.0 from a DVD ... and then let's take it from there. From what I have read above in this thread, you are confused about what you have already done and about what you should do and we, at this end, are also getting confused. So, start from scratch: format the laptop's HD and install Leap 15.0 (and install without the uefi requirement, the laptop won't be able to handle it anyway I suspect). BC -- There comes a time in the affairs of a man when he has to take the bull by the tail and face the situation. W C Fields -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-09 10:52 p.m., Basil Chupin wrote:

...

Ouch! Sorry, I forgot that you said you had a problem in installing Leap 15.0 and therefore forgot to add this to my comment above: when you start the DVD to install Leap, add the instruction 'nomodeset' (without the single quotation marks ' ) on the kernel command line. This will/should get you past that sudden stop in the installation process which you experienced (and which I, and many others, have the good misfortune of experiencing).

This rather depends on the problems he has with the DVD. if the DVD won't boot ... One thing I've observed: Don is not very explicit in describing his problems But then again, many people aren't either. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-11 2:21 a.m., Basil Chupin wrote:

Of course, but what Don wrote was-

<quote>

Leap 15 DVD install program would not boot.

</quote>

which, to me, meant that while the DVD booted he couldn't get past selecting the Install part.

Whereas I read it that it would not boot. All in all, Don is not being adequate precise, so it is open to interpretation. if it were me, I would say that the DVD booted and loaded the install program but that the install program hung, and do my best to specify WHERE it hung. IIR it gets to the point where there is a green progress bar thing ... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 14/08/18 02:04, Carlos E. R. wrote:

On 2018-08-11 08:21, Basil Chupin wrote:

...

On 10/8/18 10:04 pm, Anton Aylward wrote:

...

On 2018-08-09 10:52 p.m., Basil Chupin wrote:

...

...

This rather depends on the problems he has with the DVD. if the DVD won't boot ...

Of course, but what Don wrote was-

<quote>

Leap 15 DVD install program would not boot.

</quote>

which, to me, meant that while the DVD booted he couldn't get past selecting the Install part. Well, I would then on the DVD boot menu choose the entry for self-checking the DVD

How would this get the installer to begin the installation process? BC -- There comes a time in the affairs of a man when he has to take the bull by the tail and face the situation. W C Fields -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/08/18 05:15, Carlos E. R. wrote:

On 2018-08-17 09:14, Basil Chupin wrote:

...

On 14/08/18 02:04, Carlos E. R. wrote:

...

On 2018-08-11 08:21, Basil Chupin wrote:

...

On 10/8/18 10:04 pm, Anton Aylward wrote:

...

On 2018-08-09 10:52 p.m., Basil Chupin wrote: This rather depends on the problems he has with the DVD. if the DVD won't boot ... Of course, but what Don wrote was-

<quote>

Leap 15 DVD install program would not boot.

</quote>

which, to me, meant that while the DVD booted he couldn't get past selecting the Install part. Well, I would then on the DVD boot menu choose the entry for self-checking the DVD How would this get the installer to begin the installation process? It wouldn't.

The idea is to verify that the DVD is correct before rebooting again to install. Maybe it is bad.

Right. Just for the record, so to speak, yesterday I was forced by circumstances to re-install Leap 15.0 on my laptop. I have a DVD which has been checked for errors (there are none), and the surface of the DVD is perfectly clean and yet, when the DVD 'booted' and I selected "Installation" from the menu, the loading of the kernel "stopped, short, never to go again" some 25 seconds into the process. I then rebooted the laptop and when Leap 15's menu came up I typed "nomodeset" on the kernel command line, pressed ENTER ... and the installation then proceeded without a hitch. "Good!", I thought to myself, "now I can tell Carlos that what I stated earlier is proven." :-) BC -- There comes a time in the affairs of a man when he has to take the bull by the tail and face the situation. W C Fields -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/17/2018 09:24 PM, Basil Chupin wrote:

On 18/08/18 05:15, Carlos E. R. wrote:

...

On 2018-08-17 09:14, Basil Chupin wrote:

...

On 14/08/18 02:04, Carlos E. R. wrote:

...

On 2018-08-11 08:21, Basil Chupin wrote:

...

On 10/8/18 10:04 pm, Anton Aylward wrote:

...

On 2018-08-09 10:52 p.m., Basil Chupin wrote: This rather depends on the problems he has with the DVD. if the DVD won't boot ... Of course, but what Don wrote was-

<quote>

Leap 15 DVD install program would not boot.

</quote>

which, to me, meant that while the DVD booted he couldn't get past selecting the Install part. Well, I would then on the DVD boot menu choose the entry for self-checking the DVD How would this get the installer to begin the installation process? It wouldn't.

The idea is to verify that the DVD is correct before rebooting again to install. Maybe it is bad.

Right.

Just for the record, so to speak, yesterday I was forced by circumstances to re-install Leap 15.0 on my laptop.

I have a DVD which has been checked for errors (there are none), and the surface of the DVD is perfectly clean and yet, when the DVD 'booted' and I selected "Installation" from the menu, the loading of the kernel "stopped, short, never to go again" some 25 seconds into the process.

I then rebooted the laptop and when Leap 15's menu came up I typed "nomodeset" on the kernel command line, pressed ENTER ... and the installation then proceeded without a hitch.

"Good!", I thought to myself, "now I can tell Carlos that what I stated earlier is proven." :-) nomodset did not function for me. Thanks for the suggestion. I am going to set loglevel=7 and see what it tells me.

Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-09 03:57, don fisher wrote:

On 08/08/2018 05:44 PM, Patrick Shanahan wrote:

...

* don fisher <> [08-08-18 19:52]:

...

On 08/05/2018 07:20 PM, Patrick Shanahan wrote:

...

* don fisher <> [08-05-18 21:16]:

...

On 08/04/2018 11:05 PM, David C. Rankin wrote:

...

On 08/04/2018 10:43 PM, don fisher wrote:

...

...

...

But I still find them listed in Yast2 as candidates for installation.  I would also like to know how to clean up the Yast2 candidates list.

I don't use yast for installing/updateing.  I use zypper from the command line.  if I told you something about yast installing and/or updateing, it would probably not be correct.  I find zypper so much more comprehensive and better suited, and easy to operate.

I also feel your level of expertise is perhaps not up to the task you face and maybe you should question before acting as in "removed all if these kernel upgrades".  after many years of linux, os2, cp\m, dos and others, I frequently need to research actions or ask questions before performing the act.  and I frequently find that things I remember have changed or I really did not understand.  man pages are a great reference although frequently cryptic and difficult to comprehend.  or old age makes memories incorrect.

I have tried to perform research on the desired actions, and I have asked many questions on this list. Also, the way I have removed the unwanted kernel upgrades was to grep on my entire system for any files containing the version number of the undesired installed kernel. Then I deleted all of these files and reran grub2-mkconfig. This part all appears to work, except for the appearance of the deleted kernels in the Yast2 GUI candidates window.

Well, obviously, that's not the way to delete system files. You did not delete the packages that installed them Suppose you find you want to delete "/path/to/something/I/want/to/delete". Well, instead of: rm /path/to/something/I/want/to/delete you have to do: rpm -qf /path/to/something/I/want/to/delete which will tell you what rpm installed that file, and then, if you still want to delete it, you do: rpm --erase nameof_package_you_found

I downloaded these kernels from the page:

 https://software.opensuse.org/package/kernel-default,

under the "Opensuse 42.3", "show community packages". It shows "1 click install" for the suggested kernels. This method of installing desired software has been suggested many times on this list. What is different here?

An alternate is to right click on the download package link to obtain the download path, and then use the paste buffer to paste that path as new repository for yast-zypper - but you have to edit the result, removing the package name and perhaps one or two directories from it.

I am trying to learn more, but have found that sometimes experimentation is all that works. I have read the entire zipper man page, but still do not understand how all the parts fit together. The last time I was required to build kernels they were first downloaded from kernel.org, configured and then compiled. I have been trying to learn how to do things the Opensuse way.

-- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 2018-08-09 15:59, Anton Aylward wrote:

On 09/08/18 05:25 AM, Carlos E. R. wrote:

...

rpm --erase nameof_package_you_found

I prefer to use 'zypper rm nameof_package_you_found' for a number of reasons. One of them is that we are discussing the kernel here, and if you add or delete a kernel you want to make sure that the other aspects of the system , in particular grub, match up with it. There's no point in trying to book a kernel that is no longer there.

Grub will match :-)

Unless you specifically over-ride, zypper is going to make sure that any dependencies etc etc are taken care off. The RPM command doesn't have all those smarts.

Not exactly :-) Rpm command will check that the dependencies are fulfilled, and refuse to delete the package if they don't. Zypper will install other packages to replace what you delete to fulfill dependencies. Both check dependencies. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-08-05 at 22:10 -0700, don fisher wrote:

This appears to be a knowledgeable group so I hope you will forgive me for going a bit off topic. I mentioned the error message: ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2

Can someone tell me what the hw3.0 designation is, and the firmware-5.bin designation. I have seen mention of both boards and chips. Is the hw3.0 the board revision number and the firmware-5 the software revision number? I could not find this info after many hours on google.

maybe hwinfo --netcard tells you something. Perhaps also "inxi -n -x" if installed. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAltoKu4ACgkQtTMYHG2NR9Vd6gCfYUUwV9OgB3BTsw9PSQoGXsU0 /9QAn0YGm65dC7Pu/+RkdsHJ4f3YgaBV =cMQD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

don fisher composed on 2018-08-06 13:55 (UTC-0700):

> Thanks for the inxi command:-) It is great:-) I do not see it listed in 
> the 909 page "Linux in a Nutshell", 6th edition which I have used as my 
> bible.

When was that book published?

> Where did that one come from, and are there others?

I don't think inxi has been around all that long:

>From changelog:
* Sat Oct 22 2011 malcolmlewis@opensuse.org
- Initial build.

https://smxi.org/
https://smxi.org/docs/inxi.htm

History there I see only versions and forking, no dates.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

-- 
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-16 9:04 p.m., don fisher wrote:

...

I have received some hardware and wanted to try the same experiment. But when I go to the above site the kernel offered is kernel-default-devel-4.18.0-5.1.g280ac93.x86_64.rpm, not the 4.17.12 suggested above. I looked and did not see how to get to a list offering previous kernels including 4.17.12. Any ideas?

Well Don't Do That! This going directly to the repositories is wrong headed. They are not supposed to be used like that. You are supposed to add (not by editing manually, but by using 'zypper addrepo')the repository to your collection in /etc/zypper/repos.d/ They are then managed by zypper or Yast. This back to making sure that things are managed via the RPM database so the system knows what state it is in. STOP SCREWING AROUND WITH THAT. Please stop doing things like this. Set up your repositories properly using zypper or Yast and download the latest/updates using zypper or Yast. (I'm biased; I like to see what's going on, have control over it in a way that GUIs won't let you, and zypper lets me do that. In the limiting case I can zypper with a couple of 'verbose', point it at different .repo files and more. (More than just controlling the horizontal and the vertical :-) ) As for the choice, I use http://download.opensuse.org/repositories/Kernel:/stable/standard/ and I'm running # uname -r 4.18.0-1.g6e2c3e0-default on # cat /etc/os-release NAME="openSUSE Leap" VERSION="42.3" ID=opensuse ID_LIKE="suse" VERSION_ID="42.3" If you are running '15' then you may not have 4.18 yet. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-16 10:29 p.m., don fisher wrote:

I wanted to use the 4.17.2 kernel described as successfully installed previously in this thread. I was asking for a way to get that kernel, either with a new zypper repo, or some zypper command to request the previous kernel using the installed repo described above.

There's an old saying: You Can't Get there from here". Is there a particular reason you want an out of date kernel? Have you reviewed the change-log to see if any of the changes affect the things that matter to you? If they don't then the 18.0 is not different in those regards to the 17.12, or perhaps the changes are in areas (shc as network scehduing or buffer length or things like that) which have nothing to do with your issues. One of the rubrics of Linux is "check the logs". The Kernel_Stable is just that. It is not the Historic_kernels repository. Such may exist but my historic kernels exist in my /boot. # ls -1 /boot/vmlinux-4*-default.gz /boot/vmlinux-4.17.10-3.gf604b8a-default.gz /boot/vmlinux-4.17.11-3.g9155e12-default.gz /boot/vmlinux-4.17.11-4.g6676306-default.gz /boot/vmlinux-4.17.11-5.g6676306-default.gz /boot/vmlinux-4.17.12-2.gef4920c-default.gz /boot/vmlinux-4.17.13-2.g9079348-default.gz /boot/vmlinux-4.17.14-2.gdc49b43-default.gz /boot/vmlinux-4.18.0-1.g6e2c3e0-default.gz I don't know that I could package any of those for your use. You might try looking at the "discontinued" repos such as ftp://ftp5.gwdg.de/pub/opensuse/discontinued/ and you might try looking back though the list archives to where others have asked about now discontinued stuff. Failing that, you could even download the GIT repository and pull a previous release and build it https://en.opensuse.org/openSUSE:Kernel_git personally I think that pursuing those threads is a waste of time and effort. Unless and until you've identified (using the changelog) to see if the changes between 4.17.12 and 4.18 affect what you are concerned with. If it is, for example, fixes to do with meltdown & Sceptre and the latest this week iteration of same, then don't worry about it, just accept it. Oh, and do try: # zypper se -s kernel-default I find the results of that .... hilarious! You find the detail of the changes at https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18-Released and see if any affect you. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Don, please trim your replies. On 2018-08-16 11:23 p.m., don fisher wrote:

...

anges at https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18-Released and see if any affect you.

I tried the 4.18.0-1.g6e2c3e0-default kernel and it failed.

Well that's unhelpful. HOW did it fail? Did it fail to load? Did it fail to start some service or application? Did it fail to let you use some port? Is this a 32-bit machine you are trying with a 64-bit kernel?

But the 4.4.140-62-default, part of the 42.3 distribution, runs perfectly.

And what constitutes 'perfectly'? Do all your ports work perfectly?

I wanted to start there and install later kernels until I see the failure and isolate the problem that I am experiencing. As I mentioned, there are some things I do not understand about this laptop's hardware. And with a 13" screen it is hard for me to see details in a dump.

There are plenty of ways to dig into the hardware starting with the simple "ls*' family: lsb-release lscpu lsipc lsmod lspci lsusb lsdev lslocks lsns lsattr lsblk lsinitrd lslogins lsof lsscsi Using the kernel boot options 'splash=verbose showopts' -- and yes this all documented -- some specific like this https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.start... and some more comprehensive: https://doc.opensuse.org/ /...../Documentation/kernel-parameters.txt ... will let you see what is going on as you boot. If this goes by too fast, then you should turn to, of course, the logs, and/or make use of the 'dmesg' command. I would also advise enabling journald for the last 500M of permanent store. Again this is documented, start with the man page. As for you 13" screen: I resume you have a TTY or video port? You can plug in another screen and have the boot messages appear there; it's just a kernel boot time command line parameter. I think it is "console=" but I've never had to use it. perhaps others here can advise. Press 'e' to be able to edit the GRUB and add it. https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.start... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 17/08/18 11:51, Anton Aylward wrote:

On 2018-08-16 9:04 p.m., don fisher wrote:

...

I have received some hardware and wanted to try the same experiment. But when I go to the above site the kernel offered is kernel-default-devel-4.18.0-5.1.g280ac93.x86_64.rpm, not the 4.17.12 suggested above. I looked and did not see how to get to a list offering previous kernels including 4.17.12. Any ideas? Well Don't Do That!

This going directly to the repositories is wrong headed. They are not supposed to be used like that.

You are supposed to add (not by editing manually, but by using 'zypper addrepo')the repository to your collection in /etc/zypper/repos.d/ They are then managed by zypper or Yast.

This back to making sure that things are managed via the RPM database so the system knows what state it is in. STOP SCREWING AROUND WITH THAT.

Please stop doing things like this. Set up your repositories properly using zypper or Yast and download the latest/updates using zypper or Yast.

(I'm biased; I like to see what's going on, have control over it in a way that GUIs won't let you, and zypper lets me do that. In the limiting case I can zypper with a couple of 'verbose', point it at different .repo files and more. (More than just controlling the horizontal and the vertical :-) )

As for the choice, I use http://download.opensuse.org/repositories/Kernel:/stable/standard/ and I'm running # uname -r 4.18.0-1.g6e2c3e0-default on # cat /etc/os-release NAME="openSUSE Leap" VERSION="42.3" ID=opensuse ID_LIKE="suse" VERSION_ID="42.3"

If you are running '15' then you may not have 4.18 yet.

If you have 'http://download.opensuse.org/repositories/Kernel:/stable/standard/' as one of your repositories then it matters not which version of openSUSE you are using :-). The latest kernel is 4.18.0-5 with which I updated my Leap 15.0 and TW earlier today :-). BC -- There comes a time in the affairs of a man when he has to take the bull by the tail and face the situation. W C Fields -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 17/08/18 22:30, Anton Aylward wrote:

On 2018-08-17 3:22 a.m., Basil Chupin wrote:

...

...

If you are running '15' then you may not have 4.18 yet. If you have 'http://download.opensuse.org/repositories/Kernel:/stable/standard/' as one of your repositories then it matters not which version of openSUSE you are using :-).

The latest kernel is 4.18.0-5 with which I updated my Leap 15.0 and TW earlier today :-). Like I said ... You ONLY have 4.18.0.5 where *I* have 4.18.1.1 which, undoubtedly, you will have shortly.

Both Leap 15 and TW were updated this morning to 4.18.1-1.1. Should have happened yesterday yesterday but I was fighting "a fire" in Leap 15 where suddenly I couldn't login :-). Solved THAT a short while ago.

THAT is the point I was making. We see this more dramatically in other repositories and occasional people complain here when they favourite application isn't compiled for their version of the OS ... yet. It's about 'come back later' and 'dont be so impatient'.

The point I was making is that the kernel in '.../stable/standard/' does not care which version of oS or TW you are running -- the only condition is that your system be a 64-bit system. But if you are running a stock standard version of either oS or TW and are not using the '.../stable/standard' repository then you have to wait for a/the new version of kernel to be made available for the version you are running. BC -- There comes a time in the affairs of a man when he has to take the bull by the tail and face the situation. W C Fields -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-18 6:53 p.m., don fisher wrote:

I downloaded kernel-default-4.8.17-1.1.x86_64.rpm from one of the listed sites yesterday.

"Downloaded" meaning what. Was this a 'zypper up --download-only' or was this a FTP/Wget/Curl? if you are not using zypper then it is too easy to get your system out of sync. I am also suspicious of your attitude towards kernel command line and the use of kernel modules. Personally I consider the use of *parametrized* kernel modules essential to a fully functional system. Your problems seems to be that you want to get to arbitrary kernels for no clear resaon. If you had gone though the change logs, either the ones that come with the packages or reviewed the changes at the kernel GIT site, to identify something changed or removed, and explained same, then we could understand the point you are making. But so much of what you present seems to be arguing from ignornace of the details and antagonism towards other aspects of how Linux kernels work, how the change process works. At another level, you seem to be, and this is a personal observation, enamoured with bleeding edge modern laptop. I'm and advocated of older technology. heck, I've even bought older stuff and replaces the blown capacitors! I've got a chassis with a dead 2-core CPU that is awaiting a 4-core replacement! Laptops are notoriously Linux unfriendly. If you want to learn Linux they are in general and many of the more modern ones, as had been reported here repeatedly, in the category of "Don't start from here". That being said, I have a nice, but rather thick and heavy HP 6000 from 1999, just when they too over Compaq, it runs Linux beautifully. So it needs a new batter, and the screen need a new oscillator card but it is user my desk running 13.2 and MySQL supporting my RoR applications and LDAP for a few other things. You could probably find a PC Chassis and a your local thrift store/GoodWill/SalvationArmy. Mine seem to have them, along with 17" to 19" flat screens that are all never prices over CDN$40. You seem to be cutting yourself up with your bleeding edge laptop. Take a step back from the edge. And like I say, read the logs. And PLEASE, don't just tell us that things fail; detail what you are doing. And if you don't like me being critical about your lack of detail about context and results, then try filing a report at BugZilla and get torn to shreds by people who have to try and fix the 'bugs'. BTDT. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/17/2018 09:10 PM, Basil Chupin wrote:

On 17/08/18 22:30, Anton Aylward wrote:

...

On 2018-08-17 3:22 a.m., Basil Chupin wrote:

...

...

If you are running '15' then you may not have 4.18 yet. If you have 'http://download.opensuse.org/repositories/Kernel:/stable/standard/' as one of your repositories then it matters not which version of openSUSE you are using :-).

The latest kernel is 4.18.0-5 with which I updated my Leap 15.0 and TW earlier today :-). Like I said ... You ONLY have 4.18.0.5 where *I* have 4.18.1.1 which, undoubtedly, you will have shortly.

Both Leap 15 and TW were updated this morning to 4.18.1-1.1. Should have happened yesterday yesterday but I was fighting "a fire" in Leap 15 where suddenly I couldn't login :-). Solved THAT a short while ago.

...

THAT is the point I was making.  We see this more dramatically in other repositories and occasional people complain here when they favourite application isn't compiled for their version of the OS ... yet. It's about 'come back later' and 'dont be so impatient'.

The point I was making is that the kernel in '.../stable/standard/' does not care which version of oS or TW you are running -- the only condition is that your system be a 64-bit system.

But if you are running a stock standard version of either oS or TW and are not using the '.../stable/standard' repository then you have to wait for a/the new version of kernel to be made available for the version you are running.

BC

I am coming close to giving up. I just tried to boot the 4.4.143-65-default kernel offered by zypper up yesterday. Works fine on my regular machines, hangs at loading the ramdisk on the new laptop. Never had to debug this before. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/18/2018 05:38 PM, Anton Aylward wrote:

On 2018-08-18 7:55 p.m., don fisher wrote:

...

I just tried to boot the 4.4.143-65-default kernel offered by zypper up yesterday. Works fine on my regular machines, hangs at loading the ramdisk on the new laptop.

More and more and more it seem that your problems focus on your this new laptop. As I said, I'm not surprised that a new, bleeding edge, laptop gives problems. It may be this specific item, it may be the model.

This list has mentioned in the past many laptops that are problematic and others that seem to run Linux well. You may want to trade this in for an older, much older, model, if having a Linux laptop is important to you.

I mentioned I was about to give up. Looking on Google, the first reference I see to this model laptop is Nov 1, 2016. More than a year and a half ago, so I did not consider it bleeding edge. I will continue to poke around until I get angry enough to throw it. You mention reading logs. It was a lot easier when /var/log/messages existed, and the dns-resolver wasn't polluting the world with silly resolve.conf error messages. One would be fine, but hundreds serve no purpose as far as I know. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-18 9:03 p.m., don fisher wrote:

You mention reading logs. It was a lot easier when /var/log/messages existed, and the dns-resolver wasn't polluting the world with silly resolve.conf error messages. One would be fine, but hundreds serve no purpose as far as I know.

Yes, but logs of what? At the time I was talking about logs to the changes in the kernel, and you won't find those in /var/log! I've also mentioned the boot-time logs using the 'dmesg' utility. The new systemd logger is much better than the the old logging system on a number of counts. You need to understand that what went into /var/log/messages. or other files in /var/log. had more to do with finely tuned config file, perhaps /etc/rsyslog.conf. And THAT is highly configurable and programmable and filterable. Of you want all the DNS not to be there than configure it as such. But it is "yes it used to be but we changed all that". Logging is now part of the systemd suite: systemd-journald (8) - Journal service Do not that you have a LOT of control over what gets journalled, how much etc. And since it is a database rather than a text file is it FFFAST Rather than wade though the file, it is searchable with systemd-journalctl, and a very comprehensive set of filters and controls. It is more powerful and more flexible than the old 'syslog' based logging. If you insist, and it will slow your system down, you can pipleline the journal process into rsyslog. Detail are on-line. But that wasn't the log I was talking about; I was talking about the change logs between the version of the kernel. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-18 9:36 p.m., Carlos E. R. wrote:

Not really, it doesn't slow down things.

IMNSHO a additional slug that translated the journal format to logger format then writes to a *text* file as well is going to slow things down compared to it not being there. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-19 03:03, don fisher wrote:

On 08/18/2018 05:38 PM, Anton Aylward wrote:

I mentioned I was about to give up. Looking on Google, the first reference I see to this model laptop is Nov 1, 2016. More than a year and a half ago, so I did not consider it bleeding edge. I will continue to poke around until I get angry enough to throw it.

Did you google if this machine works well with Linux? Did you say it works well with 42.3, but not with 15.0? Then the thing would be to report in bugzilla, a regression.

You mention reading logs. It was a lot easier when /var/log/messages existed,

Just install rsyslog and you have it back. But you can get a very similar result from journalctl as it is.

and the dns-resolver wasn't polluting the world with silly resolve.conf error messages. One would be fine, but hundreds serve no purpose as far as I know.

There are tricks to silence that. I don't remember this instant, though. Hundreds? That's strange. [searching] One idea I read about is deleting /etc/resolv.conf, and then running "rcnetwork restart" which should recreate it again. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 2018-08-18 9:03 p.m., don fisher wrote:

and the dns-resolver wasn't polluting the world with silly resolve.conf error messages. One would be fine, but hundreds serve no purpose as far as I know.

That too depends on - the DNS resolver you use. I use dnsmasq which is very configurable - how you have it configured if yo just accept that is handed to you by your ISPs DHCP resolution you might have little to no control and that may be the reason for your deluge of errors - how you have the filtering with your system logging set up. Both message acceptance and the result display back to RTFM The point I m,m Patrick, Carlo and Basic are all trying to make is a) you have a lot of choices in how your system is set up b) each choice is very configurable But you have to put the effort in into learning about those choices and making them and doing the configuration, rather than just bitching about an out-of-the-box not working. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-19 9:36 a.m., Carlos E. R. wrote:

On 2018-08-19 14:28, Anton Aylward wrote:

...

On 2018-08-18 9:03 p.m., don fisher wrote:

...

and the dns-resolver wasn't polluting the world with silly resolve.conf error messages. One would be fine, but hundreds serve no purpose as far as I know.

That too depends on - the DNS resolver you use.

Nonono.

He refers to a message on the log saying that the file has been altered and not doing something with it.

Yes, there are a HUGE number of possible messages a DNS server COULD send! Lame server, network problems, I also mentioned the ISP/DHCP connection. Most ISPs that use DHCP use the protocol to include a set of DNS addresses, and unless you take extraordinary configuration measures to strap down your /etc/resolv.conf by one means or another, every time the DHCP reconnects it reloads that. I can't recall what the measures are, but mine is to have a model/switch that talks to the USP and my PC is plugged into that switch and uses DNSMasq and has a local address. This was a result of advice I was given here. On bad days, maintenance days, stormy days and very, very wet days and the like, my cable service become ... difficult and I can expect poor signals and dropped connections and restarts. I'm sure that the cable modem is given a hole new set of the same old same old DNS values on the DHCP exchange every time, but so what? I have messaging for that turned off at the cable modem. I'm sure its there in the cable modem's log, but that never bothers my system. The DNS values I use are configured in the /etc/dnsmasq.conf file. But wait! Using DNSMasq is the way the basic system gets installed, is it? You have to actually go to deliberate lengths to configure it and make the system use it, and you need to research a good set of reliable public DNS server to put in the config file. I'm sure there are other ways to achieve this end. I'm sure that you can configure the /etc/rsyslog.conf to do flood-limiting for the DNS messages. rate limiting started with rsyslog 5.7.1 back in what, 2010. There's been a lot written on it of you google. You need to install or activate rsyslog's 'imjournal' module then add to the config file something like: $ModLoad imjournal $imjournalRatelimitInterval 600 $imjournalRatelimitBurst 20000 And of course it is a lot easier with systemd-journald. By default it allows 1,000 messages within a 30 second period. The limits are controlled in the /etc/systemd/journald.conf file. For example, that default is written as: RateLimitInterval=30s RateLimitBurst=1000 but you can change that. See journald.conf(5) for details. So: the message I want to get across is a) Linux is configurable but you need to make the effort b) Methods, man pages, examples are all out there. But you need to make the effort to google for them and read them -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Op zondag 19 augustus 2018 22:07:55 CEST schreef Carlos E. R.:

On 2018-08-19 18:04, Anton Aylward wrote:

...

On 2018-08-19 9:36 a.m., Carlos E. R. wrote:

...

On 2018-08-19 14:28, Anton Aylward wrote:

...

On 2018-08-18 9:03 p.m., don fisher wrote:

...

and the dns-resolver wasn't polluting the world with silly resolve.conf error messages. One would be fine, but hundreds serve no purpose as far as I know.>>> That too depends on

- the DNS resolver you use.

Nonono.

He refers to a message on the log saying that the file has been altered and not doing something with it.

Yes, there are a HUGE number of possible messages a DNS server COULD send! Lame server, network problems,

I also mentioned the ISP/DHCP connection.

Again, no. This is an old bug in yast or network manager or wicked.

Something akin to "you have modified resolve.conf, leaving it alone".

Here, let me search for it... got them:

Aug 19 21:58:40 Legolas.valinor dns-resolver[19379]: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... Aug 19 21:58:40 Legolas.valinor dns-resolver[19381]: You can find my version in /etc/resolv.conf.netconfig Aug 19 21:58:40 Legolas.valinor NetworkManager[1252]: <13>Aug 19 21:58:40 dns-resolver: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... Aug 19 21:58:40 Legolas.valinor NetworkManager[1252]: <13>Aug 19 21:58:40 dns-resolver: You can find my version in /etc/resolv.conf.netconfig Aug 19 21:58:40 Legolas.valinor NetworkManager[1252]: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... Aug 19 21:58:40 Legolas.valinor NetworkManager[1252]: You can find my version in /etc/resolv.conf.netconfig ... Aug 19 21:58:49 Legolas.valinor dns-resolver[19600]: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... Aug 19 21:58:49 Legolas.valinor dns-resolver[19602]: You can find my version in /etc/resolv.conf.netconfig Aug 19 21:58:50 Legolas.valinor NetworkManager[1252]: <13>Aug 19 21:58:49 dns-resolver: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... Aug 19 21:58:50 Legolas.valinor NetworkManager[1252]: <13>Aug 19 21:58:49 dns-resolver: You can find my version in /etc/resolv.conf.netconfig Aug 19 21:58:50 Legolas.valinor NetworkManager[1252]: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... Aug 19 21:58:50 Legolas.valinor NetworkManager[1252]: You can find my version in /etc/resolv.conf.netconfig ... Aug 19 22:00:01 Legolas.valinor nscd[19774]: 19774 monitoring file `/etc/resolv.conf` (5)

The file "etc/resolv.conf.netconfig" contains this comment:

### Please remove (at least) this line when you modify the file!

Well, I did, and the logs still keep complaining, and as you can see, many times. 62 times in two days, to be exact. It could be understandable to say it once per session. But you can see it is three full times in 10 mere seconds. From /etc/resolv.conf:

# 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! -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-17 03:04, don fisher wrote:

On 08/04/2018 11:05 PM, David C. Rankin wrote:

...

On 08/04/2018 10:43 PM, don fisher wrote:

...

   I checked and stable is 4.17.12 -- so if your hardware is supported by the latest kernel -- you will be in luck. Good luck.

I have received some hardware and wanted to try the same experiment. But when I go to the above site the kernel offered is kernel-default-devel-4.18.0-5.1.g280ac93.x86_64.rpm, not the 4.17.12 suggested above. I looked and did not see how to get to a list offering previous kernels including 4.17.12. Any ideas?

Gone. That repository moves fast. Between the time he looked and the time you looked, it changed. It is ok to _look_ at the repository using a web browser, but to install things use zypper or yast after adding the repo. Seeing that it moves that fast, I would clone the repo to a directory of my own and use that instead.

Also, I noticed while searching through directories, that directories are offered in two forms: stable/ stable:/ How does one interpret the difference between directory names with and without the colon?

Good question to which I have no answer :-( -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

* Rodney Baker [08-05-18 09:55]:

On Sunday, 5 August 2018 22:45:40 ACST Knurpht-openSUSE wrote:

...

[...]

...

How dangerous is it to download on of the kernels from the Opensuse search site. Kernel.org says the latest stable release is 4.17.12. Under search/42.3/community packages, there are a few offerings shown at this revision level. How bad is it to install one of these kernels?

Don

Yes, you can install a newer kernel. From the Kernel repo. But .... that will mean you have to manually install the NVIDIA blob, and that you have to install the kernel development packages, i.e. NVIDIA, the hard way. To be able to test the 4.17 kernel, you can download a TW live iso, create a USB stick from it, boot it and see if the NICs work.

Whilst that is true, there is nothing difficult about installing the NVIDIA proprietary drivers manually - you just need to do it before the X server starts, so boot into single user mode, run the installer and reboot once completed.

it is even easier than that. the reboot after installing the nv driver in single user mode is not necessary, just "systemctl isolate graphical" and you will be given the graphical logon screen requesting your password (or not).

Gertjan is correct - you need the kernel dev packages because the installer builds the modules from source.

If you set up dkms (not officially supported on openSuSE, afaik), you can avoid needing to manually reinstall the kernel drivers each kernel update, but KDE/X11 updates often overwrite other necessary files, breaking some functionality (corrected by re-installing the driver after such updates).

I have simply gotten into the habit of reinstalling the driver each time I do a Tumbleweed "zypper dup", although sometimes it isn't necessary.

I also add the nvidia modules to initrd using dracut, so they're loaded early and I can get nice, hi-res text consoles (vty0-7) as well.

BTW, I've just updated to 4.17.12 and, so far, no problems on my machine.

tw here, kernel-default-4.17.11-1.3.x86_64 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Knurpht-openSUSE [08-05-18 12:02]:

Op zondag 5 augustus 2018 17:48:25 CEST schreef Patrick Shanahan:

...

* Rodney Baker [08-05-18 09:55]:

...

On Sunday, 5 August 2018 22:45:40 ACST Knurpht-openSUSE wrote:

...

[...]

...

How dangerous is it to download on of the kernels from the Opensuse search site. Kernel.org says the latest stable release is 4.17.12. Under search/42.3/community packages, there are a few offerings shown at this revision level. How bad is it to install one of these kernels?

Don

Yes, you can install a newer kernel. From the Kernel repo. But .... that will mean you have to manually install the NVIDIA blob, and that you have to install the kernel development packages, i.e. NVIDIA, the hard way. To be able to test the 4.17 kernel, you can download a TW live iso, create a USB stick from it, boot it and see if the NICs work.

Whilst that is true, there is nothing difficult about installing the NVIDIA proprietary drivers manually - you just need to do it before the X server starts, so boot into single user mode, run the installer and reboot once completed.

it is even easier than that. the reboot after installing the nv driver in single user mode is not necessary, just "systemctl isolate graphical" and you will be given the graphical logon screen requesting your password (or not).

it's even easier than that: You can install the blob with a running desktop, using the options --no-x-check --no-nouveau-check Those can be used without issue, since the actual changes to the system only come to effect after a reboot.

this does not work for me on tw, ERROR: An NVIDIA kernel module 'nvidia-uvm' appears to already be loaded in your kernel. .... tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-19 22:31, Knurpht-openSUSE wrote:

Op zondag 5 augustus 2018 05:43:27 CEST schreef don fisher:

...

I have read discussions concerning the wisdom of Opensuse not running current kernels. But I recently purchased an Alienware 13 3 that is near EOL, so it is not real bleeding edge technology. Neither the wireless nor Ethernet are supported, and now I find the the graphics chipset is not supported either. I was able to use a USB wireless transmitter, but I cannot get around the display hardware.

message about wireless in dmesg is: ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2

Qualcomm Atheros Killer E2500 Gigabit Ethernet Controller is not configurable, except with a patch into the /sys directory found on the internet.

Message about the graphics chipset from the Nouveau list is:

"GP106 is supported, you must be using an older kernel (since yours says "unknown chipset")".

How dangerous is it to download on of the kernels from the Opensuse search site. Kernel.org says the latest stable release is 4.17.12. Under search/42.3/community packages, there are a few offerings shown at this revision level. How bad is it to install one of these kernels?

Don This reply is #90 in this thread. Do we still consider the thread as support, or informative? Not me FWIW.

His problem is not yet solved. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 08/19/2018 01:45 PM, Knurpht-openSUSE wrote:

...

On 2018-08-19 22:31, Knurpht-openSUSE wrote: His problem is not yet solved. And it never will as long as Don keeps coming with things 'found on the internet', like 'a patch in /sys' ( which is regenerated at boot ), without

Op zondag 19 augustus 2018 22:33:27 CEST schreef Carlos E. R.: providing links we can check. As long as he doesn't provide proper info, everything is just shooting in the dark, and this gets even worse since we do not know what's being done and undone.

I am often criticized for making my posts too long, by people that are evidently charged by message length. This thread now contains 94 messages, some not really related to the problem that I am trying to solve. The link you referenced offering a solution to the E2500 card problem, was offers on Ubuntu forums, https://ubuntuforums.org/showthread.php?t=2350778. And as you suggested, the commands have to be applied on each reboot. I do not know where it comes from, just that it works. And I am often told that I am lazy and should search Google for solutions. There have been many problems with this Alienware a13 3 computer, so I am going in multiple directions at once. I do not know why the leap 42.3 installation DVD works fine, but the Leap 15 stalls examining USB devices. This DVD worked fine on my other Alienware computers, so I do not believe it is faulty. There was no firmware support for the Qualcomm Atheros QCA6174 wlan adapter, so I replaced the hardware with an Intel 8260 IEEE 802.11ac - Wi-Fi Adapter. The Qualcomm Atheros Killer E2500 Gigabit Ethernet Controller does not work and the message you referenced was my temporary fix. I an currently concerned about the nouveau support for the NVIDIA GP106M [GeForce GTX 1060 Mobile]. I see the driver nouveau listed in the brief crash dumps left on my screen. I miss the option of writing the complete boot output to the printer port, if any existed. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-08-19 at 14:33 -0700, don fisher wrote:

On 08/19/2018 01:45 PM, Knurpht-openSUSE wrote:

...

...

On 2018-08-19 22:31, Knurpht-openSUSE wrote: His problem is not yet solved. And it never will as long as Don keeps coming with things 'found on the internet', like 'a patch in /sys' ( which is regenerated at boot ), without

Op zondag 19 augustus 2018 22:33:27 CEST schreef Carlos E. R.: providing links we can check. As long as he doesn't provide proper info, everything is just shooting in the dark, and this gets even worse since we do not know what's being done and undone.

I am often criticized for making my posts too long, by people that are evidently charged by message length. This thread now contains 94 messages, some not really related to the problem that I am trying to solve.

The link you referenced offering a solution to the E2500 card problem, was offers on Ubuntu forums, https://ubuntuforums.org/showthread.php?t=2350778. And as you suggested, the commands have to be applied on each reboot. I do not know where it comes from, just that it works. And I am often told that I am lazy and should search Google for solutions.

If this hack works for you, it is possible to apply them on every boot automatically. In the directory "/etc/init.d" create one of these scripts, or edit if it exist: after.local Runs after runlevel is complete. Right, I know "runlevels" do not exist with systemd. Fine, "target". boot.local This one runs at the very first possible, before evaluating targets, I believe. I verified it does run in 42.3. halt.local Not in your case. Or, create a systemd service in /etc/systemd/system. How early do you want it to run?

There have been many problems with this Alienware a13 3 computer, so I am going in multiple directions at once. I do not know why the leap 42.3 installation DVD works fine, but the Leap 15 stalls examining USB devices. This DVD worked fine on my other Alienware computers, so I do not believe it is faulty.

Nevertheless, test it, because they can degrade. On boot, select the option to verify instead of installation. You should report this issue in Bugzilla.

There was no firmware support for the Qualcomm Atheros QCA6174 wlan adapter, so I replaced the hardware with an Intel 8260 IEEE 802.11ac - Wi-Fi Adapter. The Qualcomm Atheros Killer E2500 Gigabit Ethernet Controller does not work and the message you referenced was my temporary fix.

I an currently concerned about the nouveau support for the NVIDIA GP106M [GeForce GTX 1060 Mobile]. I see the driver nouveau listed in the brief crash dumps left on my screen. I miss the option of writing the complete boot output to the printer port, if any existed.

Crumbs. Does it have Nvidia AND Intel video? They are problematic. Daniel Bauer also has deep problems with his. It is possible to dump kernel log entries via network, if the network card is working. I think there is another procedure to dump via usb. Maybe devs could develop a method to dump boot messages to a raw disk partition. No filesystem support needed. Dangerous if the wrong partition is chosen. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlt5840ACgkQtTMYHG2NR9WiTACfSS2qKDR8LhcSo9qZy/ip7dal zb0AoIqyKajMHuR4uAuLOQhFTrz5C0x5 =998A -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-20 02:55, Knurpht-openSUSE wrote:

Op maandag 20 augustus 2018 00:47:26 CEST schreef Carlos E. R.:

...

On Sunday, 2018-08-19 at 14:33 -0700, don fisher wrote:

...

On 08/19/2018 01:45 PM, Knurpht-openSUSE wrote:

...

Op zondag 19 augustus 2018 22:33:27 CEST schreef Carlos E. R.:

...

On 2018-08-19 22:31, Knurpht-openSUSE wrote: His problem is not yet solved.

And it never will as long as Don keeps coming with things 'found on the internet', like 'a patch in /sys' ( which is regenerated at boot ), without providing links we can check. As long as he doesn't provide proper info, everything is just shooting in the dark, and this gets even worse since we do not know what's being done and undone.

I am often criticized for making my posts too long, by people that are evidently charged by message length. This thread now contains 94 messages, some not really related to the problem that I am trying to solve.

The link you referenced offering a solution to the E2500 card problem, was offers on Ubuntu forums, https://ubuntuforums.org/showthread.php?t=2350778. And as you suggested, the commands have to be applied on each reboot. I do not know where it comes from, just that it works. And I am often told that I am lazy and should search Google for solutions.

If this hack works for you, it is possible to apply them on every boot automatically.

In the directory "/etc/init.d" create one of these scripts, or edit if it exist:

after.local

Runs after runlevel is complete. Right, I know "runlevels" do not exist with systemd. Fine, "target".

Carlos, don't you agree this is bringing Don further and further away from a default install? With the knowledge displayed so far, IMNSHO that's maybe working around some issues, but not really solving his issues.

I understand that the default install doesn't work for him. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 2018-08-21 04:50, Basil Chupin wrote:

On 20/08/18 08:47, Carlos E. R. wrote:

...

On Sunday, 2018-08-19 at 14:33 -0700, don fisher wrote:

...

On 08/19/2018 01:45 PM, Knurpht-openSUSE wrote:

...

...

 On 2018-08-19 22:31, Knurpht-openSUSE wrote:  His problem is not yet solved.  And it never will as long as Don keeps coming with things 'found on

 Op zondag 19 augustus 2018 22:33:27 CEST schreef Carlos E. R.: the  internet', like 'a patch in /sys' ( which is regenerated at boot ),  without  providing links we can check. As long as he doesn't provide proper info,  everything is just shooting in the dark, and this gets even worse since we  do  not know what's being done and undone.

I am often criticized for making my posts too long, by people that are evidently charged by message length. This thread now contains 94 messages, some not really related to the problem that I am trying to solve.

The link you referenced offering a solution to the E2500 card problem, was offers on Ubuntu forums, https://ubuntuforums.org/showthread.php?t=2350778. And as you suggested, the commands have to be applied on each reboot. I do not know where it comes from, just that it works. And I am often told that I am lazy and should search Google for solutions.

If this hack works for you, it is possible to apply them on every boot automatically.

In the directory "/etc/init.d" create one of these scripts, or edit if it exist:

after.local

Runs after runlevel is complete. Right, I know "runlevels" do not exist with systemd. Fine, "target".

Carlos, I cannot follow what your cryptic instructions are all about so how is Don supposed to understand them?

Why not simply create the file you are talking about and post a copy of it here or on susepaste so that all he has to do is to copy it into his system?

I don't see it cryptic at all. I can not write the file because I don't know what he wants to run and when exactly. Heck, those are plan bash script files. Can't you write a simple script from scratch? I could since day two I installed my first Linux: #!/bin/bash /run/this/path/program parameters Is it that difficult?

...

...

There have been many problems with this Alienware a13 3 computer, so I am going in multiple directions at once. I do not know why the leap 42.3 installation DVD works fine, but the Leap 15 stalls examining USB devices. This DVD worked fine on my other Alienware computers, so I do not believe it is faulty.

Nevertheless, test it, because they can degrade. On boot, select the option to verify instead of installation.

You should report this issue in Bugzilla.

I can bet my most valuable parts of my body that Don will respond with, "What is a "Bugzilla? What do I spray on it to kill it?" :-)

Then ask and I will search for the link with instructions. Google: "opensuse: how to write a bugzilla" First entry: openSUSE:Submitting bug reports - openSUSE https://en.opensuse.org/openSUSE:Submitting_bug_reports Done. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 20/08/18 06:31, Knurpht-openSUSE wrote:

Op zondag 5 augustus 2018 05:43:27 CEST schreef don fisher:

...

I have read discussions concerning the wisdom of Opensuse not running current kernels. But I recently purchased an Alienware 13 3 that is near EOL, so it is not real bleeding edge technology. Neither the wireless nor Ethernet are supported, and now I find the the graphics chipset is not supported either. I was able to use a USB wireless transmitter, but I cannot get around the display hardware.

message about wireless in dmesg is: ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2

Qualcomm Atheros Killer E2500 Gigabit Ethernet Controller is not configurable, except with a patch into the /sys directory found on the internet.

Message about the graphics chipset from the Nouveau list is:

"GP106 is supported, you must be using an older kernel (since yours says "unknown chipset")".

How dangerous is it to download on of the kernels from the Opensuse search site. Kernel.org says the latest stable release is 4.17.12. Under search/42.3/community packages, there are a few offerings shown at this revision level. How bad is it to install one of these kernels?

Don This reply is #90 in this thread. Do we still consider the thread as support, or informative? Not me FWIW.

Number 92 actually. Apart from your post and my response, I think the thread is informative as we are all interested in giving support to Don in his quest to learn more about the intricacies of a Linux system. BC -- There comes a time in the affairs of a man when he has to take the bull by the tail and face the situation. W C Fields -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

don fisher composed on 2018-08-19 19:47 (UTC-0700):

...I was able to boot the Leap 15 installation DVD if I selected F5 and Safe Settings. I now need to find out exactly what this sets...

On vtty2: # cat /proc/cmdline apm=off acpi=off mce=off barrier=off ide=nodma idewait=50 i8042.nomux psmouse.proto=bare irqpoll pci=nommconf initrd=initrd splash=silent systemboot=1 -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2018 08:19 PM, Felix Miata wrote:

don fisher composed on 2018-08-19 19:47 (UTC-0700):

...

...I was able to boot the Leap 15 installation DVD if I selected F5 and Safe Settings. I now need to find out exactly what this sets...

On vtty2: # cat /proc/cmdline apm=off acpi=off mce=off barrier=off ide=nodma idewait=50 i8042.nomux psmouse.proto=bare irqpoll pci=nommconf initrd=initrd splash=silent systemboot=1

Will you please explain what you were running when you entered vtty2? Thanks Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2018 09:16 PM, Felix Miata wrote:

don fisher composed on 2018-08-19 20:54 (UTC-0700):

...

Felix Miata wrote:

...

...

don fisher composed on 2018-08-19 19:47 (UTC-0700):

...

...

...

...I was able to boot the Leap 15 installation DVD if I selected F5 and Safe Settings. I now need to find out exactly what this sets...

...

...

On vtty2: # cat /proc/cmdline apm=off acpi=off mce=off barrier=off ide=nodma idewait=50 i8042.nomux psmouse.proto=bare irqpoll pci=nommconf initrd=initrd splash=silent systemboot=1

...

Will you please explain what you were running when you entered vtty2?

Boot installation media F5 Select safe settings Wait for installation GUI to paint the screen Ctrl-Alt-F2 # cat /proc/cmdline

Thanks. I thought so, but I thought I was the only one left using DVD install media:-) Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2018 09:16 PM, Felix Miata wrote:

don fisher composed on 2018-08-19 20:54 (UTC-0700):

...

Felix Miata wrote:

...

...

don fisher composed on 2018-08-19 19:47 (UTC-0700):

...

...

...

...I was able to boot the Leap 15 installation DVD if I selected F5 and Safe Settings. I now need to find out exactly what this sets...

...

...

On vtty2: # cat /proc/cmdline apm=off acpi=off mce=off barrier=off ide=nodma idewait=50 i8042.nomux psmouse.proto=bare irqpoll pci=nommconf initrd=initrd splash=silent systemboot=1

...

Will you please explain what you were running when you entered vtty2?

Boot installation media F5 Select safe settings Wait for installation GUI to paint the screen Ctrl-Alt-F2 # cat /proc/cmdline

I experimented with the above "Safe Settings" and found that the only one that is required is acpi=off. And with thatthe system boots, but xosview only shows 3 cpus rather that the usual 7. Could the hyperthreading (if that is what they still call it) be disabled with lack of acpi? I tried the following options listed in kernel-parameters.txt, acpi=noirq, acpi=strict, and acpi=rsdt but none were successful. There are 26 more acpi related commands listed indicating a complex subsystem, but I do not know enough currently to experiment further. Ideas welcome. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2018-08-21 03:14, don fisher wrote:

On 08/20/2018 06:11 PM, don fisher wrote:

...

On 08/19/2018 09:16 PM, Felix Miata wrote:

...

don fisher composed on 2018-08-19 20:54 (UTC-0700):

...

...

...

Boot installation media F5 Select safe settings Wait for installation GUI to paint the screen Ctrl-Alt-F2 # cat /proc/cmdline

I experimented with the above "Safe Settings" and found that the only one that is required is acpi=off. And with thatthe system boots, but xosview only shows 3 cpus rather that the usual 7. Could the hyperthreading (if that is what they still call it) be disabled with lack of acpi? I tried the following options listed in kernel-parameters.txt, acpi=noirq, acpi=strict, and acpi=rsdt but none were successful. There are 26 more acpi related commands listed indicating a complex subsystem, but I do not know enough currently to experiment further.

Well, that is interesting.

...

Ideas welcome.

Bugzilla.

...

Don

I am tired. I meant 4 cpus rather than the usual 8. Sorry.

-- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 08/20/2018 08:01 PM, Basil Chupin wrote:

On 20/08/18 12:47, don fisher wrote:

...

One success:-) I was able to boot the Leap 15 installation DVD if I selected F5 and Safe Settings. I now need to find out exactly what this sets so I can try these settings on the other kernels I have had problems with. And maybe isolate what hardware appears inconsistent.

Don

<quote>

F5Kernel

    If you encounter problems with the regular installation, this menu offers to disable a few potentially problematic functions. If your hardware does not support ACPI (advanced configuration and power interface) select No ACPI to install without ACPI support. No local APIC disables support for APIC (Advanced Programmable Interrupt Controllers) which may cause problems with some hardware. Safe Settings boots the system with the DMA mode (for CD/DVD-ROM drives) and power management functions disabled.

    If you are not sure, try the following options first: Installation—ACPI Disabled or Installation—Safe Settings. Experts can also use the command line (Boot Options) to enter or change kernel parameters.

...

/quote>

https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.start...

Did you read my last post? I tried all of the suggested parameters and isolated the problem to acpi=off. I am a bit tired now and am not sure how to proceed from here. In the old days I would have built a kernel and run it under gdb. I assume one can still do that, but have not checked. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/20/2018 08:48 PM, Basil Chupin wrote:

On 21/08/18 13:20, don fisher wrote:

...

On 08/20/2018 08:01 PM, Basil Chupin wrote:

...

On 20/08/18 12:47, don fisher wrote:

...

One success:-) I was able to boot the Leap 15 installation DVD if I selected F5 and Safe Settings. I now need to find out exactly what this sets so I can try these settings on the other kernels I have had problems with. And maybe isolate what hardware appears inconsistent.

Don

<quote>

F5Kernel

     If you encounter problems with the regular installation, this menu offers to disable a few potentially problematic functions. If your hardware does not support ACPI (advanced configuration and power interface) select No ACPI to install without ACPI support. No local APIC disables support for APIC (Advanced Programmable Interrupt Controllers) which may cause problems with some hardware. Safe Settings boots the system with the DMA mode (for CD/DVD-ROM drives) and power management functions disabled.

     If you are not sure, try the following options first: Installation—ACPI Disabled or Installation—Safe Settings. Experts can also use the command line (Boot Options) to enter or change kernel parameters.

 >/quote>

https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.start...

Did you read my last post? I tried all of the suggested parameters and isolated the problem to acpi=off.

Yes I did.

...

I am a bit tired now and am not sure how to proceed from here. In the old days I would have built a kernel and run it under gdb. I assume one can still do that, but have not checked.

Alright, so now you can boot the DVD and start the installation process. Therefore, install Leap 15.0 and don't start fooling around with any "building" kernels stuff -- just first install 15.0 and get it running. Worry about new kernels LATER, OK?

Now, a word of advice: that laptop of yours (you haven't confirmed my post asking if it was Alienware 13 R3 as per that Wikipedia page) would have the ability to use UEFI. What I suggest is that you turn that off in the BIOS and install Leap 15.0 in "legacy" mode.

Also, when you reach the installation part where the choice is made which partition will be used to install Leap and where /home will be created and that the file system BTRFS will be used to format the partition CHOOSE THE EXPERT OPTION and make your own choices about formatting etc. For example, I format the "/" partition in ext4 and do not have a separate "/home" somewhere outside the "/". But that is ME -- do whatever you want, just, please, get Leap 15 installed and running so that we can get with on with worrying about new kernels, OK? :-)

Thanks. I guess I wasn't clear enough. I got the DVD to boot using the "Safe Setting" option. I was able to build a Leap 15 system on a USB drive. My effort today was to try to determine why the 4.4.143-65-default and other later kernels fail. The problem I had since the beginning of this thread was trying to get a recent version of the kernel running so that I could experiment with the open source Nvidia driver, nouveau. It will not load on the older kernels, dmesg reports: nouveau: detected PR support, will not use DSM nouveau 0000:01:00.0: enabling device (0006 -> 0007) nouveau 0000:01:00.0: unknown chipset (136000a1) nouveau: probe of 0000:01:00.0 failed with error -12 One of the authors of the nouveau driver stated that the GP106 is supported and since my message was "unknown chipset", a later version of the kernel that is aware of GP106 support may be required. That is what initiated my search for later kernels. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org