So after building a kernel and booting it, I've found it easiest
to take the system to single-user mode with

$ telinit 1

...which will take the system to single-user ("rescue") mode and
ask for your root password before proceeding. (Make sure you have
one set.)

Then I build the open Nvidia drivers, install them,
then remove the existing Nvidia drivers with the
following command (that I've scripted):

rmmod nvidia_drm nvidia_modeset nvidia_uvm nvidia

...which removes the modules in the proper order,
accounting for dependencies.

Finally, everything is ready to go, so:

# telinit 5

...and the system comes up in all its graphical glory.

I do it this way rather than rebooting because sometimes,
the drivers don't load right when I boot, and windows tear
when they move. If that happens, I do the
"telinit 1"-"rmmod"-"telinit 5"
dance, which has always solved the problem.

(I was pleasantly surprised to find out that systemd
knows about init runlevels. Very helpful.)

Finally, if you want to shutdown the display manager and
just use vty's with getty logins, you could

$ telinit 3

These runlevels are the same as they were with
SysV init on Linux.

--
-v

On Fri, 24 May 2024 01:15:27 -0000 (UTC), vallor wrote:

> (I was pleasantly surprised to find out that systemd knows about init
> runlevels. Very helpful.)

systemd offers better compatibility with sysvinit than some other
alternative service managers.

> Finally, if you want to shutdown the display manager and just use vty's
> with getty logins, you could
>
> $ telinit 3
>
> These runlevels are the same as they were with SysV init on Linux.

I thought, on Debian, the normal multiuser+networking runlevel was 3, not
5.

Another advantage with systemd’s symbolic target names is that they are
self-explanatory and get away from these cryptic and arbitrary numbers.

On 2024-05-23 9:15 p.m., vallor wrote:
> So after building a kernel and booting it, I've found it easiest
> to take the system to single-user mode with
>
> $ telinit 1
>
> ...which will take the system to single-user ("rescue") mode and
> ask for your root password before proceeding. (Make sure you have
> one set.)
>
> Then I build the open Nvidia drivers, install them,
> then remove the existing Nvidia drivers with the
> following command (that I've scripted):
>
> rmmod nvidia_drm nvidia_modeset nvidia_uvm nvidia
>
> ...which removes the modules in the proper order,
> accounting for dependencies.
>
> Finally, everything is ready to go, so:
>
> # telinit 5
>
> ...and the system comes up in all its graphical glory.
>
> I do it this way rather than rebooting because sometimes,
> the drivers don't load right when I boot, and windows tear
> when they move. If that happens, I do the
> "telinit 1"-"rmmod"-"telinit 5"
> dance, which has always solved the problem.
>
> (I was pleasantly surprised to find out that systemd
> knows about init runlevels. Very helpful.)
>
> Finally, if you want to shutdown the display manager and
> just use vty's with getty logins, you could
>
> $ telinit 3
>
> These runlevels are the same as they were with
> SysV init on Linux.

I'm curious: are you removing the NVIDIA proprietary drivers here or the
open ones? I'm reading that there are issues with the open-kernel ones
because they're in alpha. I was under the impression that you didn't
have too much trouble with them.

--
Andrzej (Andre) Matuch
TG: @AndrzejMatuch
Catholic, paleoconservative, Christ is king.

vallor <vallor@cultnix.org> wrote at 01:15 this Friday (GMT):
> So after building a kernel and booting it, I've found it easiest
> to take the system to single-user mode with
>
> $ telinit 1
>
> ...which will take the system to single-user ("rescue") mode and
> ask for your root password before proceeding. (Make sure you have
> one set.)
>
> Then I build the open Nvidia drivers, install them,
> then remove the existing Nvidia drivers with the
> following command (that I've scripted):
>
> rmmod nvidia_drm nvidia_modeset nvidia_uvm nvidia
>
> ...which removes the modules in the proper order,
> accounting for dependencies.
>
> Finally, everything is ready to go, so:
>
> # telinit 5
>
> ...and the system comes up in all its graphical glory.
>
> I do it this way rather than rebooting because sometimes,
> the drivers don't load right when I boot, and windows tear
> when they move. If that happens, I do the
> "telinit 1"-"rmmod"-"telinit 5"
> dance, which has always solved the problem.
>
> (I was pleasantly surprised to find out that systemd
> knows about init runlevels. Very helpful.)
>
> Finally, if you want to shutdown the display manager and
> just use vty's with getty logins, you could
>
> $ telinit 3
>
> These runlevels are the same as they were with
> SysV init on Linux.

Wow, I never knew about telinit! That will definitely be handy to
remember.
--
user <candycane> is generated from /dev/urandom

On Fri, 24 May 2024 17:15:09 -0000 (UTC), candycanearter07 wrote:

> Wow, I never knew about telinit! That will definitely be handy to
> remember.

I knew about it decades ago and had forgotten about it. On Ubuntu the man
pages says

"telinit may be used to change the SysV system runlevel. Since the concept
of SysV runlevels is obsolete the runlevel requests will be transparently
translated into systemd unit activation requests.

1, s, S Change into system rescue mode. This is translated into an
activation request for rescue.target and is equivalent to systemctl
rescue."

Despite the haters systemctl is here to stay. Might as well learn how to
use it.

On Fri, 24 May 2024 17:15:09 -0000 (UTC), candycanearter07 wrote:

> Wow, I never knew about telinit!

It’s really just there for muscle memory for older/more senior sysadmins.
Easier just to use the systemctl commands.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 21:31 this Friday (GMT):
> On Fri, 24 May 2024 17:15:09 -0000 (UTC), candycanearter07 wrote:
>
>> Wow, I never knew about telinit!
>
> It’s really just there for muscle memory for older/more senior sysadmins.
> Easier just to use the systemctl commands.

Oh. So how do you go to single user mode with systemctl commands?
--
user <candycane> is generated from /dev/urandom

On Fri, 24 May 2024 22:40:04 -0000 (UTC), candycanearter07 wrote:

> So how do you go to single user mode with systemctl commands?

The equivalent of “runlevels” is “targets”
<https://www.freedesktop.org/software/systemd/man/latest/systemd.target.html>.

On Fri, 24 May 2024 07:47:54 -0400, Andrzej Matuch <andrzej@matu.ch> wrote
in <v2pupa$2ae8o$1@dont-email.me>:

> On 2024-05-23 9:15 p.m., vallor wrote:
>> So after building a kernel and booting it, I've found it easiest to
>> take the system to single-user mode with
>>
>> $ telinit 1
>>
>> ...which will take the system to single-user ("rescue") mode and
>> ask for your root password before proceeding. (Make sure you have one
>> set.)
>>
>> Then I build the open Nvidia drivers, install them,
>> then remove the existing Nvidia drivers with the following command
>> (that I've scripted):
>>
>> rmmod nvidia_drm nvidia_modeset nvidia_uvm nvidia
>>
>> ...which removes the modules in the proper order,
>> accounting for dependencies.
>>
>> Finally, everything is ready to go, so:
>>
>> # telinit 5
>>
>> ...and the system comes up in all its graphical glory.
>>
>> I do it this way rather than rebooting because sometimes,
>> the drivers don't load right when I boot, and windows tear when they
>> move. If that happens, I do the "telinit 1"-"rmmod"-"telinit 5"
>> dance, which has always solved the problem.
>>
>> (I was pleasantly surprised to find out that systemd knows about init
>> runlevels. Very helpful.)
>>
>> Finally, if you want to shutdown the display manager and just use vty's
>> with getty logins, you could
>>
>> $ telinit 3
>>
>> These runlevels are the same as they were with SysV init on Linux.
>
> I'm curious: are you removing the NVIDIA proprietary drivers here or the
> open ones? I'm reading that there are issues with the open-kernel ones
> because they're in alpha. I was under the impression that you didn't
> have too much trouble with them.

They are the open ones from Nvidia. (Not nouveau, but the "open" version
of their proprietary drivers.)

https://github.com/NVIDIA/open-gpu-kernel-modules

--
-v

On 24 May 2024 18:33:22 GMT, rbowman <bowman@montana.com> wrote in
<lbc4rhFjnhcU2@mid.individual.net>:

> On Fri, 24 May 2024 17:15:09 -0000 (UTC), candycanearter07 wrote:
>
>> Wow, I never knew about telinit! That will definitely be handy to
>> remember.
>
> I knew about it decades ago and had forgotten about it. On Ubuntu the
> man pages says
>
> "telinit may be used to change the SysV system runlevel. Since the
> concept of SysV runlevels is obsolete the runlevel requests will be
> transparently translated into systemd unit activation requests.
>
> 1, s, S Change into system rescue mode. This is translated into an
> activation request for rescue.target and is equivalent to systemctl
> rescue."
>
> Despite the haters systemctl is here to stay. Might as well learn how to
> use it.

I'm not a hater, I just find remembering "telinit 1" easier than trying to
remember whatever systemctl incantation is needed. (But I'm old school,
so I didn't have to learn it, just know about it.)

--
-v

On Fri, 24 May 2024 23:10:13 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <v2r6ok$2hfmh$7@dont-email.me>:

> On Fri, 24 May 2024 22:40:04 -0000 (UTC), candycanearter07 wrote:
>
>> So how do you go to single user mode with systemctl commands?
>
> The equivalent of “runlevels” is “targets”
> <https://www.freedesktop.org/software/systemd/man/latest/
systemd.target.html>.

so you don't know

On Fri, 24 May 2024 22:40:04 -0000 (UTC), candycanearter07 wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 21:31 this Friday (GMT):
>> On Fri, 24 May 2024 17:15:09 -0000 (UTC), candycanearter07 wrote:
>>
>>> Wow, I never knew about telinit!
>>
>> It’s really just there for muscle memory for older/more senior
>> sysadmins.
>> Easier just to use the systemctl commands.
>
>
> Oh. So how do you go to single user mode with systemctl commands?

rescue
Enter rescue mode. This is equivalent to systemctl isolate rescue.target.
This operation is blocking by default, use --no-block to request
asynchronous behavior.

On Fri, 24 May 2024 23:10:13 -0000 (UTC), Lawrence D'Oliveiro wrote:

> On Fri, 24 May 2024 22:40:04 -0000 (UTC), candycanearter07 wrote:
>
>> So how do you go to single user mode with systemctl commands?
>
> The equivalent of “runlevels” is “targets”
> <https://www.freedesktop.org/software/systemd/man/latest/
systemd.target.html>.

That document is remarkably useless. All it tells you is how to create a
"target". It says nothing about what the default targets even are, let
alone anything at all about which ones map to the runlevels. I suppose
the target files are created by each distro instead of shipping with
Systemd, otherwise why wouldn't they be listed anywhere?

Double checking, I found that targets I know to exist have no man pages.
For example, I know there's a "multi-user.target".

The only way to find out what all the targets are is to search the
filesystem for them, and there are an absolute fuckton of them, mostly in
/lib/systemd and /usr/lib/systemd, but they appear in other places, too.

I happened to notice files with names like "runlevel5.target". There
seems to be one for each runlevel, at least on Ubuntu. Lucky me
for noticing, I guess.

I couldn't guess how to write a target to bring back /etc/rc.local,
which used to be supported by Systemd but they got rid of it because
it was all four of the Four Olds. Fortunately, I still have some VMs
in Google Cloud that are old enough to have the .target file for
that (or maybe it'll be a .service file, who knows), so I'd just have
to download it.

On Sat, 25 May 2024 06:22:20 -0000 (UTC), Sebastian Wells wrote:

> On Fri, 24 May 2024 23:10:13 -0000 (UTC), Lawrence D'Oliveiro wrote:
>
>> The equivalent of “runlevels” is “targets”
>> <https://www.freedesktop.org/software/systemd/man/latest/systemd.target.html>.
>
> That document is remarkably useless. All it tells you is how to
> create a "target". It says nothing about what the default targets
> even are ...

If you’d actually read the doc, you would have seen this part

Importantly, see systemd.special(7) for examples and descriptions
of standard systemd targets.

which gives a link to this page
<https://www.freedesktop.org/software/systemd/man/latest/systemd.special.html>.

On 2024-05-24 8:38 p.m., vallor wrote:
> On Fri, 24 May 2024 07:47:54 -0400, Andrzej Matuch <andrzej@matu.ch> wrote
> in <v2pupa$2ae8o$1@dont-email.me>:
>
>> On 2024-05-23 9:15 p.m., vallor wrote:
>>> So after building a kernel and booting it, I've found it easiest to
>>> take the system to single-user mode with
>>>
>>> $ telinit 1
>>>
>>> ...which will take the system to single-user ("rescue") mode and
>>> ask for your root password before proceeding. (Make sure you have one
>>> set.)
>>>
>>> Then I build the open Nvidia drivers, install them,
>>> then remove the existing Nvidia drivers with the following command
>>> (that I've scripted):
>>>
>>> rmmod nvidia_drm nvidia_modeset nvidia_uvm nvidia
>>>
>>> ...which removes the modules in the proper order,
>>> accounting for dependencies.
>>>
>>> Finally, everything is ready to go, so:
>>>
>>> # telinit 5
>>>
>>> ...and the system comes up in all its graphical glory.
>>>
>>> I do it this way rather than rebooting because sometimes,
>>> the drivers don't load right when I boot, and windows tear when they
>>> move. If that happens, I do the "telinit 1"-"rmmod"-"telinit 5"
>>> dance, which has always solved the problem.
>>>
>>> (I was pleasantly surprised to find out that systemd knows about init
>>> runlevels. Very helpful.)
>>>
>>> Finally, if you want to shutdown the display manager and just use vty's
>>> with getty logins, you could
>>>
>>> $ telinit 3
>>>
>>> These runlevels are the same as they were with SysV init on Linux.
>>
>> I'm curious: are you removing the NVIDIA proprietary drivers here or the
>> open ones? I'm reading that there are issues with the open-kernel ones
>> because they're in alpha. I was under the impression that you didn't
>> have too much trouble with them.
>
> They are the open ones from Nvidia. (Not nouveau, but the "open" version
> of their proprietary drivers.)
>
> https://github.com/NVIDIA/open-gpu-kernel-modules

Why are you removing them? Were they problematic?

--
Andrzej (Andre) Matuch
TG: @AndrzejMatuch
Catholic, paleoconservative, Christ is king.

On Sat, 25 May 2024 07:35:12 -0400, Andrzej Matuch <andrzej@matu.ch> wrote
in <v2sidg$2rbb0$12@dont-email.me>:

> On 2024-05-24 8:38 p.m., vallor wrote:
>> On Fri, 24 May 2024 07:47:54 -0400, Andrzej Matuch <andrzej@matu.ch> wrote
>> in <v2pupa$2ae8o$1@dont-email.me>:
>>
>>> On 2024-05-23 9:15 p.m., vallor wrote:
>>>> So after building a kernel and booting it, I've found it easiest to
>>>> take the system to single-user mode with
>>>>
>>>> $ telinit 1
>>>>
>>>> ...which will take the system to single-user ("rescue") mode and
>>>> ask for your root password before proceeding. (Make sure you have one
>>>> set.)
>>>>
>>>> Then I build the open Nvidia drivers, install them,
>>>> then remove the existing Nvidia drivers with the following command
>>>> (that I've scripted):
>>>>
>>>> rmmod nvidia_drm nvidia_modeset nvidia_uvm nvidia
>>>>
>>>> ...which removes the modules in the proper order,
>>>> accounting for dependencies.
>>>>
>>>> Finally, everything is ready to go, so:
>>>>
>>>> # telinit 5
>>>>
>>>> ...and the system comes up in all its graphical glory.
>>>>
>>>> I do it this way rather than rebooting because sometimes,
>>>> the drivers don't load right when I boot, and windows tear when they
>>>> move. If that happens, I do the "telinit 1"-"rmmod"-"telinit 5"
>>>> dance, which has always solved the problem.
>>>>
>>>> (I was pleasantly surprised to find out that systemd knows about init
>>>> runlevels. Very helpful.)
>>>>
>>>> Finally, if you want to shutdown the display manager and just use vty's
>>>> with getty logins, you could
>>>>
>>>> $ telinit 3
>>>>
>>>> These runlevels are the same as they were with SysV init on Linux.
>>>
>>> I'm curious: are you removing the NVIDIA proprietary drivers here or the
>>> open ones? I'm reading that there are issues with the open-kernel ones
>>> because they're in alpha. I was under the impression that you didn't
>>> have too much trouble with them.
>>
>> They are the open ones from Nvidia. (Not nouveau, but the "open" version
>> of their proprietary drivers.)
>>
>> https://github.com/NVIDIA/open-gpu-kernel-modules
>
> Why are you removing them? Were they problematic?

Hello:
>>> I do it this way rather than rebooting because sometimes,
>>> the drivers don't load right when I boot, and windows tear when they
>>> move. If that happens, I do the "telinit 1"-"rmmod"-"telinit 5"
>>> dance, which has always solved the problem.

I can't explain why removing the drivers and putting them back
fixes it -- just know it works (thank goodness).

I've reported the problem to Nvidia, haven't anything from them.

--
-v

On 2024-05-25 4:39 p.m., vallor wrote:
> On Sat, 25 May 2024 07:35:12 -0400, Andrzej Matuch <andrzej@matu.ch> wrote
> in <v2sidg$2rbb0$12@dont-email.me>:
>
>> On 2024-05-24 8:38 p.m., vallor wrote:
>>> On Fri, 24 May 2024 07:47:54 -0400, Andrzej Matuch <andrzej@matu.ch> wrote
>>> in <v2pupa$2ae8o$1@dont-email.me>:
>>>
>>>> On 2024-05-23 9:15 p.m., vallor wrote:
>>>>> So after building a kernel and booting it, I've found it easiest to
>>>>> take the system to single-user mode with
>>>>>
>>>>> $ telinit 1
>>>>>
>>>>> ...which will take the system to single-user ("rescue") mode and
>>>>> ask for your root password before proceeding. (Make sure you have one
>>>>> set.)
>>>>>
>>>>> Then I build the open Nvidia drivers, install them,
>>>>> then remove the existing Nvidia drivers with the following command
>>>>> (that I've scripted):
>>>>>
>>>>> rmmod nvidia_drm nvidia_modeset nvidia_uvm nvidia
>>>>>
>>>>> ...which removes the modules in the proper order,
>>>>> accounting for dependencies.
>>>>>
>>>>> Finally, everything is ready to go, so:
>>>>>
>>>>> # telinit 5
>>>>>
>>>>> ...and the system comes up in all its graphical glory.
>>>>>
>>>>> I do it this way rather than rebooting because sometimes,
>>>>> the drivers don't load right when I boot, and windows tear when they
>>>>> move. If that happens, I do the "telinit 1"-"rmmod"-"telinit 5"
>>>>> dance, which has always solved the problem.
>>>>>
>>>>> (I was pleasantly surprised to find out that systemd knows about init
>>>>> runlevels. Very helpful.)
>>>>>
>>>>> Finally, if you want to shutdown the display manager and just use vty's
>>>>> with getty logins, you could
>>>>>
>>>>> $ telinit 3
>>>>>
>>>>> These runlevels are the same as they were with SysV init on Linux.
>>>>
>>>> I'm curious: are you removing the NVIDIA proprietary drivers here or the
>>>> open ones? I'm reading that there are issues with the open-kernel ones
>>>> because they're in alpha. I was under the impression that you didn't
>>>> have too much trouble with them.
>>>
>>> They are the open ones from Nvidia. (Not nouveau, but the "open" version
>>> of their proprietary drivers.)
>>>
>>> https://github.com/NVIDIA/open-gpu-kernel-modules
>>
>> Why are you removing them? Were they problematic?
>
> Hello:
>>>> I do it this way rather than rebooting because sometimes,
>>>> the drivers don't load right when I boot, and windows tear when they
>>>> move. If that happens, I do the "telinit 1"-"rmmod"-"telinit 5"
>>>> dance, which has always solved the problem.
>
> I can't explain why removing the drivers and putting them back
> fixes it -- just know it works (thank goodness).
>
> I've reported the problem to Nvidia, haven't anything from them.

So, at least for the immediate future, proprietary drivers are going to
be the only way to get an acceptable experience with NVIDIA. It's too
bad. Apparently, Linux is absolute heaven with AMD hardware.

--
Andrzej (Andre) Matuch
TG: @AndrzejMatuch
Catholic, paleoconservative, Christ is king.

rbowman <bowman@montana.com> wrote at 02:52 this Saturday (GMT):
> On Fri, 24 May 2024 22:40:04 -0000 (UTC), candycanearter07 wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 21:31 this Friday (GMT):
>>> On Fri, 24 May 2024 17:15:09 -0000 (UTC), candycanearter07 wrote:
>>>
>>>> Wow, I never knew about telinit!
>>>
>>> It’s really just there for muscle memory for older/more senior
>>> sysadmins.
>>> Easier just to use the systemctl commands.
>>
>>
>> Oh. So how do you go to single user mode with systemctl commands?
>
> rescue
> Enter rescue mode. This is equivalent to systemctl isolate rescue.target.
> This operation is blocking by default, use --no-block to request
> asynchronous behavior.

Ah thanks, good to know :D
--
user <candycane> is generated from /dev/urandom

On Mon, 27 May 2024 02:00:05 -0000 (UTC), candycanearter07
<candycanearter07@candycanearter07.nomail.afraid> wrote in
<slrnv57q3n.pvf.candycanearter07@candydeb.host.invalid>:

> rbowman <bowman@montana.com> wrote at 02:52 this Saturday (GMT):
>> On Fri, 24 May 2024 22:40:04 -0000 (UTC), candycanearter07 wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 21:31 this Friday (GMT):
>>>> On Fri, 24 May 2024 17:15:09 -0000 (UTC), candycanearter07 wrote:
>>>>
>>>>> Wow, I never knew about telinit!
>>>>
>>>> It’s really just there for muscle memory for older/more senior
>>>> sysadmins.
>>>> Easier just to use the systemctl commands.
>>>
>>>
>>> Oh. So how do you go to single user mode with systemctl commands?
>>
>> rescue
>> Enter rescue mode. This is equivalent to systemctl isolate rescue.target.
>> This operation is blocking by default, use --no-block to request
>> asynchronous behavior.
>
>
> Ah thanks, good to know :D

I think I'll keep using "telinit". 😏️

--
-v

On Mon, 27 May 2024 03:11:38 -0000 (UTC), vallor wrote:

> I think I'll keep using "telinit". 😏️

At least systemd gives you the choice. Some other init systems don’t.