Thanks Micah. I actually had found that but wondered if it was going todo
anything for me since it had indicated it was fixed in F29. I also was a
little tentative to try thosecommands since I don't really understand what the
dbus is and what it is doing. I guess I will just have to give it a try next
weeksometime when I more easily work with someone in the data center to help me
getthe server back online if things don't work. Doug
From: Micah Abbott <miabb...@redhat.com>
To: Doug Campbell <chinadoug2...@yahoo.com>
Cc: "atomic-devel@projectatomic.io" <atomic-devel@projectatomic.io>
Sent: Monday, March 25, 2019 9:12 PM
Subject: Re: [atomic-devel] Rebase Fedora Atomic 27 > 29 fails to boot
A search on the `Assertion` error shows this bug as a possible match
for what you are seeing -
https://bugzilla.redhat.com/show_bug.cgi?id=1653059
There are some workarounds to try in there, though the underlying
problem (if it is indeed the same) should be fixed in F29.
On Sat, Mar 23, 2019 at 9:55 PM Doug Campbell <chinadoug2...@yahoo.com> wrote:
>
>
>
> > -----Original Message-----
> > From: atomic-devel-boun...@projectatomic.io [mailto:atomic-devel-
> > boun...@projectatomic.io] On Behalf Of Colin Walters
> > Sent: Sunday, March 24, 2019 2:28 AM
> > To: atomic-devel@projectatomic.io
> > Subject: Re: [atomic-devel] Rebase Fedora Atomic 27 > 29 fails to boot
> >
> >
> >
> > On Wed, Mar 20, 2019, at 11:41 AM, Doug Campbell wrote:
> > > Currently running Fedora Atomic 27.153
> > >
> > > Following instructions at:
> > > http://www.projectatomic.io/blog/2018/10/fedora-atomic-28-to-29-
> > upgrade/ to upgrade to version 29.
> > >
> > > Upon reboot everything is fine until I see:
> > >
> > > (1 of 2) A start job is running for Network Manager (3min 6s / 1min 36s)
> > > [timestmp] systemd-journal[990]: Failed to send WATCHDOG=1 notification
> > > message: Connection refused
> > > [timestmp] systemd-journal[990]: Failed to send WATCHDOG=1 notification
> > > message: Transport endpoint is not connected
> > >
> > > The last line continues to repeat periodically for as long as I would
> > > wait.
> >
> > Try sending the systemd journal to the console:
> > https://freedesktop.org/wiki/Software/systemd/Debugging/
> > Specifically you want to add to the kernel commandline:
> >
> > systemd.journald.forward_to_console=1 console=ttyS0,38400 console=tty1
> >
> > If you're using the default GRUB setup just press `e` at the prompt.
> >
> > If this is a physical box that's hard to change remotely, one thing I'd
> > recommend
> > is to try setting up a similar system in a VM (using the same config
> > management
> > etc.) and see if it reproduces there too. VMs are a lot easier to debug.
>
> Thanks for the suggestions.
>
> I unfortunately am dealing with a remote server and although I tried I cannot
> seem to duplicate the issue locally on a virtual machine.
>
> After switching back to version 27 I was able to look at the logs though and
> one thing that appeared interesting was the following lines:
>
> 23:11 <error> [1553094660.3061] dispatcher: could not get dispatcher proxy!
> Error calling StartServiceByName for org.freedesktop.nm_dispatcher: Timeout
> wa... NetworkManager
> 23:04 Process 1237 (systemd) of user 0 dumped core. Stack trace of thread
> 1237: #0 0x00007fc8537cd83b kill (libc.so.6) #1 0x00005575ce842eda n/a
> (systemd)... systemd-coredump
> 23:04 Freezing execution
>
>
> systemd
> 23:04 Caught <ABRT>, dumped core as pid 1237
>
>
> systemd
> 23:04 Assertion 'slot->n_ref > 0' failed at
> ../src/libsystemd/sd-bus/bus-slot.c:198, function sd_bus_slot_unref().
> Aborting.
> systemd
> 23:04 Failed to get initial list of names: Connection timed out
>
>
> systemd
> 23:02 Assertion 'slot->n_ref > 0' failed at
> ../src/libsystemd/sd-bus/bus-slot.c:198, function sd_bus_slot_unref().
> Aborting.
> systemd-login
>
>
> Not sure what that means exactly but I suspect the problem may lie in there.
>
> Doug
