[oS-en] /etc/resolv.conf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New machine with 15.4 Name solving not working (after playing with YaST networking module). /etc/resolv.conf was empty. I restarted network nmcli off nmcli on and /etc/resolv.conf was populated, but incorrectly: Laicolasse:~ l /etc/resolv.conf g lrwxrwxrwx 1 root root 26 Mar 27 19:13 /etc/resolv.conf -> /run/netconfig/resolv.conf Laicolasse:~ # cat /etc/resolv.conf ### /etc/resolv.conf is a symlink to /run/netconfig/resolv.conf ### autogenerated by netconfig! # # Before you change this file manually, consider to define the # static DNS configuration using the following variables in the # /etc/sysconfig/network/config file: # NETCONFIG_DNS_STATIC_SEARCHLIST # NETCONFIG_DNS_STATIC_SERVERS # NETCONFIG_DNS_FORWARDER # or disable DNS configuration updates via netconfig by setting: # NETCONFIG_DNS_POLICY='' # # See also the netconfig(8) manual page and other documentation. # ### Call "netconfig update -f" to force adjusting of /etc/resolv.conf. search valinor Laicolasse:~ # See that there is no DNS entry. However: Laicolasse:~ # nmcli eth0: connected to eth0 "Realtek RTL8111/8168/8411" ethernet (r8169), F4:A8:0D:7A:49:01, hw, mtu 1500 ip4 default inet4 192.168.2.17/16 route4 0.0.0.0/0 route4 192.168.0.0/16 inet6 fe80::f6a8:dff:fe7a:4901/64 route6 fe80::/64 lo: unmanaged "lo" loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536 DNS configuration: servers: 80.58.61.254 80.58.61.250 interface: eth0 Use "nmcli device show" to get complete information about known devices and "nmcli connection show" to get an overview on active connection profiles. Consult nmcli(1) and nmcli-examples(7) manual pages for complete usage details. Laicolasse:~ # As you see, the DNS information is there. Just not in etc/resolv.conf where it is needed. How do I make it go there? (machine is currently running text mode) - -- Cheers Carlos E. R. (from 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZCIgORwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV358An1d73/buBx7T2sU7+Y44 DuFnqrkwAJ9WfZ3Vn4uHxz3WrjXD1Iw1RNcgqA== =+amE -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2023-03-28 at 01:01 +0200, Carlos E. R. wrote:
### Call "netconfig update -f" to force adjusting of /etc/resolv.conf. search valinor Laicolasse:~ #
No, netconfig update -f does nothing useful. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZCIgsBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV8BkAnR6l2OA3WMnb6uC2BMxo t7ejzgyIAKCIVZGSOoTI7ChxFrNLLInnhQ5nOQ== =SaUS -----END PGP SIGNATURE-----
On 2023-03-28 01:01, Carlos E. R. wrote:
New machine with 15.4 Name solving not working (after playing with YaST networking module).
/etc/resolv.conf was empty. I restarted network
...
As you see, the DNS information is there. Just not in etc/resolv.conf where it is needed.
How do I make it go there?
(machine is currently running text mode)
Forget it. I thought a reboot would solve it, but machine decided to go to a kernel lock instead, repeatable (with indicator leds). I am reinstalling from scratch. :-/ -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 3/27/23 19:39, Carlos E. R. wrote:
Forget it.
I thought a reboot would solve it, but machine decided to go to a kernel lock instead, repeatable (with indicator leds).
I am reinstalling from scratch. :-/
Bummer.... I set my /etc/resolv.conf the way I wanted and then set the immutable attribute on the file to prevent it from being changed. 15.4 was flaky with /etc/resolv.conf. We are somewhat caught in no man's land as the battle rages between systemd and traditional networking tools over who and how your network interface will be controlled. The systemd monster grows ever larger and hungrier for all aspects of your system. Since I start WiFi onboot and dhcp on my server hands out a fixed IP based on the wireless MAC (no network manager, etc..), I certainly don't want resolv.conf to change. -- David C. Rankin, J.D.,P.E.
On 2023-03-28 07:11, David C. Rankin wrote:
On 3/27/23 19:39, Carlos E. R. wrote:
Forget it.
I thought a reboot would solve it, but machine decided to go to a kernel lock instead, repeatable (with indicator leds).
I am reinstalling from scratch. :-/
Bummer....
I set my /etc/resolv.conf the way I wanted and then set the immutable attribute on the file to prevent it from being changed.
It is a new install... I want to do things they are supposed to work, not apply all my hacks this early. So I thought, I really thought, that a reboot would set it right. I did not expect a kernel crash that blocked access to the machine, which I do not know if it is my fault after replacing many configuration files.
15.4 was flaky with /etc/resolv.conf. We are somewhat caught in no man's land as the battle rages between systemd and traditional networking tools over who and how your network interface will be controlled. The systemd monster grows ever larger and hungrier for all aspects of your system.
Heh.
Since I start WiFi onboot and dhcp on my server hands out a fixed IP based on the wireless MAC (no network manager, etc..), I certainly don't want resolv.conf to change.
On the contrary, my laptop is expected to move around. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Tue, Mar 28, 2023 at 8:11 AM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
15.4 was flaky with /etc/resolv.conf. We are somewhat caught in no man's land as the battle rages between systemd and traditional networking tools over who and how your network interface will be controlled. The systemd monster grows ever larger and hungrier for all aspects of your system.
Which has nothing to do with openSUSE and is FUD anyway.
Since I start WiFi onboot and dhcp on my server hands out a fixed IP based on the wireless MAC (no network manager, etc..), I certainly don't want resolv.conf to change.
Which is perfectly possible using netconfig but then there will be nothing to complain about.
David C. Rankin wrote:
Since I start WiFi onboot and dhcp on my server hands out a fixed IP based on the wireless MAC (no network manager, etc..), I certainly don't want resolv.conf to change.
Okay, I'm curious - why on earth not?? My setup is the same, on a number of machines (laptops, raspis etc), but I certainly _do_ want resolv.conf changed. The dhcp config is what matters, I want search domains, nameservers and other options distributed and written to resolv.conf. -- Per Jessen, Zürich (4.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 3/28/23 02:56, Per Jessen wrote:
David C. Rankin wrote:
Since I start WiFi onboot and dhcp on my server hands out a fixed IP based on the wireless MAC (no network manager, etc..), I certainly don't want resolv.conf to change.
Okay, I'm curious - why on earth not?? My setup is the same, on a number of machines (laptops, raspis etc), but I certainly _do_ want resolv.conf changed. The dhcp config is what matters, I want search domains, nameservers and other options distributed and written to resolv.conf.
Well, My laptop rarely travels, so for consistent name-resolution given the atavistic nature of resolv.conf on 15.4, I set it how I need it and then fix it in that state. If I do take the laptop somewhere, then I simply remove the immutable attribute. (much less effort that chasing resolv.conf issues down) I just used YAST to set the interface to start on boot -- so it lives that way happily, regardless whether I have a desktop or just boot to console. -- David C. Rankin, J.D.,P.E.
David C. Rankin wrote:
On 3/28/23 02:56, Per Jessen wrote:
David C. Rankin wrote:
Since I start WiFi onboot and dhcp on my server hands out a fixed IP based on the wireless MAC (no network manager, etc..), I certainly don't want resolv.conf to change.
Okay, I'm curious - why on earth not?? My setup is the same, on a number of machines (laptops, raspis etc), but I certainly _do_ want resolv.conf changed. The dhcp config is what matters, I want search domains, nameservers and other options distributed and written to resolv.conf.
Well,
My laptop rarely travels, so for consistent name-resolution given the atavistic nature of resolv.conf on 15.4, I set it how I need it and then fix it in that state. If I do take the laptop somewhere, then I simply remove the immutable attribute. (much less effort that chasing resolv.conf issues down)
My laptops and PCs and whathaveyou also very rarely travel anywhere, but I don't have any running Leap 15.4 yet - if there is something basically wrong with the resolver setup in 15.4, I guess I'[ll find out. -- Per Jessen, Zürich (8.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-29 08:34, Per Jessen wrote:
David C. Rankin wrote:
On 3/28/23 02:56, Per Jessen wrote:
David C. Rankin wrote:
Since I start WiFi onboot and dhcp on my server hands out a fixed IP based on the wireless MAC (no network manager, etc..), I certainly don't want resolv.conf to change.
Okay, I'm curious - why on earth not?? My setup is the same, on a number of machines (laptops, raspis etc), but I certainly _do_ want resolv.conf changed. The dhcp config is what matters, I want search domains, nameservers and other options distributed and written to resolv.conf.
Well,
My laptop rarely travels, so for consistent name-resolution given the atavistic nature of resolv.conf on 15.4, I set it how I need it and then fix it in that state. If I do take the laptop somewhere, then I simply remove the immutable attribute. (much less effort that chasing resolv.conf issues down)
My laptops and PCs and whathaveyou also very rarely travel anywhere, but I don't have any running Leap 15.4 yet - if there is something basically wrong with the resolver setup in 15.4, I guess I'[ll find out.
I have noticed no issues with resolv.conf in my first four machines (two fixed, two old laptops), all running 15.4. I only had issues with the new laptop, possibly triggered by my tinkering. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-03-29 08:34, Per Jessen wrote:
David C. Rankin wrote:
On 3/28/23 02:56, Per Jessen wrote:
David C. Rankin wrote:
Since I start WiFi onboot and dhcp on my server hands out a fixed IP based on the wireless MAC (no network manager, etc..), I certainly don't want resolv.conf to change.
Okay, I'm curious - why on earth not?? My setup is the same, on a number of machines (laptops, raspis etc), but I certainly _do_ want resolv.conf changed. The dhcp config is what matters, I want search domains, nameservers and other options distributed and written to resolv.conf.
Well,
My laptop rarely travels, so for consistent name-resolution given the atavistic nature of resolv.conf on 15.4, I set it how I need it and then fix it in that state. If I do take the laptop somewhere, then I simply remove the immutable attribute. (much less effort that chasing resolv.conf issues down)
My laptops and PCs and whathaveyou also very rarely travel anywhere, but I don't have any running Leap 15.4 yet - if there is something basically wrong with the resolver setup in 15.4, I guess I'[ll find out.
I have noticed no issues with resolv.conf in my first four machines (two fixed, two old laptops), all running 15.4.
I was being a bit sarcastic - I very much doubt there is any issue with the resolver in 15.4 (in any typical setup), it is such a basic necessity, we would have heard about it. -- Per Jessen, Zürich (14.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-29 13:53, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-29 08:34, Per Jessen wrote:
David C. Rankin wrote:
On 3/28/23 02:56, Per Jessen wrote:
David C. Rankin wrote:
Since I start WiFi onboot and dhcp on my server hands out a fixed IP based on the wireless MAC (no network manager, etc..), I certainly don't want resolv.conf to change.
Okay, I'm curious - why on earth not?? My setup is the same, on a number of machines (laptops, raspis etc), but I certainly _do_ want resolv.conf changed. The dhcp config is what matters, I want search domains, nameservers and other options distributed and written to resolv.conf.
Well,
My laptop rarely travels, so for consistent name-resolution given the atavistic nature of resolv.conf on 15.4, I set it how I need it and then fix it in that state. If I do take the laptop somewhere, then I simply remove the immutable attribute. (much less effort that chasing resolv.conf issues down)
My laptops and PCs and whathaveyou also very rarely travel anywhere, but I don't have any running Leap 15.4 yet - if there is something basically wrong with the resolver setup in 15.4, I guess I'[ll find out.
I have noticed no issues with resolv.conf in my first four machines (two fixed, two old laptops), all running 15.4.
I was being a bit sarcastic - I very much doubt there is any issue with the resolver in 15.4 (in any typical setup), it is such a basic necessity, we would have heard about it.
I did hear of problems, when it was moved to /run something. I don't know how it works now, thus I had problems when it failed to work for me the other day. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-03-29 13:53, Per Jessen wrote:
Carlos E. R. wrote:
My laptops and PCs and whathaveyou also very rarely travel anywhere, but I don't have any running Leap 15.4 yet - if there is something basically wrong with the resolver setup in 15.4, I guess I'[ll find out.
I have noticed no issues with resolv.conf in my first four machines (two fixed, two old laptops), all running 15.4.
I was being a bit sarcastic - I very much doubt there is any issue with the resolver in 15.4 (in any typical setup), it is such a basic necessity, we would have heard about it.
I did hear of problems, when it was moved to /run something. I don't know how it works now,
I expect it works very much the same way as always :-) In my NFS-root setup, there was some issue, possibly influenced by firewalld. The work-around was removing firewalld which I do anyway.
I had problems when it failed to work for me the other day.
What was the problem in the end? or is it still a problem? -- Per Jessen, Zürich (15.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-29 14:36, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-29 13:53, Per Jessen wrote:
Carlos E. R. wrote:
My laptops and PCs and whathaveyou also very rarely travel anywhere, but I don't have any running Leap 15.4 yet - if there is something basically wrong with the resolver setup in 15.4, I guess I'[ll find out.
I have noticed no issues with resolv.conf in my first four machines (two fixed, two old laptops), all running 15.4.
I was being a bit sarcastic - I very much doubt there is any issue with the resolver in 15.4 (in any typical setup), it is such a basic necessity, we would have heard about it.
I did hear of problems, when it was moved to /run something. I don't know how it works now,
I expect it works very much the same way as always :-) In my NFS-root setup, there was some issue, possibly influenced by firewalld. The work-around was removing firewalld which I do anyway.
Well, "always" I wrote it by hand, directly. That can not be done now, if it lives under /run. Something is now creating it on every boot. What, how? Where does it read the data from? How can I do now permanent changes to it so they get written on every boot?
I had problems when it failed to work for me the other day.
What was the problem in the end? or is it still a problem?
No idea what it was, and can't find out because I reinstalled fully. Every time I boot the machine, I tremble. I don't feel safe. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Wed, Mar 29, 2023 at 3:43 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
Well, "always" I wrote it by hand, directly. That can not be done now,
"now" as in the last 10 years at least?
if it lives under /run. Something is now creating it on every boot. What, how? Where does it read the data from? How can I do now permanent changes to it so they get written on every boot?
man netconfig
Carlos E. R. wrote:
On 2023-03-29 14:36, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-29 13:53, Per Jessen wrote:
Carlos E. R. wrote:
My laptops and PCs and whathaveyou also very rarely travel anywhere, but I don't have any running Leap 15.4 yet - if there is something basically wrong with the resolver setup in 15.4, I guess I'[ll find out.
I have noticed no issues with resolv.conf in my first four machines (two fixed, two old laptops), all running 15.4.
I was being a bit sarcastic - I very much doubt there is any issue with the resolver in 15.4 (in any typical setup), it is such a basic necessity, we would have heard about it.
I did hear of problems, when it was moved to /run something. I don't know how it works now,
I expect it works very much the same way as always :-) In my NFS-root setup, there was some issue, possibly influenced by firewalld. The work-around was removing firewalld which I do anyway.
Well, "always" I wrote it by hand, directly.
Seriously? Okay, I guess maybe you don't have a full function dhcp server.
That can not be done now, if it lives under /run.
If I were to write everyone of my resolv.conf files manually, it would probably take me a day or two. But you can still write it manually, with your favourite editor.
Something is now creating it on every boot.
I expect you can configure the contents in /etc/sysconfig/network/config.
What, how? Where does it read the data from? How can I do now permanent changes to it so they get written on every boot?
Same way as for many, many years - /etc/sysconfig/network/config.
No idea what it was, and can't find out because I reinstalled fully.
Provided it works now, the problem/culprit has been identifed - the operator.
Every time I boot the machine, I tremble. I don't feel safe.
Yeah, it might explode. I would quickly just start the boot process, then go to another room. -- Per Jessen, Zürich (15.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-29 14:53, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-29 14:36, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-29 13:53, Per Jessen wrote:
Carlos E. R. wrote:
> My laptops and PCs and whathaveyou also very rarely travel > anywhere, but I don't have any running Leap 15.4 yet - if there > is something basically wrong with the resolver setup in 15.4, I > guess I'[ll find out.
I have noticed no issues with resolv.conf in my first four machines (two fixed, two old laptops), all running 15.4.
I was being a bit sarcastic - I very much doubt there is any issue with the resolver in 15.4 (in any typical setup), it is such a basic necessity, we would have heard about it.
I did hear of problems, when it was moved to /run something. I don't know how it works now,
I expect it works very much the same way as always :-) In my NFS-root setup, there was some issue, possibly influenced by firewalld. The work-around was removing firewalld which I do anyway.
Well, "always" I wrote it by hand, directly.
Seriously? Okay, I guess maybe you don't have a full function dhcp server.
Certainly, I don't. I have an ISP provided router that has some limited DHCP functionality. I can fixate 15 or 30 addresses, I think. I can assign a common DNS. Strangely, the current incumbent is assigning the upstream Telefónica addresses instead of its own router address.
That can not be done now, if it lives under /run.
If I were to write everyone of my resolv.conf files manually, it would probably take me a day or two. But you can still write it manually, with your favourite editor.
No, you can't. It lives under /run, it is volatile. You can break the symlink and write an actual file in /etc, perhaps.
Something is now creating it on every boot.
I expect you can configure the contents in /etc/sysconfig/network/config.
Yes, that's what I do in my desktop machine, where I am seated now: NETCONFIG_DNS_STATIC_SERVERS='127.0.0.1 192.168.1.16'
What, how? Where does it read the data from? How can I do now permanent changes to it so they get written on every boot?
Same way as for many, many years - /etc/sysconfig/network/config.
Hum.
No idea what it was, and can't find out because I reinstalled fully.
Provided it works now, the problem/culprit has been identifed - the operator.
LOL. And what did the operator do to cause this, so that he doesn't do it again? :-)
Every time I boot the machine, I tremble. I don't feel safe.
Yeah, it might explode. I would quickly just start the boot process, then go to another room.
It may eat your kittens :-D Common, it may force me to do another reinstall. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-03-29 14:53, Per Jessen wrote:
That can not be done now, if it lives under /run.
If I were to write everyone of my resolv.conf files manually, it would probably take me a day or two. But you can still write it manually, with your favourite editor.
No, you can't. It lives under /run, it is volatile.
Well, that does not actually mean you cannot edit it.
You can break the symlink and write an actual file in /etc, perhaps.
For instance.
No idea what it was, and can't find out because I reinstalled fully.
Provided it works now, the problem/culprit has been identifed - the operator.
LOL. And what did the operator do to cause this, so that he doesn't do it again? :-)
Uncritically copied over a load of old sh*te, I think I saw him say.
Every time I boot the machine, I tremble. I don't feel safe.
Yeah, it might explode. I would quickly just start the boot process, then go to another room.
It may eat your kittens :-D Common, it may force me to do another reinstall.
Carlos, sigh. You forced yourself to do another install. -- Per Jessen, Zürich (15.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-29 15:46, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-29 14:53, Per Jessen wrote:
That can not be done now, if it lives under /run.
If I were to write everyone of my resolv.conf files manually, it would probably take me a day or two. But you can still write it manually, with your favourite editor.
No, you can't. It lives under /run, it is volatile.
Well, that does not actually mean you cannot edit it.
Ok, right. Did I say "permanently edit" somewhere? :-?
You can break the symlink and write an actual file in /etc, perhaps.
For instance.
Yeah, sure, but that is under the eat my kittens warning board. :-p (I may have done it somewhere and forgotten, mind)
No idea what it was, and can't find out because I reinstalled fully.
Provided it works now, the problem/culprit has been identifed - the operator.
LOL. And what did the operator do to cause this, so that he doesn't do it again? :-)
Uncritically copied over a load of old sh*te, I think I saw him say.
:-D Not uncritically... just not sufficiently checked, rather. I copied file by file, under /etc, /usr/local/, /var/log, /root, maybe some other. I decided what files to copy. I did not write anything in /boot, or bins. Maybe something happened accidentally.
Every time I boot the machine, I tremble. I don't feel safe.
Yeah, it might explode. I would quickly just start the boot process, then go to another room.
It may eat your kittens :-D Common, it may force me to do another reinstall.
Carlos, sigh. You forced yourself to do another install.
How, exactly? Per, I'm not as bright as I was, age takes its toll, but I am experienced. I don't know of anything I did that would cause a kernel panic. The only thing new is, aside of the machine, using full disk encryption. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
Every time I boot the machine, I tremble. I don't feel safe.
Yeah, it might explode. I would quickly just start the boot process, then go to another room.
It may eat your kittens :-D Common, it may force me to do another reinstall.
Carlos, sigh. You forced yourself to do another install.
How, exactly?
By uncritically copying over a load of old sh*te, as far as I can tell. If you cannot reproduce the problem by just repeating the installation, it must have been subsequent operator error. -- Per Jessen, Zürich (19.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-29 16:23, Per Jessen wrote:
Carlos E. R. wrote:
Every time I boot the machine, I tremble. I don't feel safe.
Yeah, it might explode. I would quickly just start the boot process, then go to another room.
It may eat your kittens :-D Common, it may force me to do another reinstall.
Carlos, sigh. You forced yourself to do another install.
How, exactly?
By uncritically copying over a load of old sh*te, as far as I can tell. If you cannot reproduce the problem by just repeating the installation, it must have been subsequent operator error.
Again, I did not copy over a lot of old sh*te *uncritically*. I decided what files to copy, one by one. Many of them I edited just after copying them. Something that I am still doing, just more slowly and booting several times in between. I think myself that the cause was unconfigured sound by YaST. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-03-29 16:23, Per Jessen wrote:
Carlos E. R. wrote:
> Every time I boot the machine, I tremble. I don't feel safe.
Yeah, it might explode. I would quickly just start the boot process, then go to another room.
It may eat your kittens :-D Common, it may force me to do another reinstall.
Carlos, sigh. You forced yourself to do another install.
How, exactly?
By uncritically copying over a load of old sh*te, as far as I can tell. If you cannot reproduce the problem by just repeating the installation, it must have been subsequent operator error.
Again, I did not copy over a lot of old sh*te *uncritically*. I decided what files to copy, one by one. Many of them I edited just after copying them.
Yesterday you wrote: "New laptop is now running, but I will be much more careful when copying over config files from old config.". Needing to be "much more careful" suggests you weren't sufficiently careful on the first try. That sounds to me like "uncritically copying over a load of old sh*te", maybe slightly exaggerated to enhance the meaning.
I think myself that the cause was unconfigured sound by YaST.
Right, it is a well known problem with unconfigured sound that forces people to reinstall, just to see if repeating the exercise will magically solve the problem. -- Per Jessen, Zürich (19.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-29 16:36, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-29 16:23, Per Jessen wrote:
Carlos E. R. wrote:
>> Every time I boot the machine, I tremble. I don't feel safe. > > Yeah, it might explode. I would quickly just start the boot > process, then go to another room.
It may eat your kittens :-D Common, it may force me to do another reinstall.
Carlos, sigh. You forced yourself to do another install.
How, exactly?
By uncritically copying over a load of old sh*te, as far as I can tell. If you cannot reproduce the problem by just repeating the installation, it must have been subsequent operator error.
Again, I did not copy over a lot of old sh*te *uncritically*. I decided what files to copy, one by one. Many of them I edited just after copying them.
Yesterday you wrote: "New laptop is now running, but I will be much more careful when copying over config files from old config.".
Needing to be "much more careful" suggests you weren't sufficiently careful on the first try. That sounds to me like "uncritically copying over a load of old sh*te", maybe slightly exaggerated to enhance the meaning.
Being more careful means that I'm doing it more slowly and booting in between to check. Uncritically would mean to me: cp source:/etc dest:/etc I did not do that. I checked every single file I copied, and edited many.
I think myself that the cause was unconfigured sound by YaST.
Right, it is a well known problem with unconfigured sound that forces people to reinstall, just to see if repeating the exercise will magically solve the problem.
The last message before crashing was about sound, precisely. One of these areas:
Mar 28 20:10:50 Laicolasse nscd[1568]: 1568 monitoring file `/etc/netgroup` (7) Mar 28 20:10:50 Laicolasse nscd[1568]: 1568 monitoring directory `/etc` (2) Mar 28 20:10:50 Laicolasse systemd[1]: Finished Save/Restore Sound Card State. <=========== Mar 28 20:10:50 Laicolasse bluetoothd[1544]: Bluetooth daemon 5.62 Mar 28 20:10:50 Laicolasse systemd[1]: Starting Load extra kernel modules for sound stuff...
or
Mar 28 20:10:50 Laicolasse systemd[1]: Finished Apply settings from /etc/sysconfig/keyboard. Mar 28 20:10:50 Laicolasse kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Mar 28 20:10:50 Laicolasse kernel: Bluetooth: BNEP filters: protocol multicast Mar 28 20:10:50 Laicolasse kernel: Bluetooth: BNEP socket layer initialized Mar 28 20:10:50 Laicolasse dbus-daemon[1546]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' request> Mar 28 20:10:50 Laicolasse bluetoothd[1544]: Bluetooth management interface 1.21 initialized Mar 28 20:10:50 Laicolasse systemd[1]: Starting Hostname Service... Mar 28 20:10:50 Laicolasse augenrules[1542]: /sbin/augenrules: No change Mar 28 20:10:50 Laicolasse systemd[1]: sound-extra.service: Deactivated successfully. Mar 28 20:10:50 Laicolasse systemd[1]: Finished Load extra kernel modules for sound stuff. Mar 28 20:10:50 Laicolasse systemd[1]: Reached target Sound Card. <=========== Mar 28 20:10:50 Laicolasse augenrules[1659]: No rules Mar 28 20:10:50 Laicolasse systemd[1]: Finished auditd rules generation. Mar 28 20:10:50 Laicolasse polkitd[1564]: Loading rules from directory /etc/polkit-1/rules.d Mar 28 20:10:50 Laicolasse polkitd[1564]: Loading rules from directory /usr/share/polkit-1/rules.d Mar 28 20:10:50 Laicolasse polkitd[1564]: Finished loading, compiling and executing 4 rules Mar 28 20:10:50 Laicolasse systemd[1]: Started Authorization Manager. Mar 28 20:10:50 Laicolasse polkitd[1564]: Acquired the name org.freedesktop.PolicyKit1 on the system bus
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 3/29/23 01:34, Per Jessen wrote:
My laptops and PCs and whathaveyou also very rarely travel anywhere, but I don't have any running Leap 15.4 yet - if there is something basically wrong with the resolver setup in 15.4, I guess I'[ll find out.
No, Nothing is wrong with the resolver. We are just looking at a changing landscape at who controls name resolution and how it is done. The old /etc/resolv.conf isn't even needed depending on what you have managing your connection. systemd won't write one if you use its interface manager or some of the others. But there are apps that sill look for the traditional /etc/resolv.conf. So we are in the "in between" landscape of "who's on 1st?" as far as /etc/resolv.conf goes (despite what Andre calls FUD) I never did figure out what in my install was wiping /etc/resolv.conf. Much depends on how you configure your system -- and this isn't a bad thing -- openSUSE has always been good at providing "user-choice". The problem becomes how does Yast resolve whether and what goes in /etc/resolv.conf for all the myriads of possible configurations -- this is where the issue lies. So the path of least resistance for me at the time was just to set /etc/resolv.conf and set it as immutable given the way my system was setup (installed as minimal X-setup and then added KDE3, fluxbox and i3). Backtracking though all the network pieces/dependencies to identify and properly resolve whatever on 15.4 was causing the issue with that install history would have been quite an undertaking. So just be aware of the landscape and that your setup and choice of network manager will impact how /etc/resolv.conf is handled and you can at least quickly work-around any problem that arises. If you want to do the deep-dive of exactly what is happening, then I wouldn't mind helping, but it's not something I've had the time or motivation to do yet. -- David C. Rankin, J.D.,P.E.
Carlos E. R. wrote:
New machine with 15.4 Name solving not working (after playing with YaST networking module).
There's your problem - playing with yast :-)
/etc/resolv.conf was empty. I restarted network
This sounds similar to what I wrote earlier this month - when I was working on my mythtv install. IIRC, it was firewalld getting in the way, but I gave it up, my setup being somewhat exotic.
I thought a reboot would solve it, but machine decided to go to a kernel lock instead, repeatable (with indicator leds). I am reinstalling from scratch. :-/
You give up too quickly. At this point I would have booted the installer again, and probably rebuilt the initrd. Well, I might have attached a serial console, but I presume you don't have a serial port. -- Per Jessen, Zürich (4.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-28 10:02, Per Jessen wrote:
Carlos E. R. wrote:
New machine with 15.4 Name solving not working (after playing with YaST networking module).
There's your problem - playing with yast :-)
Yeah... I wanted to change the hostname and domain name, and I could not find how to do the later. This time (I had to reinstall) I set hostname during the very install operation.
/etc/resolv.conf was empty. I restarted network
This sounds similar to what I wrote earlier this month - when I was working on my mythtv install. IIRC, it was firewalld getting in the way, but I gave it up, my setup being somewhat exotic.
I remember, and tried stopping firewalld with systemd, then systemd refused to start it again with some strange error which I have forgotten. Anyway, it had no effect on dns servers.
I thought a reboot would solve it, but machine decided to go to a kernel lock instead, repeatable (with indicator leds). I am reinstalling from scratch. :-/
You give up too quickly. At this point I would have booted the installer again, and probably rebuilt the initrd. Well, I might have attached a serial console, but I presume you don't have a serial port.
Nay, this machine doesn't have a serial port. No, it crashed just after systemd starts sound. Some message about "finished starting sound". I was baffled. I did try to force an upgrade, but it only overwrote 16 packages or so, thus it was useless. I had no idea what to do, so reinstall it was :-/ I had no rescue USB or alternative install. I now have with me a stick to create it in this morning. New laptop is now running, but I will be much more careful when copying over config files from old config. This night I copied over, using rsync, the entire /home. I have to find out how to limit the battery charge to 50%. Manual mentions some setting in Windows, but of course I have no Windows. Found a reference googling yesterday [...] Huh, I'm at a different location today and don't have the link. New urgent thing: make tea. I'm running on a single early coffee. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
Carlos E. R. wrote:
On 2023-03-28 10:02, Per Jessen wrote:
This sounds similar to what I wrote earlier this month - when I was working on my mythtv install. IIRC, it was firewalld getting in the way, but I gave it up, my setup being somewhat exotic.
I remember, and tried stopping firewalld with systemd, then systemd refused to start it again with some strange error which I have forgotten. Anyway, it had no effect on dns servers.
"systemctl disable --now firewalld" is what you would have needed, but I would not have expected it to have any effect either.
No, it crashed just after systemd starts sound. Some message about "finished starting sound". I was baffled.
I did try to force an upgrade, but it only overwrote 16 packages or so, thus it was useless.
I had no idea what to do, so reinstall it was :-/ I had no rescue USB or alternative install.
Not needed, you just boot the installer again, but with "usessh=1". [1] That way it does not crank up yast right away and you can switch to a virtual console to work on the problem. [1] there might be other ways, I just happen to use this one.
I have to find out how to limit the battery charge to 50%.
Try googling "battery charge threshold linux". -- Per Jessen, Zürich (7.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-28 11:07, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-28 10:02, Per Jessen wrote:
This sounds similar to what I wrote earlier this month - when I was working on my mythtv install. IIRC, it was firewalld getting in the way, but I gave it up, my setup being somewhat exotic.
I remember, and tried stopping firewalld with systemd, then systemd refused to start it again with some strange error which I have forgotten. Anyway, it had no effect on dns servers.
"systemctl disable --now firewalld" is what you would have needed, but I would not have expected it to have any effect either.
"systemctl stop firewalld" should have sufficed for testing, but failed with a complaint.
No, it crashed just after systemd starts sound. Some message about "finished starting sound". I was baffled.
I did try to force an upgrade, but it only overwrote 16 packages or so, thus it was useless.
I had no idea what to do, so reinstall it was :-/ I had no rescue USB or alternative install.
Not needed, you just boot the installer again, but with "usessh=1". [1] That way it does not crank up yast right away and you can switch to a virtual console to work on the problem.
And do what? I had no clue. It probably would not have worked, anyway, root is encrypted.
[1] there might be other ways, I just happen to use this one.
I have to find out how to limit the battery charge to 50%.
Try googling "battery charge threshold linux".
Sure, found it. "lenovo L15 limit battery charge, linux" <https://askubuntu.com/questions/34452/how-can-i-limit-battery-charging-to-80-capacity> → <https://linrunner.de/tlp/> <https://linrunner.de/tlp/installation/opensuse.html> My previous Lenovo is still not supported by tlp: #Legolas:~ # tlp-stat -b #--- TLP 1.4.0 -------------------------------------------- # #+++ Battery Care #Plugin: asus #Supported features: none available #Driver usage: #* natacpi (asus_wmi) = inactive (laptop not supported) -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
On 2023-03-28 12:48, Carlos E. R. wrote:
On 2023-03-28 11:07, Per Jessen wrote:
Carlos E. R. wrote:
I had no idea what to do, so reinstall it was :-/ I had no rescue USB or alternative install.
Not needed, you just boot the installer again, but with "usessh=1". [1] That way it does not crank up yast right away and you can switch to a virtual console to work on the problem.
And do what?
I had no clue.
It probably would not have worked, anyway, root is encrypted.
Forgot to mention, that I prefer this one: <http://download.opensuse.org/distribution/leap/15.4/live/openSUSE-Leap-15.4-Rescue-CD-x86_64-Build31.185-Media.iso> which can mount encrypted filesystems with a click (and typing the password, of course). -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
Carlos E. R. wrote:
On 2023-03-28 11:07, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-28 10:02, Per Jessen wrote:
This sounds similar to what I wrote earlier this month - when I was working on my mythtv install. IIRC, it was firewalld getting in the way, but I gave it up, my setup being somewhat exotic.
I remember, and tried stopping firewalld with systemd, then systemd refused to start it again with some strange error which I have forgotten. Anyway, it had no effect on dns servers.
"systemctl disable --now firewalld" is what you would have needed, but I would not have expected it to have any effect either.
"systemctl stop firewalld" should have sufficed for testing, but failed with a complaint.
I don't think that would have been sufficient, but my situation was different. However, when basic things like "systemctl stop firewalld" fail, something is really wrong with your system.
No, it crashed just after systemd starts sound. Some message about "finished starting sound". I was baffled.
I did try to force an upgrade, but it only overwrote 16 packages or so, thus it was useless.
I had no idea what to do, so reinstall it was :-/ I had no rescue USB or alternative install.
Not needed, you just boot the installer again, but with "usessh=1". [1] That way it does not crank up yast right away and you can switch to a virtual console to work on the problem.
And do what?
Like I said earlier, with no other indications, my instinct would be to rebuild the initrd. I have seen it often enough, that the initrd built during installation isn't _quite_ right. A kernel panic on boot-up of a newly installed system suggests something is very wrong.
I had no clue. It probably would not have worked, anyway, root is encrypted.
I don't see the relevance. Once the installer system is running, it is up to you to mount root. I presume you would be able to do that. -- Per Jessen, Zürich (11.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-28 14:16, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-28 11:07, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-28 10:02, Per Jessen wrote:
This sounds similar to what I wrote earlier this month - when I was working on my mythtv install. IIRC, it was firewalld getting in the way, but I gave it up, my setup being somewhat exotic.
I remember, and tried stopping firewalld with systemd, then systemd refused to start it again with some strange error which I have forgotten. Anyway, it had no effect on dns servers.
"systemctl disable --now firewalld" is what you would have needed, but I would not have expected it to have any effect either.
"systemctl stop firewalld" should have sufficed for testing, but failed with a complaint.
I don't think that would have been sufficient, but my situation was different. However, when basic things like "systemctl stop firewalld" fail, something is really wrong with your system.
"stop" worked, it was "start" which failed, badly. I was not expecting really wrong things to happen on a system installed two hours ago...
No, it crashed just after systemd starts sound. Some message about "finished starting sound". I was baffled.
I did try to force an upgrade, but it only overwrote 16 packages or so, thus it was useless.
I had no idea what to do, so reinstall it was :-/ I had no rescue USB or alternative install.
Not needed, you just boot the installer again, but with "usessh=1". [1] That way it does not crank up yast right away and you can switch to a virtual console to work on the problem.
And do what?
Like I said earlier, with no other indications, my instinct would be to rebuild the initrd. I have seen it often enough, that the initrd built during installation isn't _quite_ right. A kernel panic on boot-up of a newly installed system suggests something is very wrong.
But by the time systemd is starting services, initrd is long gone.
I had no clue. It probably would not have worked, anyway, root is encrypted.
I don't see the relevance. Once the installer system is running, it is up to you to mount root. I presume you would be able to do that.
Have you tried to mount an encrypted root from the CLI? It is not trivial. I don't remember how to do it. Let me see... cryptsetup luksOpen $CR_DEVICE $CR_NAME mount /dev/mapper/$CR_NAME $WHERE -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
Carlos E. R. wrote:
On 2023-03-28 14:16, Per Jessen wrote:
However, when basic things like "systemctl stop firewalld" fail, something is really wrong with your system.
"stop" worked, it was "start" which failed, badly.
I was not expecting really wrong things to happen on a system installed two hours ago...
Exactly, with a kernal panic on top of that, something went really wrong.
Like I said earlier, with no other indications, my instinct would be to rebuild the initrd. I have seen it often enough, that the initrd built during installation isn't _quite_ right. A kernel panic on boot-up of a newly installed system suggests something is very wrong.
But by the time systemd is starting services, initrd is long gone.
Hmm, perhaps. Like I said, with no other indications, my instinct would be to rebuild the initrd.
I had no clue. It probably would not have worked, anyway, root is encrypted.
I don't see the relevance. Once the installer system is running, it is up to you to mount root. I presume you would be able to do that.
Have you tried to mount an encrypted root from the CLI? It is not trivial. I don't remember how to do it. Let me see...
cryptsetup luksOpen $CR_DEVICE $CR_NAME mount /dev/mapper/$CR_NAME $WHERE
Looks perfectly trivial to me. -- Per Jessen, Zürich (13.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-28 14:58, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-28 14:16, Per Jessen wrote:
However, when basic things like "systemctl stop firewalld" fail, something is really wrong with your system.
"stop" worked, it was "start" which failed, badly.
I was not expecting really wrong things to happen on a system installed two hours ago...
Exactly, with a kernal panic on top of that, something went really wrong.
But considering I copied over from the previous laptop hundreds of config files, maybe I copied something I should. One candidate is something trying to play a sound while sound was not configured. After all, it crashed right after the finished starting sound line. So now I'm copying files way more slowly, with some reboots.
Like I said earlier, with no other indications, my instinct would be to rebuild the initrd. I have seen it often enough, that the initrd built during installation isn't _quite_ right. A kernel panic on boot-up of a newly installed system suggests something is very wrong.
But by the time systemd is starting services, initrd is long gone.
Hmm, perhaps. Like I said, with no other indications, my instinct would be to rebuild the initrd.
LOL, you have a bee with that. I installed no drivers :-) Next time I will try that.
I had no clue. It probably would not have worked, anyway, root is encrypted.
I don't see the relevance. Once the installer system is running, it is up to you to mount root. I presume you would be able to do that.
Have you tried to mount an encrypted root from the CLI? It is not trivial. I don't remember how to do it. Let me see...
cryptsetup luksOpen $CR_DEVICE $CR_NAME mount /dev/mapper/$CR_NAME $WHERE
Looks perfectly trivial to me.
Yeah, because I could look it up, and had the leisure to do so, not pissed off status. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
Carlos E. R. wrote:
On 2023-03-28 14:58, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-03-28 14:16, Per Jessen wrote:
However, when basic things like "systemctl stop firewalld" fail, something is really wrong with your system.
"stop" worked, it was "start" which failed, badly.
I was not expecting really wrong things to happen on a system installed two hours ago...
Exactly, with a kernal panic on top of that, something went really wrong.
But considering I copied over from the previous laptop hundreds of config files, maybe I copied something I should.
Oh, I missed that bit. -- Per Jessen, Zürich (10.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
David C. Rankin -
Per Jessen