public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael <confabulate@kintzios.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] How to find out all openrc dependencies?
Date: Sun, 14 Apr 2024 09:24:54 +0100	[thread overview]
Message-ID: <5773352.DvuYhMxLoT@rogueboard> (raw)
In-Reply-To: <4565188.LvFx2qVVIh@persephone>

[-- Attachment #1: Type: text/plain, Size: 3792 bytes --]

On Sunday, 14 April 2024 08:28:07 BST J. Roeleveld wrote:
> On Thursday, 11 April 2024 12:10:31 CEST Michael wrote:
> > On Thursday, 11 April 2024 10:48:15 BST J. Roeleveld wrote:
> > > On Thursday, 11 April 2024 11:35:10 CEST Michael wrote:
> > > > On Thursday, 11 April 2024 06:19:57 BST J. Roeleveld wrote:
> > > > > Hi all,
> > > > > 
> > > > > For a while I've been seeing the following ERROR-messages when
> > > > > booting
> > > > > 1
> > > > > of
> > > > > my systems:
> > > > > 
> > > > > * ERROR: cannot start multipathd as localmount would not start
> > > > > 
> > > > >  * ERROR: cannot start zfs-import as localmount would not start
> > > > > 
> > > > > This isn't a big concern as these services will start correctly
> > > > > later:
> > > > > 
> > > > > INIT: Entering runlevel: 3
> > > > > 
> > > > >  * Starting multipathd ...
> > > > >  [ ok ]
> > > > >  * Importing ZFS pool(s)  ...
> > > > >  [ ok ]
> > > > > 
> > > > > But I am trying to find the cause of these errors as they are
> > > > > preventing
> > > > > parallel-start from actually working correctly.
> > > > > 
> > > > > When I check with "rc-depend", I don't see an obious cause:
> > > > > 
> > > > > # /lib/rc/bin/rc-depend multipathd
> > > > > sysfs devfs udev udev-trigger modules fsck root localmount
> > > > > multipathd
> > > > > 
> > > > > # /lib/rc/bin/rc-depend localmount
> > > > > sysfs devfs udev udev-trigger modules fsck root localmount
> > > > > 
> > > > > # /lib/rc/bin/rc-depend zfs-import
> > > > > multipath sysfs devfs udev udev-trigger modules fsck root localmount
> > > > > multipathd zfs-import
> > > > > 
> > > > > # /lib/rc/bin/rc-depend multipath
> > > > > multipath
> > > > > 
> > > > > From how I read these, it should be able to start "localmount"
> > > > > properly
> > > > > before even trying to start "multipathd" and "zfs-import"
> > > > > There is also no technical dependency for "localmount" (the root
> > > > > filesystem
> > > > > is not on ZFS on this system)
> > > > > 
> > > > > Any help/suggestions on how to find the cause would be appreciated.
> > > > > 
> > > > > --
> > > > > Joost
> > > > 
> > > > Check if hwclock is in the boot runlevel:
> > > > 
> > > > rc-update -s -v | grep hwclock
> > > 
> > > What does "hwclock" got to do with this?
> > > It has no dependency with multipathd, zfs-import, localmount or anything
> > > else that is showing an error.
> > > 
> > > --
> > > Joost
> > 
> > Our systems are certainly different, but I noticed this dependency on my
> > localmount which is missing on yours:
> > 
> > # /lib/rc/bin/rc-depend localmount
> > sysfs devfs udev udev-trigger hwclock modules fsck root dmcrypt localmount
> > 
> >                               ^^^^^^^
> > 
> > Have you compared your system services which has this problem, with other
> > systems of yours which can startup properly?
> 
> Adding additional dependencies into the tree is more likely to cause further
> issues. I am actually looking for how to quickly find out which dependency
> is causing a circular dependency issue as the first time it thinks it needs
> to start a service it fails. But the 2nd time it starts, it goes correctly.
> 
> I removed hwclock from ALL VMs as they don't actually have a hwclock.
> 
> I did find out the actual cause of the problem through a lot of trial and
> error, 

Out of curiosity - what was the cause of this?  I have only come across 
hwclock on my installations (not VMs).


> but this is not really useful in actually quickly finding the
> problem. Being able to "simulate" the startup sequence for how OpenRC wants
> to do things would have simplified and sped up the entire process.
> 
> --
> Joost

I enable the rc log and check how the various services try to start up, 
however the information provided is not always useful.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-04-14  8:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-11  5:19 [gentoo-user] How to find out all openrc dependencies? J. Roeleveld
2024-04-11  9:35 ` Michael
2024-04-11  9:48   ` J. Roeleveld
2024-04-11 10:10     ` Michael
2024-04-14  7:28       ` J. Roeleveld
2024-04-14  8:24         ` Michael [this message]
2024-04-14 16:40           ` J. Roeleveld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5773352.DvuYhMxLoT@rogueboard \
    --to=confabulate@kintzios.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox