[opensuse] using optimus prime on 43.3?
Hi, After solving the problem of loading nvidia drivers thanks to the help on this list, especially Andrei, I open a new thread in the hope that maybe, maybe my nvidia card can be used one day. I have an Asus GL552V laptop, i7 6700, optimus graphics intel/nvidia running opensuse leap 42.3, KDE It now runs the intel graphics only, in a terrible way with lot of flickering. I cannot disable the intel graphics or make the nvidia graphics primary in the BIOS (there are no such options there and I double-double-checked...). I would love to be able to switch between both cards (intel/nvidia) just as it was possible on OpenSuse 13x using suse-prime. If that's not possible, I'd love to have nvidia activated all the time. I don't want bumblebee, as for my work-flow it is not really helpful. I have installed the nvidia drivers from the opensuse nvidia repositiory and they are up and loaded. But running prime-select (installed from the 42.3 repo) something breaks so that I cannot logout from the KDE session nor shutdown with the KDE menu button. As somebody suggested I changed the display manager from sddm to kdm, but that didn't help. How can I goon testing and maybe solve the problem? What and where do I have to look? Thanks for your time and energy and help! Daniel -- Daniel Bauer photographer Basel Málaga https://www.patreon.com/danielbauer http://www.daniel-bauer.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 17/07/2018 à 13:03, Daniel Bauer a écrit :
I would love to be able to switch between both cards (intel/nvidia) just as it was possible on OpenSuse 13x using suse-prime.
may be you could start here, find a suse-prime mailing list or ask the maintainer directly may be it's just a little change that made it break :-( good luck jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jul 17, 2018 at 2:03 PM, Daniel Bauer <linux@daniel-bauer.com> wrote:
Hi,
After solving the problem of loading nvidia drivers thanks to the help on this list, especially Andrei, I open a new thread in the hope that maybe, maybe my nvidia card can be used one day.
I have an Asus GL552V laptop, i7 6700, optimus graphics intel/nvidia running opensuse leap 42.3, KDE
It now runs the intel graphics only, in a terrible way with lot of flickering.
I cannot disable the intel graphics or make the nvidia graphics primary in the BIOS (there are no such options there and I double-double-checked...).
I would love to be able to switch between both cards (intel/nvidia) just as it was possible on OpenSuse 13x using suse-prime.
If that's not possible, I'd love to have nvidia activated all the time.
I don't want bumblebee, as for my work-flow it is not really helpful.
I have installed the nvidia drivers from the opensuse nvidia repositiory and they are up and loaded. But running prime-select (installed from the 42.3 repo) something breaks so that I cannot logout from the KDE session nor shutdown with the KDE menu button.
As somebody suggested I changed the display manager from sddm to kdm, but that didn't help.
How can I goon testing and maybe solve the problem? What and where do I have to look?
The first step is to enable KMS in nvidia-drm. This is documented in nVidia README. You may need to recreate initrd because I think openSUSE adds drivers there (mkinitrd). After rebooting with KMS enabled show lspci -nnk xrandr --listproviders glxinfo | grep vendor as well as Xorg log. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17.07.2018 13:20, Andrei Borzenkov wrote:
On Tue, Jul 17, 2018 at 2:03 PM, Daniel Bauer <linux@daniel-bauer.com> wrote:
Hi,
After solving the problem of loading nvidia drivers thanks to the help on this list, especially Andrei, I open a new thread in the hope that maybe, maybe my nvidia card can be used one day.
I have an Asus GL552V laptop, i7 6700, optimus graphics intel/nvidia running opensuse leap 42.3, KDE
It now runs the intel graphics only, in a terrible way with lot of flickering.
I cannot disable the intel graphics or make the nvidia graphics primary in the BIOS (there are no such options there and I double-double-checked...).
I would love to be able to switch between both cards (intel/nvidia) just as it was possible on OpenSuse 13x using suse-prime.
If that's not possible, I'd love to have nvidia activated all the time.
I don't want bumblebee, as for my work-flow it is not really helpful.
I have installed the nvidia drivers from the opensuse nvidia repositiory and they are up and loaded. But running prime-select (installed from the 42.3 repo) something breaks so that I cannot logout from the KDE session nor shutdown with the KDE menu button.
As somebody suggested I changed the display manager from sddm to kdm, but that didn't help.
How can I goon testing and maybe solve the problem? What and where do I have to look?
The first step is to enable KMS in nvidia-drm. This is documented in nVidia README.
I don't know where to find that readme. Googling brought me to an nvidia page and there I read to enter: modprobe -r nvidia-drm ; modprobe nvidia-drm modeset=1 is it that? one of it, both of it? You may need to recreate initrd because I think
openSUSE adds drivers there (mkinitrd). After rebooting with KMS enabled show
lspci -nnk xrandr --listproviders glxinfo | grep vendor
as well as Xorg log.
-- Daniel Bauer photographer Basel Málaga https://www.patreon.com/danielbauer http://www.daniel-bauer.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Daniel Bauer <linux@daniel-bauer.com> [07-17-18 07:37]:
On 17.07.2018 13:20, Andrei Borzenkov wrote:
[...]
The first step is to enable KMS in nvidia-drm. This is documented in nVidia README.
I don't know where to find that readme. Googling brought me to an nvidia page and there I read to enter:
modprobe -r nvidia-drm ; modprobe nvidia-drm modeset=1
is it that? one of it, both of it?
http://download.nvidia.com/XFree86/Linux-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
On Tue, Jul 17, 2018 at 2:34 PM, Daniel Bauer <linux@daniel-bauer.com> wrote:
On 17.07.2018 13:20, Andrei Borzenkov wrote:
On Tue, Jul 17, 2018 at 2:03 PM, Daniel Bauer <linux@daniel-bauer.com> wrote:
Hi,
After solving the problem of loading nvidia drivers thanks to the help on this list, especially Andrei, I open a new thread in the hope that maybe, maybe my nvidia card can be used one day.
I have an Asus GL552V laptop, i7 6700, optimus graphics intel/nvidia running opensuse leap 42.3, KDE
It now runs the intel graphics only, in a terrible way with lot of flickering.
I cannot disable the intel graphics or make the nvidia graphics primary in the BIOS (there are no such options there and I double-double-checked...).
I would love to be able to switch between both cards (intel/nvidia) just as it was possible on OpenSuse 13x using suse-prime.
If that's not possible, I'd love to have nvidia activated all the time.
I don't want bumblebee, as for my work-flow it is not really helpful.
I have installed the nvidia drivers from the opensuse nvidia repositiory and they are up and loaded. But running prime-select (installed from the 42.3 repo) something breaks so that I cannot logout from the KDE session nor shutdown with the KDE menu button.
As somebody suggested I changed the display manager from sddm to kdm, but that didn't help.
How can I goon testing and maybe solve the problem? What and where do I have to look?
The first step is to enable KMS in nvidia-drm. This is documented in nVidia README.
I don't know where to find that readme. Googling brought me to an nvidia page and there I read to enter:
modprobe -r nvidia-drm ; modprobe nvidia-drm modeset=1
is it that? one of it, both of it?
This enables KMS for current boot. It will be lost after reboot. To enable it permanently you need to create modprobe configuration file. echo options nvidia-drm modeset=1 > /etc/modprobe.d/nvidia-drm.conf mkinitrd reboot
You may need to recreate initrd because I think
openSUSE adds drivers there (mkinitrd). After rebooting with KMS enabled show
lspci -nnk xrandr --listproviders glxinfo | grep vendor
as well as Xorg log.
-- Daniel Bauer photographer Basel Málaga https://www.patreon.com/danielbauer http://www.daniel-bauer.com
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17.07.2018 13:50, Andrei Borzenkov wrote:
On Tue, Jul 17, 2018 at 2:34 PM, Daniel Bauer <linux@daniel-bauer.com> wrote:
On 17.07.2018 13:20, Andrei Borzenkov wrote:
On Tue, Jul 17, 2018 at 2:03 PM, Daniel Bauer <linux@daniel-bauer.com> wrote:
Hi,
After solving the problem of loading nvidia drivers thanks to the help on this list, especially Andrei, I open a new thread in the hope that maybe, maybe my nvidia card can be used one day.
I have an Asus GL552V laptop, i7 6700, optimus graphics intel/nvidia running opensuse leap 42.3, KDE
It now runs the intel graphics only, in a terrible way with lot of flickering.
I cannot disable the intel graphics or make the nvidia graphics primary in the BIOS (there are no such options there and I double-double-checked...).
I would love to be able to switch between both cards (intel/nvidia) just as it was possible on OpenSuse 13x using suse-prime.
If that's not possible, I'd love to have nvidia activated all the time.
I don't want bumblebee, as for my work-flow it is not really helpful.
I have installed the nvidia drivers from the opensuse nvidia repositiory and they are up and loaded. But running prime-select (installed from the 42.3 repo) something breaks so that I cannot logout from the KDE session nor shutdown with the KDE menu button.
As somebody suggested I changed the display manager from sddm to kdm, but that didn't help.
How can I goon testing and maybe solve the problem? What and where do I have to look?
The first step is to enable KMS in nvidia-drm. This is documented in nVidia README.
echo options nvidia-drm modeset=1 > /etc/modprobe.d/nvidia-drm.conf mkinitrd reboot
ok, did that
lspci -nnk xrandr --listproviders glxinfo | grep vendor
https://www.daniel-bauer.com/test/output.txt
as well as Xorg log.
https://www.daniel-bauer.com/test/Xorg.0.log.txt -- Daniel Bauer photographer Basel Málaga https://www.patreon.com/danielbauer http://www.daniel-bauer.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jul 17, 2018 at 3:07 PM, Daniel Bauer <linux@daniel-bauer.com> wrote:
On 17.07.2018 13:50, Andrei Borzenkov wrote:
On Tue, Jul 17, 2018 at 2:34 PM, Daniel Bauer <linux@daniel-bauer.com> wrote:
On 17.07.2018 13:20, Andrei Borzenkov wrote:
On Tue, Jul 17, 2018 at 2:03 PM, Daniel Bauer <linux@daniel-bauer.com> wrote:
Hi,
After solving the problem of loading nvidia drivers thanks to the help on this list, especially Andrei, I open a new thread in the hope that maybe, maybe my nvidia card can be used one day.
I have an Asus GL552V laptop, i7 6700, optimus graphics intel/nvidia running opensuse leap 42.3, KDE
It now runs the intel graphics only, in a terrible way with lot of flickering.
I cannot disable the intel graphics or make the nvidia graphics primary in the BIOS (there are no such options there and I double-double-checked...).
I would love to be able to switch between both cards (intel/nvidia) just as it was possible on OpenSuse 13x using suse-prime.
If that's not possible, I'd love to have nvidia activated all the time.
I don't want bumblebee, as for my work-flow it is not really helpful.
I have installed the nvidia drivers from the opensuse nvidia repositiory and they are up and loaded. But running prime-select (installed from the 42.3 repo) something breaks so that I cannot logout from the KDE session nor shutdown with the KDE menu button.
As somebody suggested I changed the display manager from sddm to kdm, but that didn't help.
How can I goon testing and maybe solve the problem? What and where do I have to look?
The first step is to enable KMS in nvidia-drm. This is documented in nVidia README.
echo options nvidia-drm modeset=1 > /etc/modprobe.d/nvidia-drm.conf mkinitrd reboot
OK, checking your versions it was probably not necessary. It is only required for PRIME synchronization, but it needs Xorg 1.19 anyway.
ok, did that
lspci -nnk xrandr --listproviders glxinfo | grep vendor
https://www.daniel-bauer.com/test/output.txt
as well as Xorg log.
Do you have another system that you can use to log in over LAN? It will greatly simplify things, as otherwise if anything goes wrong with X configuration, you may not be able to access your system. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17.07.2018 14:35, Andrei Borzenkov wrote:
On Tue, Jul 17, 2018 at 3:07 PM, Daniel Bauer <linux@daniel-bauer.com> wrote:
On 17.07.2018 13:50, Andrei Borzenkov wrote:
On Tue, Jul 17, 2018 at 2:34 PM, Daniel Bauer <linux@daniel-bauer.com> wrote:
On 17.07.2018 13:20, Andrei Borzenkov wrote:
On Tue, Jul 17, 2018 at 2:03 PM, Daniel Bauer <linux@daniel-bauer.com> wrote:
Hi,
After solving the problem of loading nvidia drivers thanks to the help on this list, especially Andrei, I open a new thread in the hope that maybe, maybe my nvidia card can be used one day.
I have an Asus GL552V laptop, i7 6700, optimus graphics intel/nvidia running opensuse leap 42.3, KDE
It now runs the intel graphics only, in a terrible way with lot of flickering.
I cannot disable the intel graphics or make the nvidia graphics primary in the BIOS (there are no such options there and I double-double-checked...).
I would love to be able to switch between both cards (intel/nvidia) just as it was possible on OpenSuse 13x using suse-prime.
If that's not possible, I'd love to have nvidia activated all the time.
I don't want bumblebee, as for my work-flow it is not really helpful.
I have installed the nvidia drivers from the opensuse nvidia repositiory and they are up and loaded. But running prime-select (installed from the 42.3 repo) something breaks so that I cannot logout from the KDE session nor shutdown with the KDE menu button.
As somebody suggested I changed the display manager from sddm to kdm, but that didn't help.
How can I goon testing and maybe solve the problem? What and where do I have to look?
The first step is to enable KMS in nvidia-drm. This is documented in nVidia README.
echo options nvidia-drm modeset=1 > /etc/modprobe.d/nvidia-drm.conf mkinitrd reboot
OK, checking your versions it was probably not necessary. It is only required for PRIME synchronization, but it needs Xorg 1.19 anyway.
ok, did that
lspci -nnk xrandr --listproviders glxinfo | grep vendor
https://www.daniel-bauer.com/test/output.txt
as well as Xorg log.
Do you have another system that you can use to log in over LAN? It will greatly simplify things, as otherwise if anything goes wrong with X configuration, you may not be able to access your system.
This is the problem and my great fear... I only have this laptop with me (I am moving around and don't have friends here...) and I /need/ it for work, would be terrible if I could not use it... So I can only try things that will at least allow me to enter in text mode to undo what caused the problem... So I would really ask you to only tell me things that will leave me at least a text login, please :-) -- Daniel Bauer photographer Basel Málaga https://www.patreon.com/danielbauer http://www.daniel-bauer.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 17/07/2018 à 16:12, Daniel Bauer a écrit :
So I can only try things that will at least allow me to enter in text mode to undo what caused the problem...
AFAIK, typing "3" on the kernel line in grub allow text mode jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17.07.2018 16:28, jdd@dodin.org wrote:
Le 17/07/2018 à 16:12, Daniel Bauer a écrit :
So I can only try things that will at least allow me to enter in text mode to undo what caused the problem...
AFAIK, typing "3" on the kernel line in grub allow text mode
jdd
Yes, I use this when the graphical login doesn't work. However Andrei's "if anything goes wrong with X configuration, you may not be able to access your system" makes me fear that even this wouldn't work anymore. As long as I can go to text mode with init 3 I guess everything can be reversed (at least with the help of the list ;-) ) . But if there's a risk to even lose init 3 login I cannot go for that risk... -- Daniel Bauer photographer Basel Málaga https://www.patreon.com/danielbauer http://www.daniel-bauer.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 17/07/2018 à 17:04, Daniel Bauer a écrit :
As long as I can go to text mode with init 3 I guess everything can be reversed (at least with the help of the list ;-) ) .
But if there's a risk to even lose init 3 login I cannot go for that risk...
sure when I can I try to have two installs in the same computer, as backup :-( http://dodin.org/wiki/pmwiki.php?n=Doc.AddXResolution#toc1 I wrote here a (may be incomplete) list of X config files :-(. There are a lot jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd@dodin.org composed on 2018-07-17 17:13 (UTC+0200):
Daniel Bauer composed:
As long as I can go to text mode with init 3 I guess everything can be reversed (at least with the help of the list ;-) ) .
But if there's a risk to even lose init 3 login I cannot go for that risk...
sure
when I can I try to have two installs in the same computer, as backup :-(
Not that it could be of any use to Daniel now, but even though I have many computers but none mobile, this is one reason (of several) every PC of mine that I did any OS installation on is multiboot. Though it is plenty extra work to initialize, and some extra maintenance, it is better overall than fumbling around _at inopportune times_ for diverse rescue media that may or may turn out to be suitable to task at hand, or trying to solve problems that are easy in Xorg but overwhelming without it. -- "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 17.07.2018 20:56, Felix Miata wrote:
jdd@dodin.org composed on 2018-07-17 17:13 (UTC+0200):
Daniel Bauer composed:
As long as I can go to text mode with init 3 I guess everything can be reversed (at least with the help of the list ;-) ) .
But if there's a risk to even lose init 3 login I cannot go for that risk...
sure
when I can I try to have two installs in the same computer, as backup :-(
Not that it could be of any use to Daniel now, but even though I have many computers but none mobile, this is one reason (of several) every PC of mine that I did any OS installation on is multiboot. Though it is plenty extra work to initialize, and some extra maintenance, it is better overall than fumbling around _at inopportune times_ for diverse rescue media that may or may turn out to be suitable to task at hand, or trying to solve problems that are easy in Xorg but overwhelming without it.
This is something I never thought about. I should have done this on my laptop, it sounds very reasonable to me. But well, I haven't. It wasn't so important though. I always had a desktop machine and only updated it /after/ a successful update of the laptop, so I always had one running machine. But now I am "on the road" with only this laptop... -- Daniel Bauer photographer Basel Málaga https://www.patreon.com/danielbauer http://www.daniel-bauer.com -- 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 Tuesday, 2018-07-17 at 21:09 +0200, Daniel Bauer wrote:
On 17.07.2018 20:56, Felix Miata wrote:
jdd@dodin.org composed on 2018-07-17 17:13 (UTC+0200):
sure
when I can I try to have two installs in the same computer, as backup :-(
Not that it could be of any use to Daniel now, but even though I have many computers but none mobile, this is one reason (of several) every PC of mine that I did any OS installation on is multiboot. Though it is plenty extra work to initialize, and some extra maintenance, it is better overall than fumbling around _at inopportune times_ for diverse rescue media that may or may turn out to be suitable to task at hand, or trying to solve problems that are easy in Xorg but overwhelming without it.
This is something I never thought about. I should have done this on my laptop, it sounds very reasonable to me. But well, I haven't.
It wasn't so important though. I always had a desktop machine and only updated it /after/ a successful update of the laptop, so I always had one running machine. But now I am "on the road" with only this laptop...
I almost always create an extra system; it can be a small partition only for testing, like 8 GB. 15 is much better. I didn't on my last install, a small laptop with a small SSD. However, there is an alternative on modern laptops: an external hard disk via USB3. If you only need it for rescue, the openSUSE rescue image on a stick is enough. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAltOTeMACgkQtTMYHG2NR9VTNACgig4PPNYUIvEjmNcJOC9IdxAf mZ4Ani9PKJq51OV77MYUaB6DIMJVU9LD =928l -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. composed on 2018-07-17 22:13 (UTC+0200):
I almost always create an extra system; it can be a small partition only for testing, like 8 GB. 15 is much better.
Maximum size of my test /s is 10, but the vast majority are less than 7200M, mostly 5600M. When multibooting for the primary purpose of testing a beta that is expected to become a replacement main installation, then size of test / is best identical. That allows the test to become the operational via a rather simple cloning operation followed by distribution upgrade when upgrade rather than fresh is desired, without disturbing the existing normal. My test partitions share a single /home/ and single /usr/local/ partition, are installed with recommends disabled, and have installed only one DE besides the default IceWM, so have modest space requirements.
I didn't on my last install, a small laptop with a small SSD. However, there is an alternative on modern laptops: an external hard disk via USB3.
USB is/are a(re) different bus(es), which is/are subject to different device enumeration order and thus different device name assignment. Thus, I never do USB HD boot. I use eSATA when I need to boot from an external HD. That way, the BIOS is able to assist when necessary with the problems variable device names can cause during rescue operations. Mind you because all here are multiboot, external HD boot from either bus is virtually never a necessity. A stick I have used, but only for feeding a BIOS updater's own integrated BIOS update utility its new code.
If you only need it for rescue, the openSUSE rescue image on a stick is enough.-- "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-07-17 23:08, Felix Miata wrote:
Carlos E. R. composed on 2018-07-17 22:13 (UTC+0200):
I almost always create an extra system; it can be a small partition only for testing, like 8 GB. 15 is much better.
Maximum size of my test /s is 10, but the vast majority are less than 7200M, mostly 5600M. When multibooting for the primary purpose of testing a beta that is expected to become a replacement main installation, then size of test / is best identical. That allows the test to become the operational via a rather simple cloning operation followed by distribution upgrade when upgrade rather than fresh is desired, without disturbing the existing normal.
My test partitions share a single /home/ and single /usr/local/ partition, are installed with recommends disabled, and have installed only one DE besides the default IceWM, so have modest space requirements.
My strategy is a main system, big, home plus root, and a small extra test/rescue system (single partition), 9..15 GB. Once done testing, I upgrade the main system, not switch.
I didn't on my last install, a small laptop with a small SSD. However, there is an alternative on modern laptops: an external hard disk via USB3.
USB is/are a(re) different bus(es), which is/are subject to different device enumeration order and thus different device name assignment. Thus, I never do USB HD boot.
Just use labels or uuids.
I use eSATA when I need to boot from an external HD. That way, the BIOS is able to assist when necessary with the problems variable device names can cause during rescue operations.
No such problems - there are no variable names if you choose the correct ones ;-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. composed on 2018-07-17 17:46 (UTC-0400):
Felix Miata wrote:
My test partitions share a single /home/ and single /usr/local/ partition, are installed with recommends disabled, and have installed only one DE besides the default IceWM, so have modest space requirements.
My strategy is a main system, big, home plus root, and a small extra test/rescue system (single partition), 9..15 GB. Once done testing, I upgrade the main system, not switch.
I had only three on my main system for a number of years, current, next, test. problems common to betas made me add a fourth, to keep the former longer and/or opportune more than one "next". Now with so many PCs here one wouldn't expect that to matter, but this is using RAID, while the others save one is not, and the one that is is pretty much different from this.
USB is/are a(re) different bus(es), which is/are subject to different device enumeration order and thus different device name assignment. Thus, I never do USB HD boot.
Just use labels or uuids.
I know that, and you know that, but not every rescue context is helped by those, in particular, Grub*.
I use eSATA when I need to boot from an external HD. That way, the BIOS is able to assist when necessary with the problems variable device names can cause during rescue operations.
No such problems - there are no variable names if you choose the correct ones ;-)
Not usually the first thing done in rescue mode is fdisk -l | or | parted -l No UUIDs or labels in those. So in context of anyone needing help being instructed, the very first result is consternation. Other rescue tools often have similar limitations -- "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-07-18 00:23, Felix Miata wrote:
Carlos E. R. composed on 2018-07-17 17:46 (UTC-0400):
Felix Miata wrote:
My test partitions share a single /home/ and single /usr/local/ partition, are installed with recommends disabled, and have installed only one DE besides the default IceWM, so have modest space requirements.
My strategy is a main system, big, home plus root, and a small extra test/rescue system (single partition), 9..15 GB. Once done testing, I upgrade the main system, not switch.
I had only three on my main system for a number of years, current, next, test. problems common to betas made me add a fourth, to keep the former longer and/or opportune more than one "next". Now with so many PCs here one wouldn't expect that to matter, but this is using RAID, while the others save one is not, and the one that is is pretty much different from this.
USB is/are a(re) different bus(es), which is/are subject to different device enumeration order and thus different device name assignment. Thus, I never do USB HD boot.
Just use labels or uuids.
I know that, and you know that, but not every rescue context is helped by those, in particular, Grub*.
I use eSATA when I need to boot from an external HD. That way, the BIOS is able to assist when necessary with the problems variable device names can cause during rescue operations.
No such problems - there are no variable names if you choose the correct ones ;-)
Not usually the first thing done in rescue mode is
fdisk -l | or | parted -l
No UUIDs or labels in those. So in context of anyone needing help being instructed, the very first result is consternation. Other rescue tools often have similar limitations
But gparted sees and creates labels. And in the context of having an external disk booted over eSATA or USB, it works :-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. composed on 2018-07-18 02:31 (UTC+0200):
Felix Miata wrote:
No UUIDs or labels in those. So in context of anyone needing help being instructed, the very first result is consternation. Other rescue tools often have similar limitations
But gparted sees and creates labels. And in the context of having an external disk booted over eSATA or USB, it works :-)
Reads labels only if labels present, and runs only if its on an available filesystem. -- "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-07-18 02:41, Felix Miata wrote:
Carlos E. R. composed on 2018-07-18 02:31 (UTC+0200):
Felix Miata wrote:
No UUIDs or labels in those. So in context of anyone needing help being instructed, the very first result is consternation. Other rescue tools often have similar limitations
But gparted sees and creates labels. And in the context of having an external disk booted over eSATA or USB, it works :-)
Reads labels only if labels present, and runs only if its on an available filesystem.
They are present. All my partitions are labelled :-p Otherwise, use UUIDs. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. composed on 2018-07-18 05:03 (UTC+0200):
Felix Miata wrote:
Carlos E. R. composed on 2018-07-18 02:31 (UTC+0200):
Felix Miata wrote:
No UUIDs or labels in those. So in context of anyone needing help being instructed, the very first result is consternation. Other rescue tools often have similar limitations
But gparted sees and creates labels. And in the context of having an external disk booted over eSATA or USB, it works :-)
Reads labels only if labels present, and runs only if its on an available filesystem.
They are present. All my partitions are labelled :-p
Otherwise, use UUIDs.
I was referring to people other than Carlos E. R. needing help with or trying to use rescue modes provided through various rescue sources. Real humans can't be expected to work with UUIDs (or have existing filesystem labels). UUIDs are for software like grub, systemd and kernel, not people. -- "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-07-18 05:14, Felix Miata wrote:
Carlos E. R. composed on 2018-07-18 05:03 (UTC+0200):
Felix Miata wrote:
Carlos E. R. composed on 2018-07-18 02:31 (UTC+0200):
Felix Miata wrote:
No UUIDs or labels in those. So in context of anyone needing help being instructed, the very first result is consternation. Other rescue tools often have similar limitations
But gparted sees and creates labels. And in the context of having an external disk booted over eSATA or USB, it works :-)
Reads labels only if labels present, and runs only if its on an available filesystem.
They are present. All my partitions are labelled :-p
Otherwise, use UUIDs.
I was referring to people other than Carlos E. R. needing help with or trying to use rescue modes provided through various rescue sources. Real humans can't be expected to work with UUIDs (or have existing filesystem labels). UUIDs are for software like grub, systemd and kernel, not people.
:-) YaST by default uses UUIDs since years, and so does grub. Usage of device names such as /dev/sda is deprecated and should not be created by any automatic configuration tool used by openSUSE, and if done should be reported as bug. In fact, a name such as /dev/sda in fstab since years makes YaST abort the system upgrade, asking the admin to remove the offending line. There was a post when it happened to someone not 4 months ago. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Le 18/07/2018 à 10:13, Carlos E. R. a écrit :
YaST by default uses UUIDs since years, and so does grub. Usage of device names such as /dev/sda
/dev/sda is not a device name as used on this thread, if I understand well. "names" are in fact "labels" I think... jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18/07/18 04:27 AM, jdd@dodin.org wrote:
Le 18/07/2018 à 10:13, Carlos E. R. a écrit :
YaST by default uses UUIDs since years, and so does grub. Usage of device names such as /dev/sda
/dev/sda is not a device name as used on this thread, if I understand well. "names" are in fact "labels"
I think...
LOL! Lewis Carrol or a computer science purist or student of Alfred Korzybski might argue with that. A Zen Master might also, while his finger is pointing to the moon. Or not. In the mean time, as I said elsewhere, we are[1] human. Well some of us claim to be. Some of the time. We are not 'grub'. We are not YaST. We are not the kernel. In English, the very 'to be' is often problematic because we confuse its use relating to identity with its other uses: https://en.wikipedia.org/wiki/E-Prime#Different_functions_of_%22to_be%22 Kellogg and Bourland describe misuse of the verb to be as creating a "deity mode of speech", allowing "even the most ignorant to transform their opinions magically into god-like pronouncements on the nature of things" [1] That is use of the verb 'to be' as class membership. You might think that its use is one of 'identity', but not in this context. -- 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 07/18/2018 03:13 AM, Carlos E. R. wrote:
YaST by default uses UUIDs since years, and so does grub.
Well, if you define years by 1+, then maybe that is a true statement, but my 42.2 install did install to */dev/sda* (using /dev/sda in fstab and all GRUB files, not UUID) which resulted in grub overwriting my Win10 boot code when I moved the drive to a second drive bay and put the Win10 disk back in the laptop. I had to manually update all grub and the fstab file to remove the /dev/sda and convert to UUID. -- David C. Rankin, J.D.,P.E.
On 2018-07-18 17:18, David C. Rankin wrote:
On 07/18/2018 03:13 AM, Carlos E. R. wrote:
YaST by default uses UUIDs since years, and so does grub.
Well, if you define years by 1+, then maybe that is a true statement, but my 42.2 install did install to */dev/sda* (using /dev/sda in fstab and all GRUB files, not UUID) which resulted in grub overwriting my Win10 boot code when I moved the drive to a second drive bay and put the Win10 disk back in the laptop.
I had to manually update all grub and the fstab file to remove the /dev/sda and convert to UUID.
Yes, I know, but it is a bug. Try to upgrade 13.1 to Leap with /dev/sda something in fstab and it will abort on you. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 17/07/18 11:14 PM, Felix Miata wrote:
Real humans can't be expected to work with UUIDs (or have existing filesystem labels). UUIDs are for software like grub, systemd and kernel, not people.
+1 That's why we have DNS. That's why the cities we live in have names and we don't use Latitude/Longitude to describe where we live. Even the few of us who are good at mental arithmetic don't think in those sort of numbers. Whenever I set up a new drive I use some to tool to labels the disk. It may be ROOT4 or HOME17 or PHOTO18, and I try hard to make it both unique and meaningful. Occasionally I find the grub.conf has a UUID and I struggle to translate that and replace it with a meaningful /dev/disk/by-label/ or /dev/disk/by-partlabel/ YMMV but why make life difficult for yourself. After all the computer is there for your convenience. It's not as if if you are there for the convenience of the computer. 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 18.07.2018 14:30, Anton Aylward wrote:
On 17/07/18 11:14 PM, Felix Miata wrote:
Real humans can't be expected to work with UUIDs (or have existing filesystem labels). UUIDs are for software like grub, systemd and kernel, not people.
+1
That's why we have DNS. That's why the cities we live in have names and we don't use Latitude/Longitude to describe where we live.
Even the few of us who are good at mental arithmetic don't think in those sort of numbers.
Whenever I set up a new drive I use some to tool to labels the disk. It may be ROOT4 or HOME17 or PHOTO18, and I try hard to make it both unique and meaningful.
Occasionally I find the grub.conf has a UUID and I struggle to translate that and replace it with a meaningful /dev/disk/by-label/ or /dev/disk/by-partlabel/
YMMV but why make life difficult for yourself. After all the computer is there for your convenience. It's not as if if you are there for the convenience of the computer. Yet.
hm. If you use windows or mac in fact you do what the computer says, one of the reasons why I use Linux. Even android wants to give me orders ("Allow access to the microphone now!" says google Maps each time, although it doesn't need it, but someone at google wants to hear if there are any moans in my car, probably to delete them if considered inappropriate...) On the other hand, with my recent problems I use more time for the computer than the computer works for me :-( But that's off-off-topic. In regard to disk-labels: I label my external disks with useful names, but when I plug them by usb the message is only "1.8 TB encrypted drive". So if I connect several I never know which one is which, especially when I want to disconnect one to plug another one. Would be extremely nice if that box that opens when you plug a device would show it's name. But it's not my biggest problem, though. -- Daniel Bauer photographer Basel Málaga https://www.patreon.com/danielbauer http://www.daniel-bauer.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-07-18 15:13, Daniel Bauer wrote:
In regard to disk-labels: I label my external disks with useful names, but when I plug them by usb the message is only "1.8 TB encrypted drive". So if I connect several I never know which one is which, especially when I want to disconnect one to plug another one. Would be extremely nice if that box that opens when you plug a device would show it's name. But it's not my biggest problem, though.
You have to label the filesystem inside the encrypted partition, and possible the partlabel outside. It might be possible to label the partition outside, before encryption, but then it may be overwritten and lost. The external uuid keeps, though. Maybe. I mount them manually, mostly, thus I define the directory where they mount. You need to define entries in fstab and crypttab for each disk (nofail,noauto). But then entering the password becomes one more nuisance than leaving it on automatic... So I wrote my own scripts. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Carlos E. R. composed on 2018-07-17 23:46 (UTC+0200):
Felix Miata wrote:
My test partitions share a single /home/ and single /usr/local/ partition, are installed with recommends disabled, and have installed only one DE besides the default IceWM, so have modest space requirements.
My strategy is a main system, big, home plus root, and a small extra test/rescue system (single partition), 9..15 GB. Once done testing, I upgrade the main system, not switch.
I had only three on my main system for a number of years, current, next, test. problems common to betas made me add a fourth, to keep the former longer and/or opportune more than one "next". Now with so many PCs here one wouldn't expect that to matter, but this is using RAID, while the others save one is not, and the one that is is pretty much different from this.
USB is/are a(re) different bus(es), which is/are subject to different device enumeration order and thus different device name assignment. Thus, I never do USB HD boot.
Just use labels or uuids.
I know that, and you know that, but not every rescue context is helped by those, in particular, Grub*.
I use eSATA when I need to boot from an external HD. That way, the BIOS is able to assist when necessary with the problems variable device names can cause during rescue operations.
No such problems - there are no variable names if you choose the correct ones ;-)
Not usually the first thing done in rescue mode is fdisk -l | or | parted -l No UUIDs or labels in those. So in context of anyone needing help being instructed, the very first result is consternation. Other rescue tools often have similar limitations -- "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-07-17 16:28, jdd@dodin.org wrote:
Le 17/07/2018 à 16:12, Daniel Bauer a écrit :
So I can only try things that will at least allow me to enter in text mode to undo what caused the problem...
AFAIK, typing "3" on the kernel line in grub allow text mode
The idea, I think, is to connect from another machine via network to the one that is hanging to kill some process or see the output of some command. If there is no other comptuer, an alternative is a tablet with an ssh application. For instance, VX ConnectBot. I find it cumbersome, though. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Le 17/07/2018 à 19:34, Carlos E. R. a écrit :
If there is no other comptuer, an alternative is a tablet with an ssh application. For instance, VX ConnectBot. I find it cumbersome, though.
or any smartphone :-( jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-07-17 19:53, jdd@dodin.org wrote:
Le 17/07/2018 à 19:34, Carlos E. R. a écrit :
If there is no other comptuer, an alternative is a tablet with an ssh application. For instance, VX ConnectBot. I find it cumbersome, though.
or any smartphone :-(
Even more cumbersome :-( -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 07/17/2018 01:34 PM, Carlos E. R. wrote:
The idea, I think, is to connect from another machine via network to the one that is hanging to kill some process or see the output of some command.
If there is no other comptuer, an alternative is a tablet with an ssh application. For instance, VX ConnectBot. I find it cumbersome, though.
Try using "Reflection" instead on the tablet. It is very straight forward and easy to use. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-07-18 18:20, Ken Schneider - openSUSE wrote:
On 07/17/2018 01:34 PM, Carlos E. R. wrote:
The idea, I think, is to connect from another machine via network to the one that is hanging to kill some process or see the output of some command.
If there is no other comptuer, an alternative is a tablet with an ssh application. For instance, VX ConnectBot. I find it cumbersome, though.
Try using "Reflection" instead on the tablet. It is very straight forward and easy to use.
A search on google play found only photo apps... Try sending an actual google play link, or add the developer name :-? My trouble with "VX ConnectBot" is mostly the keyboard, though. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 2018-07-17 13:34, Daniel Bauer wrote:
On 17.07.2018 13:20, Andrei Borzenkov wrote:
The first step is to enable KMS in nvidia-drm. This is documented in nVidia README.
I don't know where to find that readme. Googling brought me to an nvidia page and there I read to enter:
Telcontar:~ # locate -i nvidia | grep -i readme /usr/share/doc/nvidia/README.txt.gz /usr/share/doc/nvidia/NVIDIA-Linux-x86-1.0-7664-pkg1/usr/share/doc/README.txt /usr/share/doc/nvidia/NVIDIA-Linux-x86-1.0-7664-pkg1/usr/src/nv/README /usr/src/kernel-modules/nvidia-340.106-default/g_nvreadme.h /usr/src/kernel-modules/nvidia-uvm-340.106-default/rm/g_nvreadme.h Telcontar:~ # But they are not owned by any rpm, and are dated 2006, so it is none of them. It appears that the nvidia RPMS do not have the readme file, so you have to grab the .run archive instead. So if Patrick is right, the readme is here: <http://download.nvidia.com/XFree86/Linux-x86_64/396.24/README/> maybe here: <http://download.nvidia.com/XFree86/Linux-x86_64/396.24/README/kms.html> -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 7/17/2018 6:03 AM, Daniel Bauer wrote:
It now runs the intel graphics only, in a terrible way with lot of flickering.
I cannot disable the intel graphics or make the nvidia graphics primary in the BIOS (there are no such options there and I double-double-checked...).
Install dmidecode - run it as root, then posts the output. It is a listing of all devices and how they are connected to your system. Everything from the BIOS, each stick of RAM, each bus and controller, etc.. (worth having even if this doesn't fix the problem. Just redirect the output to a file, e.g. # dmidecode > tmp/dmidecodefile -- 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
participants (9)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Daniel Bauer -
David C. Rankin -
Felix Miata -
jdd＠dodin.org -
Ken Schneider - openSUSE -
Patrick Shanahan