On 26 Jan 2013, at 13:09, Chris Murphy wrote:
On Jan 26, 2013, at 10:45 AM, Mike Pinkerton
<pseli...@mindspring.com> wrote:
If a fedup upgrade can go offline for a lengthy, but uncertain,
amount of time, then the lack of feedback is worrying. You can't
hold your breath for 25 minutes, you don't know when to conclude
that you have a serious problem that will require help from the
data center staff, and you don't have any idea where the process
went off-track.
I think the lack of feedback with fedup is a known weak area that
needs improvement. I found that by deleting 'quiet rhgb' and adding
one of the debug options to the fedup kenel at reboot time, I can
get to a shell during the upgrade, and issue a:
journalcti --follow
And I get live updates throughout the process. I don't recall
"hang" without some sort of feedback for more than maybe 5 minutes.
I forget off hand if top and/or ps are available, I think at least
one of them is.
I can see how this would help when sitting in front of the box, but
when you're hundreds or thousands of miles away, it isn't really an
option.
If you could SSH into fedup during its "offline" period and get
real time feedback about what it is doing and any errors it
encounters, and perhaps the ability to fix any problems when it
finishes but before it attempts to reboot, then it would be less
scary for remote upgrades.
I haven't tried 'systemctl start sshd' during the upgrade to see
what happens; it's probably not totally benign to do this, since
ssh will be upgraded, but it seems a lot safer, vastly so, than a
live yum update while a server is running.
Would it work for the network and sshd to be run from the initramfs
rather than the file system that is being updated?
It would be nice if one could start fedup with a flag that would tell
it to start the network and sshd upon reboot, and enable feedback to
a remote user. That would make the process a lot less worrisome.
--
Mike
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
