Public bug reported:
What I was doing:
I tried to bootstrap a Ceph cluster on an Ubuntu Server 24.04.1 arm64 with
cephadm installed by apt from the Ubuntu repository.
What happened:
cephadm tries to pull the x86_64/amd64 version of the package instead of the
arm64 version, resulting in an exec
i filed this bug specifically for hyperconverged environments. Upgrading
monitor nodes first and then upgrading separate OSD nodes is probably
doable, but in a hyperconverged environment you can not separate.
I tried do-release-upgrade (a couple of times) without rebooting at the end,
but found t
I accomplished the upgrade by marking all Ceph packages held, then
digging myself through the dependency jungle to upgrade the packages
subsequently. This obviously is not a production ready way to do so, but
at least Ceph Octopus is running in 20.04 now now.
This really needs to be fixed.
--
Yo
One note on importance: If someone runs do-release-upgrade on a
converged Ceph node, it will destroy the node. So far I have not seen
any recovery procedure. The only reason I was able to rapidly redo the
upgrade is because it runs on snapshots and thus can be recovered after
destruction. This is n
I tried to do the upgrade by hand (disable all the services that can not
be autostarted, do the upgrade (btw, a manpage has been moved from ceph-
deploy to ceph-base and thus the apt upgrade fails. do-release-upgrade
is using --force-overwrite for this, but that's not a clean solution).
Solution is
I just shut down Ceph on all four nodes completely, then did the do-
release-upgrade. Before the upgrade I verified that all Ceph services
were down so I would be able to start them in the correct order.
After the upgrade (without reboot!) I found that all Ceph services on
all Ceph nodes had been
I redid the whole upgrade:
* do-release-upgrade and finished without reboot (all 4 nodes)
** so ceph daemons should not have been restarted
* restarted all ceph mons sequentially
** verified I get octopus as min mon release
* restarted all ceph-mgrs sequentially
** verified that all ceph-mgr daemon
This would work If all nodes have a single function only (mon, mgr, old). I
tried everything to update the monitors first, but due to the dependencies
between the Ceph packages the monitors and mgr daemons can not simply be
updated separately from the OSDs What I don't get, though, is that once all
Public bug reported:
Upon upgrading a Ceph node with do-release-upgrade from eoan to focal,
the OSD doesn't connect after the upgrade. I rolled back the change
(VBox snapshot) and tried again, same result. I also tried to hold back
the Ceph packages and upgrade after the fact, but again same resul
I am experiencing the same bug. The workaround helps, but I would really
appreciate if tre bug was fixed soon.
Otherwise evolution and evolution MAPI works well for me.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.lau
I installed 3.0.1 from Oneiric (Aug 6, 2011) and encountered the same
issue. After reverting to the mentioned kernel by Herton the trackpad
works fine.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/81
I have the same behavior with up-to-date kubuntu 9.04 and acroread 9.1.0
- opening links to pdf files with acroread from thunderbird causes hang
of KDE/X. killing the offending acroread process frees up KDE. The
behavior is reproducible.
--
Kubuntu 9.04 Xorg/KDE freeze starting adobe reader 9.1.0
12 matches
Mail list logo
