| View previous topic :: View next topic |
| Author |
Message |
tld
Veteran
Joined: 09 Dec 2003
Posts: 1848
|
 Posted: Sun Dec 27, 2020 5:59 pm Post subject: Runlevel mess in new install? |
 |
|
HELP! I'm doing my first new install in like 13 years on a new AMD machine. For the most part it seemed to be going great. However I've ended up with a complete mess I just don't understand related to the runlevels.
When I went to add my net.eth0 to the default runlevel I got an error because there IS no default runlevel and I have no idea why. I can see that clearly IS in the stage3 tarball I started with. I extracted the runlevels directory out of the tarball to a temporary location to see how they differed and now I see that there's a LOT missing even under the runlevels that are there. Something deleted a lot of stuff and I have NO idea what.
Here's what was in the tarball: | Code: | cd tmp/etc/runlevels/
find . | sort
.
./boot
./boot/binfmt
./boot/bootmisc
./boot/fsck
./boot/hostname
./boot/hwclock
./boot/keymaps
./boot/localmount
./boot/loopback
./boot/modules
./boot/mtab
./boot/procfs
./boot/root
./boot/save-keymaps
./boot/save-termencoding
./boot/stmpfiles-setup
./boot/swap
./boot/sysctl
./boot/termencoding
./boot/urandom
./default
./default/local
./default/netmount
./nonetwork
./nonetwork/local
./shutdown
./shutdown/killprocs
./shutdown/mount-ro
./shutdown/savecache
./sysinit
./sysinit/cgroups
./sysinit/devfs
./sysinit/dmesg
./sysinit/kmod-static-nodes
./sysinit/stmpfiles-dev
./sysinit/sysfs
./sysinit/udev
./sysinit/udev-trigger |
...and here's what I have now: | Code: | cd /etc/runlevels/
find . | sort
.
./boot
./boot/stmpfiles-setup
./shutdown
./shutdown/killprocs
./shutdown/mount-ro
./shutdown/savecache
./sysinit
./sysinit/devfs
./sysinit/dmesg
./sysinit/kmod-static-nodes
./sysinit/stmpfiles-dev
./sysinit/sysfs
./sysinit/tmpfiles.dev
./sysinit/udev
./sysinit/udev-trigger |
On a semi related note, I also see that I have stmpfiles-setup under the boot runlevel which came from sys-apps/systemd-tmpfiles. On my old system I have virtual/tmpfiles in my /etc/portage/profile/package.provided to prevent that bulls*** dependency. I'm not sure if that's related.
Again, more importantly something wiped out a lot of stuff there and I have no idea what. One small caveat here is that, like many here I'm using an old version of openrc (sys-apps/openrc-0.17) from my local overlay and did downgrade from the original. I can't believe that would have done this.
Does anyone have any clue what happened here? I could get that back from the tarball but it scares the crap out of me and I'm wondering what else might have gone wrong. Beyond baffled.
Thanks!
Tom |
|
| Back to top |
|
 |
tld
Veteran
Joined: 09 Dec 2003
Posts: 1848
|
| Posted: Sun Dec 27, 2020 6:26 pm Post subject: |
|
|
For now I've recovered /etc/runlevels from the tarball which should be fine as the net.eth0 would have been the only change to it that I'm aware of. I've also unmerged sys-apps/systemd-tmpfiles and virtual/tmpfiles, and added "virtual/tmpfiles-0-r1" to /etc/portage/profile/package.provided to get rid of that. But wow...something did a seriously bogus delete there, and this install has otherwise been totally by the book. To say that doesn't give me a good feeling would be the understatement of the century. Again, any ideas as to what might have happened there would be welcome.
Tom |
|
| Back to top |
|
|
alamahant
Advocate
Joined: 23 Mar 2019
Posts: 3927
|
| Posted: Sun Dec 27, 2020 9:14 pm Post subject: |
|
|
What advive can i give to a veteran but If I were you i would ditch the entire install,reformat and remount the partitions,move the tarball inside the chroot directory,cd into it,tar -xf the trball in a simple way without playing with runlevels etc and use the current version of openrc provided by the tarball.
Chroot and proceed...
Why would i prefer to complicate my life?
_________________
 |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1848
|
| Posted: Sun Dec 27, 2020 10:29 pm Post subject: |
|
|
That sounds pretty extreme. Since I posted that I've actually finished up and have rebooted to the new system and everything certainly seems fine. For one thing, I'm not going with that current openrc for sure. Like several others here I got fed up with all the surprise changes to openrc trying to make it more systemd-like.
I'm wondering if there's something that got tripped up in the uninstall of sys-apps/openrc-0.42.1 that occurred during the downgrade to sys-apps/openrc-0.17. Looking into that.
Tom |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Dec 27, 2020 10:36 pm Post subject: |
|
|
| I have absolutely nothing installed in \boot related to run-levels. I think you extracted to the wrong place. |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1848
|
| Posted: Sun Dec 27, 2020 11:31 pm Post subject: |
|
|
| Tony0945 wrote: | | I have absolutely nothing installed in \boot related to run-levels. I think you extracted to the wrong place. |
You totally lost me there. I think you must have misread my post. I don't think I have anything either but I don't even what "boot" you're referring to.
I think I know what might have happened here: The ebuild for openrc-0.17 does all sorts of stuff backing up and removing the existing runlevels etc. See the stuff around line 133 here:
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/openrc/openrc-0.17.ebuild?id=782ebc87648969f950b67e14ee177aca0b14bc58
To further complicate things, I think the openrc-0.17.ebuild I have in my local overlay may not be the one I should be using. It's clearly older/different from the above link. I can't recall even where I where I got it from, but when I added it to my old systems, I probably already had openrc-0.17 installed, so that ebuild was probably never even used. It's possible that there's something wrong with what that did around the runlevels. Again, I was able to get them back so I appear to be OK now.
Tony0945: I see that you run (or at least used to run) openrc-0.17. Does the above link appear to be the one you're using?
Thanks!
Tom |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22867
|
| Posted: Mon Dec 28, 2020 12:26 am Post subject: |
|
|
| tld wrote: | | Tony0945 wrote: | | I have absolutely nothing installed in \boot related to run-levels. I think you extracted to the wrong place. |
You totally lost me there. I think you must have misread my post. I don't think I have anything either but I don't even what "boot" you're referring to. |
You showed the contents of the runlevel boot. I think that Tony misread your post as describing runlevels in the /boot directory normally used by grub/lilo/syslinux, and commented accordingly. You were actually describing a directory named boot, under the runlevels directory, which is a traditional place for openrc to trigger scripts that need to start early during boot. |
|
| Back to top |
|
|
colo-des
Tux's lil' helper
Joined: 20 May 2011
Posts: 97
|
| Posted: Mon Dec 28, 2020 1:08 am Post subject: |
|
|
I have been reading many threads in the forum and indeed /tmp with opentmpfiles
to make /tmp non-volatile on reboots you have to have an application
either premeditated with the runlevel /boot directly, or with the network chip in UEFI mode.
I am the only one who saw the temporary folders firefox creates when run with
alphanumeric names for tracking? ... if those survive the boot they cannot be read
in early stages of booting or by UEFI and calling home directly with the network chip
when there are no ways to log or audit anything?
https://wiki.gentoo.org/wiki/Tmpfs#systemd
$ mountpoint /tmp
/tmp is not a mount point
At the moment I use a ram disk in fstab to make it volatile, I don't know if openrc is really respecting it.
$ cat /etc/fstab |grep 4G
none /tmp tmpfs rw,nosuid,noatime,nodev,size=4G,mode=1777 0 0
$ mountpoint /tmp
/tmp is a mount point
Last edited by colo-des on Mon Dec 28, 2020 4:09 am; edited 1 time in total |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1848
|
| Posted: Mon Dec 28, 2020 1:25 am Post subject: |
|
|
| Hu wrote: | | I think that Tony misread your post as describing runlevels in the /boot directory normally used by grub/lilo/syslinux, and commented accordingly. You were actually describing a directory named boot, under the runlevels directory, which is a traditional place for openrc to trigger scripts that need to start early during boot. |
Right...my post was probably a little confusing. The first "find" I have above was from the runlevels directory that I extracted from the stage3 tarball to a temporary location, which was just to see exactly what was originally in there from the tarball. The second find was from /etc/runlevels to show what I ended up with after things got deleted.
Tom |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Dec 28, 2020 1:49 am Post subject: |
|
|
| tld wrote: | | Tony0945: I see that you run (or at least used to run) openrc-0.17. Does the above link appear to be the one you're using? |
First: yes, what Hu said.
I saved my distfile a long time ago, before git was a thing. The only thing I've added was a symlink for tmpfiles that someone (I think Anon-E-moose) suggested.
| Code: | ~ $ ls -l /bin/tmpfiles
lrwxrwxrwx 1 root root 22 Dec 1 20:38 /bin/tmpfiles -> /lib/rc/sh/tmpfiles.sh |
|
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1848
|
| Posted: Mon Dec 28, 2020 5:28 am Post subject: |
|
|
| Tony0945 wrote: | I saved my distfile a long time ago, before git was a thing. The only thing I've added was a symlink for tmpfiles that someone (I think Anon-E-moose) suggested.
| Code: | ~ $ ls -l /bin/tmpfiles
lrwxrwxrwx 1 root root 22 Dec 1 20:38 /bin/tmpfiles -> /lib/rc/sh/tmpfiles.sh |
|
On my old system I must have done the same as I have that as well. I just added that to the new system, but in that case it had to use "lib64" in place of "lib", since I left multi-lib enabled.
I actually just replaced my openrc-0.17.ebuild with the version from that link above, though I had to comment out a section in the pkg_postinst() that wasn't needed anymore and was attempting to use "path_exists" which no longer works. I just tried re-emerging openrc and this time /etc/runlevels was left completely intact...so I think I'm all good there.
Thanks!
Tom |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Dec 28, 2020 3:07 pm Post subject: |
|
|
| You are welcome! For a package that has so many versions, there is a singular lack of documentation on version changes and the impact. A good upstream does that and Gentoo is upstream for OpenRC. I have forked 0.17 to a new name on my local overlay for that reason. As I say, the only change I made was adding the symlink. On my rescue partition, I have the latest version of OpenRC. It no longer supports "service", so I manually symlinked /sbin/rc-service to /sbin/service. Someone pointed out that I could have used an alias also. |
|
| Back to top |
|
|
|
Installing Gentoo
