| View previous topic :: View next topic |
| Author |
Message |
ilightwas
n00b
Joined: 07 Jul 2020
Posts: 9
Location: Brazil
|
 Posted: Fri Sep 08, 2023 2:47 am Post subject: A funny predicament |
 |
|
To start off, I never used gentoo with systemd. Nothing against it, just started with openrc and stuck with it.
A few days ago I decided to switch to systemd, even if it's just for the sake of learning more about it.. I know it's widely used in other distros but I am an outlier that had gentoo as the first linux distro and never distro hopped.
So, I got to changing the system to use systemd, did my research, applied all the changes, did all the rebuilds, everything was fine. So before doing the reboot to start using it, I unmerged openrc since it was ready to be removed.
Did the old --depclean and gone was openrc. Now to reboot..
doas reboot
A red text splash saying something about systemd not being running (don't quite remember it, since this happened a few days ago). I tried doing all sorts of reboot commands, which all failed complaining about systemd. To be honest I just started laughing at the situation and eventually just hit the hard reset button.
Systemd then booted all fine and dandy.
After a while it got me thinking about how would I have approached the situation differently to manage to reboot the system. I guess to start off the right way would been probably to unmerge openrc after the reboot. I did try emerging it again in the hopes to gain 'access back' to it but it was blocked by the changes to systemd so I decided not to undo everything.
This state that the system can't reboot with most common reboot commands is a curious case study for me. Somewhat lost access to part of the system.
I'm curious about what approach you all would have taken.
The challenge: not hitting the hard reset
If anything, I feel I might learn a thing or two from you guys with this thread. |
|
| Back to top |
|
 |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Fri Sep 08, 2023 6:55 am Post subject: |
|
|
That systemd wasn't running makes sense, so I'd guess that's why it couldn't shut down. And as you mentioned, uninstalling openrc after rebooting would likely have been the correct path.
I generally take the approach of making sure changes work before finalizing them.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Banana
Moderator
Joined: 21 May 2004
Posts: 1739
Location: Germany
|
|
| Back to top |
|
|
ilightwas
n00b
Joined: 07 Jul 2020
Posts: 9
Location: Brazil
|
| Posted: Fri Sep 08, 2023 7:38 am Post subject: |
|
|
| pjp wrote: | That systemd wasn't running makes sense, so I'd guess that's why it couldn't shut down. And as you mentioned, uninstalling openrc after rebooting would likely have been the correct path.
I generally take the approach of making sure changes work before finalizing them. |
I was surprised. The changes were ok. After the reboot there was nothing out of the ordinary. It was really only that window between removing openrc and rebooting.
| Banana wrote: | | I would just made a backup of my data and settings and did a fresh install with systemd. I fear there is too much new, confusing and different config to easily get lost in what is what. |
I did an in place switch to understand better the changes. It's not really that bad, at first I thought so too. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3434
|
| Posted: Fri Sep 08, 2023 9:56 am Post subject: |
|
|
When you issue a command to shutdown, what actually happens is you're telling init to enter runlevel 0 (reboot is runlevel 6).
Init then shuts down all the services and instructs kernel to power down.
It looks like systemd - surprise, surprise - is not compatible with sysvinit used by openrc. This means you can't use systemd's interface to change runlevel of sysvinit, which at this point was still in RAM and maintaining your runtime environment.
| Quote: | | The challenge: not hitting the hard reset |
trigger kexec if your system supports it
or press Alt+SysRQ+B
or send reboot request via /proc
or reboot -f (does not go through init, just tells the kernel to kill itself)
Or find some way to make sysvinit exec systemd init, handing over PID 1. Just kidding, there is no point in changing init while services are running, you'd just get your system to an invalid state. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 934
Location: Romania
|
| Posted: Fri Sep 08, 2023 10:10 am Post subject: Re: A funny predicament |
|
|
| ilightwas wrote: |
A few days ago I decided to switch to systemd, even if it's just for the sake of learning more about it.
|
Why did you think that systemd was worth using/learning?
If you really didn't have to touch systemd before, consider yourself lucky.
If you really wanted to tackle the devil yourself, I would have suggested using a different machine to test.
| ilightwas wrote: |
I'm curious about what approach you all would have taken.
|
I wouldn't have installed systemd.
From my experience, it's a bloated pile of garbage, forced down user's throats for political reasons, not technical reasons.
Tell us, what is easier/faster, going from openrc to systemd or from systemd to openrc?
Come back to this thread after you first have to chroot after an update or when you get bootup ads.
This thread shows that we have too few systemd threads.
Also, give us your opinion on which init system you like better.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
ilightwas
n00b
Joined: 07 Jul 2020
Posts: 9
Location: Brazil
|
| Posted: Fri Sep 08, 2023 10:38 am Post subject: |
|
|
| szatox wrote: |
| Quote: | | The challenge: not hitting the hard reset |
trigger kexec if your system supports it
or press Alt+SysRQ+B
or send reboot request via /proc
or reboot -f (does not go through init, just tells the kernel to kill itself)
Or find some way to make sysvinit exec systemd init, handing over PID 1. Just kidding, there is no point in changing init while services are running, you'd just get your system to an invalid state. |
I knew I was going to learn something new. That was exactly what I was expecting to hear.
I feel like I will mock up a system in the same state just to try these.
Thank you for the earlier explanation and the ideas |
|
| Back to top |
|
|
ilightwas
n00b
Joined: 07 Jul 2020
Posts: 9
Location: Brazil
|
| Posted: Fri Sep 08, 2023 10:42 am Post subject: Re: A funny predicament |
|
|
| stefan11111 wrote: |
Why did you think that systemd was worth using/learning?
|
To be honest, if were not it taking over all the other distros with it's peculiarities and features(aka bloat) I wouldn't worry about it.
But I see that for anything other than my bubble I would need to understand it better. And I mean more exactly the everything around it, not just the basic notion of managing services, that's pretty mundane.
Unfortunately it is what it is.
| stefan11111 wrote: | | ilightwas wrote: |
I'm curious about what approach you all would have taken.
|
I wouldn't have installed systemd.
|
LOL you got me haha
| stefan11111 wrote: |
From my experience, it's a bloated pile of garbage, forced down user's throats for political reasons, not technical reasons.
Tell us, what is easier/faster, going from openrc to systemd or from systemd to openrc?
Come back to this thread after you first have to chroot after an update or when you get bootup ads.
This thread shows that we have too few systemd threads.
Also, give us your opinion on which init system you like better. |
I guess openrc is straight forward, since systemd seems to be more of a enviroment than just the init system.
What do you mean bootup ads? you mean ads like.. ads as in advertisement?
Also if you could give me an overview of why there would be an issue with chroot that be great, always eager to learn. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 934
Location: Romania
|
| Posted: Fri Sep 08, 2023 10:47 am Post subject: Re: A funny predicament |
|
|
| ilightwas wrote: |
What do you mean bootup ads? you mean ads like.. ads as in advertisement?
|
That was half-joking. Yes, like in advertisement. In a couple of years, that might no longer be a joke.
| ilightwas wrote: |
Also if you could give me an overview of why there would be an issue with chroot that be great, always eager to learn. |
No problems with chroot. I meant having to chroot from a rescue usb because a systemd update broke something.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 934
Location: Romania
|
| Posted: Fri Sep 08, 2023 10:58 am Post subject: |
|
|
| szatox wrote: |
| Quote: | | The challenge: not hitting the hard reset |
trigger kexec if your system supports it
or press Alt+SysRQ+B
or send reboot request via /proc
or reboot -f (does not go through init, just tells the kernel to kill itself)
|
Don't know about reboot -f, but the others need kernel support.
kexec needs kexec to be enabled.
SysRQ needs magic SysRQ.
/proc needs to be enabled.
AFAIK only /proc is enabled by default, the rest are disabled by default.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
ilightwas
n00b
Joined: 07 Jul 2020
Posts: 9
Location: Brazil
|
| Posted: Fri Sep 08, 2023 10:59 am Post subject: Re: A funny predicament |
|
|
| stefan11111 wrote: | | ilightwas wrote: |
What do you mean bootup ads? you mean ads like.. ads as in advertisement?
|
That was half-joking. Yes, like in advertisement. In a couple of years, that might no longer be a joke.
|
Ohh right I get it now. I was thinking... "did they actually do that wtf, I'm unaware" lol
That would the dawn of systemd distros,(no not linux) and "wait 5s to skip this video and start your services" lol
| stefan11111 wrote: |
| ilightwas wrote: |
Also if you could give me an overview of why there would be an issue with chroot that be great, always eager to learn. |
No problems with chroot. I meant having to chroot from a rescue usb because a systemd update broke something. |
That would be a new 'experience'.. never ever my system got broken because of openrc updating. |
|
| Back to top |
|
|
Leonardo.b
Guru
Joined: 10 Oct 2020
Posts: 308
|
| Posted: Fri Sep 08, 2023 11:03 am Post subject: |
|
|
Before removing old init:
| Code: | | mv /sbin/shutdown /sbin/shutdown_old |
... or whatever shutdown points to.
Alternative: install new init, reboot, and finally remove old init.
Several init systems alongside are possible too. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1701
Location: South America
|
| Posted: Fri Sep 08, 2023 8:41 pm Post subject: |
|
|
Others have mentioned what happened here, which I'd like to elaborate on. All init systems can reboot, but the technical details about how exactly one tells that to the component in charge of doing the reboot vary between them. And yes, sysvinit's way is different to systemd's way. So in general one needs both the components of the old init system still in place, to shutdown cleanly and trigger a reboot, and the components of the new init system, so that it can take charge after the reboot.
This means:
| Leonardo.b wrote: | | Alternative: install new init, reboot, and finally remove old init. |
There is one complication, though. For convenience, init systems want to provide tools named "init", '"shutdown", "reboot", etc. Usually in the form of symbolic links or wrapper scripts. And obviously if there is more that one package installed that provides an init system, at any time only one of them can actually install tools with those names. sysvinit is also special in this aspect because its "init", "shutdown", "reboot", etc. are the actual ELF binaries that perform those functions, not wrappers or symlinks.
Unsetting Gentoo's sysv-utils USE flag can be used to temporarily avoid these clashes.
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5117
Location: Bavaria
|
| Posted: Fri Sep 08, 2023 9:09 pm Post subject: |
|
|
I think the cleanest and least problematic procedure would be:
- Shutdown with old init system
- Boot with GentooMinimalInstCD
- Chroot into your system like you do with a new installation
- Do all changes
- Boot/Systemstart with new init system |
|
| Back to top |
|
|
|
Gentoo Chat
