Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything
Hi All,
Just a quick headsup for users following Fedora 29, the dbus 1.12.10-1.fc29 build is missing the systemd dbus.service file, breaking almost everything.
Instead it contains a dbus-daemon.service file, but the dbus.socket file expects a matching dbus.service, not dbus-daemon.service.
So either hold of on applying updates until this is fixed or exclude dbus.
Regards,
Hans
Hi
On Thu, Aug 30, 2018 at 3:13 PM Hans de Goede hdegoede@redhat.com wrote:
Hi All,
Just a quick headsup for users following Fedora 29, the dbus 1.12.10-1.fc29 build is missing the systemd dbus.service file, breaking almost everything.
Instead it contains a dbus-daemon.service file, but the dbus.socket file expects a matching dbus.service, not dbus-daemon.service.
So either hold of on applying updates until this is fixed or exclude dbus.
You can create the missing 'dbus.service' unit via:
`systemctl enable dbus-daemon`
This *should* be done automatically when installing `dbus-daemon`, for some reason this is not the case for some people. We are looking into that. fedora-release-29-0.12 provides the required systemd-presets.
Thanks David
Hi,
tried the suggested workaround with systemctl enable dbus-daemon. Now I get a black screen after login with sddm to lxqt-session.
https://bugzilla.redhat.com/show_bug.cgi?id=1623781
Regards, Raphael
On Sat, Sep 01, 2018 at 07:06:09AM -0000, Raphael Groner wrote:
Hi,
tried the suggested workaround with systemctl enable dbus-daemon. Now I get a black screen after login with sddm to lxqt-session.
F29 was supposed to switch to dbus-broker as a provider of dbus: https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementat... Enabling dbus-daemon would make two conflicting implementation active, won't it?
On Sat, Sep 01, 2018 at 09:21:42AM +0200, Tomasz Torcz wrote:
On Sat, Sep 01, 2018 at 07:06:09AM -0000, Raphael Groner wrote:
Hi,
tried the suggested workaround with systemctl enable dbus-daemon. Now I get a black screen after login with sddm to lxqt-session.
F29 was supposed to switch to dbus-broker as a provider of dbus: https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementat... Enabling dbus-daemon would make two conflicting implementation active, won't it?
"Enabling" dbus-daemon activates a link which creates the alias dbus.service → dbus-broker.service. So that step replaces the original dbus daemon. At least that was supposed to happen. It is probably useful to look at 'systemctl status dbus.service' to see what it is actually running.
Here: $ systemctl status dbus ● dbus-broker.service - D-Bus System Message Bus Loaded: loaded (/usr/lib/systemd/system/dbus-broker.service; enabled; vendor preset: disabled) ... CGroup: /system.slice/dbus-broker.service ├─1029 /usr/bin/dbus-broker-launch --scope system --audit └─1030 dbus-broker --log 4 --controller 9 --machine-id 08a5690a2eed47cf92ac0a5d2e3cf6b0 --audit
Aug 31 21:12:15 krowka dbus-broker-launch[1029]: Activation request for 'org.freedesktop.PackageKit' fail> Aug 31 21:12:15 krowka dbus-broker-launch[1029]: Activation request for 'org.bluez' failed: Unit dbus-org> ...
But note that there are actually 3 (!) dbus daemons in play. There's the system dbus instance, discussed above, and then each user has a user instance (systemctl status --user dbus) and another instance used for at-spi2 (changing this requires patching at-spi2, which I think has already happened upstream, but those changes aren't present in Fedora yet, so we expect to see dbus-daemon there).
Zbyszek
Den lör 1 sep. 2018 kl 09:54 skrev Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl:
On Sat, Sep 01, 2018 at 09:21:42AM +0200, Tomasz Torcz wrote:
On Sat, Sep 01, 2018 at 07:06:09AM -0000, Raphael Groner wrote:
Hi,
tried the suggested workaround with systemctl enable dbus-daemon. Now I get a black screen after login with sddm to lxqt-session.
F29 was supposed to switch to dbus-broker as a provider of dbus: https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementat... Enabling dbus-daemon would make two conflicting implementation active, won't it?
"Enabling" dbus-daemon activates a link which creates the alias dbus.service → dbus-broker.service. So that step replaces the original dbus daemon. At least that was supposed to happen. It is probably useful to look at 'systemctl status dbus.service' to see what it is actually running.
Here: $ systemctl status dbus ● dbus-broker.service - D-Bus System Message Bus Loaded: loaded (/usr/lib/systemd/system/dbus-broker.service; enabled; vendor preset: disabled) ... CGroup: /system.slice/dbus-broker.service ├─1029 /usr/bin/dbus-broker-launch --scope system --audit └─1030 dbus-broker --log 4 --controller 9 --machine-id 08a5690a2eed47cf92ac0a5d2e3cf6b0 --audit
Aug 31 21:12:15 krowka dbus-broker-launch[1029]: Activation request for 'org.freedesktop.PackageKit' fail> Aug 31 21:12:15 krowka dbus-broker-launch[1029]: Activation request for 'org.bluez' failed: Unit dbus-org> ...
But note that there are actually 3 (!) dbus daemons in play. There's the system dbus instance, discussed above, and then each user has a user instance (systemctl status --user dbus) and another instance used for at-spi2 (changing this requires patching at-spi2, which I think has already happened upstream, but those changes aren't present in Fedora yet, so we expect to see dbus-daemon there).
Zbyszek
I can't get a commandline, everything seems stuck in the boot process.... Is there anyway to get a commandline and update the system when it is in this state?
/Andreas
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Sat, 1 Sep 2018 13:44:56 +0200 Andreas Tunek andreas.tunek@gmail.com wrote:
I can't get a commandline, everything seems stuck in the boot process.... Is there anyway to get a commandline and update the system when it is in this state?
You could try getting to single user mode, putting a 1 after the boot line during boot by editing the menu entry before booting. That should put you into the root account, where you can run a dnf update.
Or, if you can boot a rescue image, you can then use chroot to do a dnf update of F29, should be something like chroot /mnt/Sysimage dnf update where /mnt/Sysimage is the root directory of the F29 installation.
I've done this successfully in the past from an older version of Fedora for rawhide update in a situation like you are experiencing, and it has worked. I always keep an older version of Fedora (the last one I used before this one) around for just this purpose (disk is cheap).
Den lör 1 sep. 2018 kl 15:50 skrev stan stanl-fedorauser@vfemail.net:
On Sat, 1 Sep 2018 13:44:56 +0200 Andreas Tunek andreas.tunek@gmail.com wrote:
I can't get a commandline, everything seems stuck in the boot process.... Is there anyway to get a commandline and update the system when it is in this state?
You could try getting to single user mode, putting a 1 after the boot line during boot by editing the menu entry before booting. That should put you into the root account, where you can run a dnf update.
There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it.
Or, if you can boot a rescue image, you can then use chroot to do a dnf update of F29, should be something like chroot /mnt/Sysimage dnf update where /mnt/Sysimage is the root directory of the F29 installation.
Is there a guide or something how to do that?
I've done this successfully in the past from an older version of Fedora for rawhide update in a situation like you are experiencing, and it has worked. I always keep an older version of Fedora (the last one I used before this one) around for just this purpose (disk is cheap).
Disk is not cheap on my test laptop unfortunately...
I think that install is gone and all I can do is reinstall. Not very fun.....
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Sun, Sep 2, 2018 at 9:34 AM Andreas Tunek andreas.tunek@gmail.com wrote:
Den lör 1 sep. 2018 kl 15:50 skrev stan stanl-fedorauser@vfemail.net:
Or, if you can boot a rescue image, you can then use chroot to do a dnf update of F29, should be something like chroot /mnt/Sysimage dnf update where /mnt/Sysimage is the root directory of the F29 installation.
Is there a guide or something how to do that?
https://docs.fedoraproject.org/en-US/Fedora/23/html/Multiboot_Guide/common_o...
You can chroot into the installed system from a live medium and it doesn't even have to be a Fedora one.
On Sun, 2 Sep 2018 09:33:39 +0200 Andreas Tunek andreas.tunek@gmail.com wrote:
There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it.
Whoa! I'm not sure what that buys, but I'll change that as soon as possible when I install it. That's crazy! Maybe someone wants to imitate a Mac or something. "Don't you trouble your pretty little head about what is going on behind the scenes, dearie, it is all taken care of. You just watch the pretty pictures, leave the driving to us." And that's reasonable for a certain class of users.
Is there a guide or something how to do that?
Alexander gave you one option, here are a couple of others.
http://www.system-rescue-cd.org/
https://www.fossmint.com/linux-rescue-recovery-tools/
A Fedora livecd would also work, anything that can boot the system without using the installed image. The advantage of using a recent fedora live image is that the kernel and packages will be compatible.
Disk is not cheap on my test laptop unfortunately...
There isn't even 80 GB, maybe less, free to clone the current version before you update? An rsync makes this easy, though you should probably do it from a live image so the temporary stuff created during boot isn't there.
I think that install is gone and all I can do is reinstall. Not very fun.....
I think you can recover, though it will be some work. In your situation, I would try to recover, as I think a reinstall will take more time and effort than a recovery.
All that is needed is to either downgrade dbus, or update it to the repaired version. You could just go to koji, grab the fixed dbus rpms, https://koji.fedoraproject.org/koji/buildinfo?buildID=1140329 cp them into the installed system from the rescue environment, chroot into the installed system from the rescue environment, and then run dnf -C update [the koji files, space separated] or rpm -ivh [the koji files, space separated] Then leave the chroot with exit and shutdown.
After that, booting into the system should work as dbus will be repaired.
On Sun, 2018-09-02 at 08:58 -0700, stan wrote:
On Sun, 2 Sep 2018 09:33:39 +0200 Andreas Tunek andreas.tunek@gmail.com wrote:
There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it.
Whoa! I'm not sure what that buys, but I'll change that as soon as possible when I install it. That's crazy! Maybe someone wants to imitate a Mac or something.
It's a Change that was properly announced and extensively discussed on this list. (Though it's unfortunate that this situation is apparently not considered a 'failed' boot by the mechanism that's supposed to make sure the boot menu *is* shown after a failed boot). https://fedoraproject.org/wiki/Changes/HiddenGrubMenu https://bugzilla.redhat.com/show_bug.cgi?id=1592201
"Don't you trouble your pretty little head about what is going on behind the scenes, dearie, it is all taken care of. You just watch the pretty pictures, leave the driving to us." And that's reasonable for a certain class of users.
Please avoid implicitly gendered language like this, that's not cool, and you don't need it to make your point.
Is there a guide or something how to do that?
Alexander gave you one option, here are a couple of others.
http://www.system-rescue-cd.org/
https://www.fossmint.com/linux-rescue-recovery-tools/
A Fedora livecd would also work, anything that can boot the system without using the installed image. The advantage of using a recent fedora live image is that the kernel and packages will be compatible.
Disk is not cheap on my test laptop unfortunately...
There isn't even 80 GB, maybe less, free to clone the current version before you update? An rsync makes this easy, though you should probably do it from a live image so the temporary stuff created during boot isn't there.
I think that install is gone and all I can do is reinstall. Not very fun.....
I think you can recover, though it will be some work. In your situation, I would try to recover, as I think a reinstall will take more time and effort than a recovery.
All that is needed is to either downgrade dbus, or update it to the repaired version. You could just go to koji, grab the fixed dbus rpms, https://koji.fedoraproject.org/koji/buildinfo?buildID=1140329 cp them into the installed system from the rescue environment, chroot into the installed system from the rescue environment, and then run dnf -C update [the koji files, space separated] or rpm -ivh [the koji files, space separated] Then leave the chroot with exit and shutdown.
After that, booting into the system should work as dbus will be repaired.
Actually, I think the title of this thread is wrong. At least in my testing, 1.12.10-2.fc29 is the *broken* package. 1.12.10-1.fc29 is fine. It's when you upgrade to 1.12.10-2.fc29 that things go sideways. To fix things you need to either enable dbus-daemon.service or downgrade to -1.
Den sön 2 sep. 2018 kl 18:18 skrev Adam Williamson adamwill@fedoraproject.org:
On Sun, 2018-09-02 at 08:58 -0700, stan wrote:
On Sun, 2 Sep 2018 09:33:39 +0200 Andreas Tunek andreas.tunek@gmail.com wrote:
There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it.
Whoa! I'm not sure what that buys, but I'll change that as soon as possible when I install it. That's crazy! Maybe someone wants to imitate a Mac or something.
It's a Change that was properly announced and extensively discussed on this list. (Though it's unfortunate that this situation is apparently not considered a 'failed' boot by the mechanism that's supposed to make sure the boot menu *is* shown after a failed boot). https://fedoraproject.org/wiki/Changes/HiddenGrubMenu https://bugzilla.redhat.com/show_bug.cgi?id=1592201
It would be nice if you could get to a command prompt (with networking enabled) even if dbus is broken.
"Don't you trouble your pretty little head about what is going on behind the scenes, dearie, it is all taken care of. You just watch the pretty pictures, leave the driving to us." And that's reasonable for a certain class of users.
Please avoid implicitly gendered language like this, that's not cool, and you don't need it to make your point.
Is there a guide or something how to do that?
Alexander gave you one option, here are a couple of others.
http://www.system-rescue-cd.org/
https://www.fossmint.com/linux-rescue-recovery-tools/
A Fedora livecd would also work, anything that can boot the system without using the installed image. The advantage of using a recent fedora live image is that the kernel and packages will be compatible.
Disk is not cheap on my test laptop unfortunately...
There isn't even 80 GB, maybe less, free to clone the current version before you update? An rsync makes this easy, though you should probably do it from a live image so the temporary stuff created during boot isn't there.
I think that install is gone and all I can do is reinstall. Not very fun.....
I think you can recover, though it will be some work. In your situation, I would try to recover, as I think a reinstall will take more time and effort than a recovery.
All that is needed is to either downgrade dbus, or update it to the repaired version. You could just go to koji, grab the fixed dbus rpms, https://koji.fedoraproject.org/koji/buildinfo?buildID=1140329 cp them into the installed system from the rescue environment, chroot into the installed system from the rescue environment, and then run dnf -C update [the koji files, space separated] or rpm -ivh [the koji files, space separated] Then leave the chroot with exit and shutdown.
After that, booting into the system should work as dbus will be repaired.
Actually, I think the title of this thread is wrong. At least in my testing, 1.12.10-2.fc29 is the *broken* package. 1.12.10-1.fc29 is fine. It's when you upgrade to 1.12.10-2.fc29 that things go sideways. To fix things you need to either enable dbus-daemon.service or downgrade to -1. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Adam Williamson wrote:
On Sun, 2018-09-02 at 08:58 -0700, stan wrote:
On Sun, 2 Sep 2018 09:33:39 +0200 Andreas Tunek andreas.tunek@gmail.com wrote:
There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it.
Whoa! I'm not sure what that buys, but I'll change that as soon as possible when I install it. That's crazy! Maybe someone wants to imitate a Mac or something.
It's a Change that was properly announced and extensively discussed on this list.
Since some Fedora users may not read this list, I hope that these changes will be prominently mentioned in the release documentation.
Preferably for F30 as well as F29 so that users who only update to every other release will also receive notification.
Ron
On Mon, Sep 3, 2018, 09:13 Ron Yorston rmy@frippery.org wrote:
Adam Williamson wrote:
On Sun, 2018-09-02 at 08:58 -0700, stan wrote:
On Sun, 2 Sep 2018 09:33:39 +0200 Andreas Tunek andreas.tunek@gmail.com wrote:
There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it.
Whoa! I'm not sure what that buys, but I'll change that as soon as possible when I install it. That's crazy! Maybe someone wants to imitate a Mac or something.
It's a Change that was properly announced and extensively discussed on this list.
Since some Fedora users may not read this list, I hope that these changes will be prominently mentioned in the release documentation.
Preferably for F30 as well as F29 so that users who only update to every other release will also receive notification.
Ron
Well, one might argue that users who really want to run pre-beta releases of fedora are also expected to follow the discussions and announcements here. fedora 29 really isn't ready for end users yet (as witnessed by this thread) - it's not even in beta after all - so if you don't (or can't) keep up with the news and development discussions, you really shouldn't be running fedora 29 yet IMO.
I know that doesn't help rescue the borked systems, but running alpha-quality code is bound to lead to problems, and users are expected to be able to deal with them - otherwise they should stick to stable releases.
Fabio
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Den mån 3 sep. 2018 kl 12:56 skrev Fabio Valentini decathorpe@gmail.com:
On Mon, Sep 3, 2018, 09:13 Ron Yorston rmy@frippery.org wrote:
Adam Williamson wrote:
On Sun, 2018-09-02 at 08:58 -0700, stan wrote:
On Sun, 2 Sep 2018 09:33:39 +0200 Andreas Tunek andreas.tunek@gmail.com wrote:
There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it.
Whoa! I'm not sure what that buys, but I'll change that as soon as possible when I install it. That's crazy! Maybe someone wants to imitate a Mac or something.
It's a Change that was properly announced and extensively discussed on this list.
Since some Fedora users may not read this list, I hope that these changes will be prominently mentioned in the release documentation.
Preferably for F30 as well as F29 so that users who only update to every other release will also receive notification.
Ron
Well, one might argue that users who really want to run pre-beta releases of fedora are also expected to follow the discussions and announcements here. fedora 29 really isn't ready for end users yet (as witnessed by this thread) - it's not even in beta after all - so if you don't (or can't) keep up with the news and development discussions, you really shouldn't be running fedora 29 yet IMO.
I know that doesn't help rescue the borked systems, but running alpha-quality code is bound to lead to problems, and users are expected to be able to deal with them - otherwise they should stick to stable releases.
Fabio
The thing is, if people do not test releases they will never be stable. And even if I don't know how to access my F29 installation from a chroot sometimes my testing is valuable to the project. Also, I think that my testing has shown that a lack of root account and boot menu has lead to a much worser user experience in certain cases.
/Andreas
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, 2018-09-03 at 20:09 +0200, Andreas Tunek wrote:
Den mån 3 sep. 2018 kl 12:56 skrev Fabio Valentini decathorpe@gmail.com:
On Mon, Sep 3, 2018, 09:13 Ron Yorston rmy@frippery.org wrote:
Adam Williamson wrote:
On Sun, 2018-09-02 at 08:58 -0700, stan wrote:
On Sun, 2 Sep 2018 09:33:39 +0200 Andreas Tunek andreas.tunek@gmail.com wrote:
There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it.
Whoa! I'm not sure what that buys, but I'll change that as soon as possible when I install it. That's crazy! Maybe someone wants to imitate a Mac or something.
It's a Change that was properly announced and extensively discussed on this list.
Since some Fedora users may not read this list, I hope that these changes will be prominently mentioned in the release documentation.
Preferably for F30 as well as F29 so that users who only update to every other release will also receive notification.
Ron
Well, one might argue that users who really want to run pre-beta releases of fedora are also expected to follow the discussions and announcements here. fedora 29 really isn't ready for end users yet (as witnessed by this thread) - it's not even in beta after all - so if you don't (or can't) keep up with the news and development discussions, you really shouldn't be running fedora 29 yet IMO.
I know that doesn't help rescue the borked systems, but running alpha-quality code is bound to lead to problems, and users are expected to be able to deal with them - otherwise they should stick to stable releases.
Fabio
The thing is, if people do not test releases they will never be stable. And even if I don't know how to access my F29 installation from a chroot sometimes my testing is valuable to the project. Also, I think that my testing has shown that a lack of root account and boot menu has lead to a much worser user experience in certain cases.
FWIW, I personally would like us to avoid such world-breaking bugs as this and the grub2 UEFI bug from reaching Rawhide or Branched as much as possible, and I'm frankly unhappy that both of those *did* a) happen and b) reach Rawhide and Branched, in 2018 we really ought to be able to avoid that. I think people ought to be able to run development Fedora and still have at least a reasonable expectation that we won't be so bad at making it that obvious disasters like this happen. More subtle bugs, sure, but anything this obvious should not make it in.
Note that there is an option for running Branched with a little extra safety: just disable updates-testing . We enable it by default for Branched because we basically want folks to be testing those packages - in Branched, the distinction between u-t and 'stable' is mainly about trying to keep the compose package set less broken and less about user safety. But you *can* disable it, and thus benefit from testing by other Branched users, if you want to. If you did that, you'd never have gotten either the broken grub2 or the broken udev as both were caught in u-t.
There is no such option for Rawhide, but you *do* at least have the option of reading test@ / devel@ and making sure no-one's complaining about their system failing to boot before you update. :)
Hey
On Tue, Sep 4, 2018 at 5:30 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2018-09-03 at 20:09 +0200, Andreas Tunek wrote:
The thing is, if people do not test releases they will never be stable. And even if I don't know how to access my F29 installation from a chroot sometimes my testing is valuable to the project. Also, I think that my testing has shown that a lack of root account and boot menu has lead to a much worser user experience in certain cases.
FWIW, I personally would like us to avoid such world-breaking bugs as this and the grub2 UEFI bug from reaching Rawhide or Branched as much as possible, and I'm frankly unhappy that both of those *did* a) happen and b) reach Rawhide and Branched, in 2018 we really ought to be able to avoid that. I think people ought to be able to run development Fedora and still have at least a reasonable expectation that we won't be so bad at making it that obvious disasters like this happen. More subtle bugs, sure, but anything this obvious should not make it in.
FWIW, the dbus changes were not intended for F29, but were backmerged due to miscommunication on our side. Which is unfortunate, because the bug only appears if you update the dbus package in steps (1.12.8-1 -> 1.12.8-2 -> 1.12.10-2) rather than in one jump (1.12.8-1 -> 1.12.10-2). Sorry for broken package!
Thanks David
Den sön 2 sep. 2018 kl 17:59 skrev stan stanl-fedorauser@vfemail.net:
On Sun, 2 Sep 2018 09:33:39 +0200 Andreas Tunek andreas.tunek@gmail.com wrote:
There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it.
Whoa! I'm not sure what that buys, but I'll change that as soon as possible when I install it. That's crazy! Maybe someone wants to imitate a Mac or something. "Don't you trouble your pretty little head about what is going on behind the scenes, dearie, it is all taken care of. You just watch the pretty pictures, leave the driving to us." And that's reasonable for a certain class of users.
Is there a guide or something how to do that?
Alexander gave you one option, here are a couple of others.
http://www.system-rescue-cd.org/
https://www.fossmint.com/linux-rescue-recovery-tools/
A Fedora livecd would also work, anything that can boot the system without using the installed image. The advantage of using a recent fedora live image is that the kernel and packages will be compatible.
Disk is not cheap on my test laptop unfortunately...
There isn't even 80 GB, maybe less, free to clone the current version before you update? An rsync makes this easy, though you should probably do it from a live image so the temporary stuff created during boot isn't there.
I have a 128 GB ssd in my system.
I think that install is gone and all I can do is reinstall. Not very fun.....
I think you can recover, though it will be some work. In your situation, I would try to recover, as I think a reinstall will take more time and effort than a recovery.
All that is needed is to either downgrade dbus, or update it to the repaired version. You could just go to koji, grab the fixed dbus rpms, https://koji.fedoraproject.org/koji/buildinfo?buildID=1140329 cp them into the installed system from the rescue environment, chroot into the installed system from the rescue environment, and then run dnf -C update [the koji files, space separated] or rpm -ivh [the koji files, space separated] Then leave the chroot with exit and shutdown.
After that, booting into the system should work as dbus will be repaired. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Hi,
On 02-09-18 09:33, Andreas Tunek wrote:
Den lör 1 sep. 2018 kl 15:50 skrev stan stanl-fedorauser@vfemail.net:
On Sat, 1 Sep 2018 13:44:56 +0200 Andreas Tunek andreas.tunek@gmail.com wrote:
I can't get a commandline, everything seems stuck in the boot process.... Is there anyway to get a commandline and update the system when it is in this state?
You could try getting to single user mode, putting a 1 after the boot line during boot by editing the menu entry before booting. That should put you into the root account, where you can run a dnf update.
There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it.
The boot menu should show if the previous boot is considered unsuccessful I guess that you have left the gnome-initial-setup gnome-shell session sit around for more then 2 minutes and then the boot is considered successful if you press "ctrl + alt + F4" and then "ctrl + alt + del" as soon as you get the broken gnome-initial-setup screen, it should reboot into the menu (this worked for me when I hit the same issue).
If that fails you should be able to get the boot menu by one of:
a) Keeping shift pressed during boot, note you typically need to press it a bit after the vendor logo / bios post shows otherwise it might not register
b) Pressing Esc during boot (needs to be done at the right time, so press it repeatedly during boot)
c) Pressing F8 during boot (needs to be done at the right time, so press it repeatedly during boot)
Regards,
Hans
Den mån 3 sep. 2018 kl 14:07 skrev Hans de Goede hdegoede@redhat.com:
Hi,
On 02-09-18 09:33, Andreas Tunek wrote:
Den lör 1 sep. 2018 kl 15:50 skrev stan stanl-fedorauser@vfemail.net:
On Sat, 1 Sep 2018 13:44:56 +0200 Andreas Tunek andreas.tunek@gmail.com wrote:
I can't get a commandline, everything seems stuck in the boot process.... Is there anyway to get a commandline and update the system when it is in this state?
You could try getting to single user mode, putting a 1 after the boot line during boot by editing the menu entry before booting. That should put you into the root account, where you can run a dnf update.
There is no root acoount on a default F29 installation. Also, you can't see the boot menu and I haven't been able to trigger it.
The boot menu should show if the previous boot is considered unsuccessful I guess that you have left the gnome-initial-setup gnome-shell session sit around for more then 2 minutes and then the boot is considered successful if you press "ctrl + alt + F4" and then "ctrl + alt + del" as soon as you get the broken gnome-initial-setup screen, it should reboot into the menu (this worked for me when I hit the same issue).
F29 worked before this update so I have already done the gnome initial setup.
If that fails you should be able to get the boot menu by one of:
a) Keeping shift pressed during boot, note you typically need to press it a bit after the vendor logo / bios post shows otherwise it might not register
b) Pressing Esc during boot (needs to be done at the right time, so press it repeatedly during boot)
c) Pressing F8 during boot (needs to be done at the right time, so press it repeatedly during boot)
Will I be able to log in to the user account? And will I have network access?
Regards,
Hans
On 09/03/2018 02:07 PM, Hans de Goede wrote:
The boot menu should show if the previous boot is considered unsuccessful I guess that you have left the gnome-initial-setup gnome-shell session sit around for more then 2 minutes and then the boot is considered successful if you press "ctrl + alt + F4" and then "ctrl + alt + del" as soon as you get the broken gnome-initial-setup screen, it should reboot into the menu (this worked for me when I hit the same issue).
Have we seriously reached the point of engineering things so that the way the system boots depends on your speed at cursing at the software when things don't work?
Regards
Den tors 30 aug. 2018 kl 15:21 skrev Hans de Goede hdegoede@redhat.com:
Hi All,
Just a quick headsup for users following Fedora 29, the dbus 1.12.10-1.fc29 build is missing the systemd dbus.service file, breaking almost everything.
Instead it contains a dbus-daemon.service file, but the dbus.socket file expects a matching dbus.service, not dbus-daemon.service.
So either hold of on applying updates until this is fixed or exclude dbus.
I seem to have gotten the update and now I can't log in to the system. Is there any way you can fix this?
/Andreas
Regards,
Hans _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Thank you for this headsup, I want to share some info too. I have found one site https://soclikes.com/buy-instagram-mentions-user-followers, here you can cheap get instagram mentions user followers. So, everyone, who need it, go here.
Thank you for this headsup, I want to share some info too. I have found one site https://soclikes.com/buy-instagram-mentions-user-followers, here you can cheap get instagram mentions user followers. So, everyone, who need it, go here.
On Tue, Aug 4, 2020 at 12:42 PM Mike Johnson jakeostin34@gmail.com wrote:
Thank you for this headsup, I want to share some info too. I have found one site https://soclikes.com/buy-instagram-mentions-user-followers, here you can cheap get instagram mentions user followers. So, everyone, who need it, go here.
So, how do we ban spammers from this list? CC devel-owner.
On 04.08.2020 13:58, Kamil Paral wrote:
So, how do we ban spammers from this list? CC devel-owner.
Allow only CLA+1 group members to post messages.
On Tue, 4 Aug 2020 at 09:37, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 04.08.2020 13:58, Kamil Paral wrote:
So, how do we ban spammers from this list? CC devel-owner.
Allow only CLA+1 group members to post messages.
I don't think mailman has any idea about group membership and I really don't have the time to deal with 'I am the upstream developer of XYZ and I am trying to respond to this thread.. why do I have to join multiple groups to post?'
I also note that a lot of fas account members have email addresses different from what they send email here as.
-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Tue, Aug 04, 2020 at 09:45:40AM -0400, Stephen John Smoogen wrote:
On Tue, 4 Aug 2020 at 09:37, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 04.08.2020 13:58, Kamil Paral wrote:
So, how do we ban spammers from this list? CC devel-owner.
Allow only CLA+1 group members to post messages.
I don't think mailman has any idea about group membership and I really don't have the time to deal with 'I am the upstream developer of XYZ and I am trying to respond to this thread.. why do I have to join multiple groups to post?'
I also note that a lot of fas account members have email addresses different from what they send email here as.
I'd like to add: Please don't reply on list to spam?
Mail the list owner(s) directly is fine, infrastructure ticktet if they aren't responding, but replying to the list just ampifies the spam. ;(
kevin
On Tue, 4 Aug 2020 at 08:58, Kamil Paral kparal@redhat.com wrote:
On Tue, Aug 4, 2020 at 12:42 PM Mike Johnson jakeostin34@gmail.com wrote:
Thank you for this headsup, I want to share some info too. I have found one site https://soclikes.com/buy-instagram-mentions-user-followers, here you can cheap get instagram mentions user followers. So, everyone, who need it, go here.
So, how do we ban spammers from this list? CC devel-owner.
User has been unsubscribed from the list. banning usually doesn't work because they have normally a couple hundred other accounts to use.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Alexander Ploumistos -
Andreas Tunek -
David Herrmann -
Fabio Valentini -
Hans de Goede -
Kamil Paral -
Kevin Fenzi -
Mike Johnson -
Raphael Groner -
Roberto Ragusa -
Ron Yorston -
stan -
Stephen John Smoogen -
Tomasz Torcz -
Vitaly Zaitsev -
Zbigniew Jędrzejewski-Szmek