Re: Making apt-get powercut-proof
On Mon, May 05, 2008 at 08:57:36PM +0100, Andrew Sayers wrote:
> A friend of mine was upgrading to Hardy, and (so far as we can tell)
> there was a power cut while it was halfway through, which left his
> system in a not-especially-useful state. I think the best solution is
> to have a /etc/init.d/{apt-get|dpkg} script that checks for
> half-finished installs, and restarts them if necessary. If so, which
> (or both) would be better, and is there anyone here that knows enough
> about the two to suggest a complete set of commands that need to be run?
> Also, is this something we should be doing in an Ubuntu-specific way
> (e.g. from X), or should I take this idea to Debian?
Another use case (which I've run into a few times) is if you are doing
the upgrade unattended, it pauses for confirmation about a change to a
config file, and [battery runs out | wife turns off computer | system
locks up due to a suspend/resume bug].
I don't recall exactly what apt commands I needed to get things going
again. In one particularly nasty case, network manager had been left in
some sort of weird inconsistent state and I couldn't get it to connect
to the network, so ended up having to do a bunch of low level wireless
network hackery to get it going again. I suspect that was atypical, but
it makes me wonder if power failures during certain packages could be
much worse than others...
Anyway, making upgrades more resilient to being restarted in the middle
would be quite welcomed.
Bryce
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
Andrew Sayers wrote:
> A friend of mine was upgrading to Hardy, and (so far as we can tell)
there was a power cut while it was halfway through, which left his
system in a not-especially-useful state. I think the best solution is
to have a /etc/init.d/{apt-get|dpkg} script that checks for
> half-finished installs, and restarts them if necessary. If so, which
(or both) would be better, and is there anyone here that knows enough
about the two to suggest a complete set of commands that need to be run?
> Also, is this something we should be doing in an Ubuntu-specific way
> (e.g. from X), or should I take this idea to Debian?
Probably a Debian backend, with a Ubuntu graphical frontend.
No idea on the command to use, though.
-FFM
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
> On Mon, May 05, 2008 at 08:57:36PM +0100, Andrew Sayers wrote:
>> A friend of mine was upgrading to Hardy, and (so far as we can tell)
>> there was a power cut while it was halfway through, which left his
>> system in a not-especially-useful state. I think the best solution is
>> to have a /etc/init.d/{apt-get|dpkg} script that checks for
>> half-finished installs, and restarts them if necessary. If so, which
>> (or both) would be better, and is there anyone here that knows enough
>> about the two to suggest a complete set of commands that need to be run?
>> Also, is this something we should be doing in an Ubuntu-specific way
>> (e.g. from X), or should I take this idea to Debian?
>
> Another use case (which I've run into a few times) is if you are doing
> the upgrade unattended, it pauses for confirmation about a change to a
> config file, and [battery runs out | wife turns off computer | system
> locks up due to a suspend/resume bug].
>
Another different but related case is when a package is broken/frozen and
the user is not able to continue (phpbb2-conf-mysql, I'm looking at you!),
it would be nice to have a "skip" button for packages that seem to be
stuck.
-FFM
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
On Mon, May 5, 2008 at 5:13 PM, <[EMAIL PROTECTED]> wrote: > Another different but related case is when a package is broken/frozen and > the user is not able to continue (phpbb2-conf-mysql, I'm looking at you!), > it would be nice to have a "skip" button for packages that seem to be > stuck. > Reading this, I just thought I'd mention that previous upgrades have caused issues with scrollkeeper-update, in which the only way to continue was to kill the process. Having a 'skip package' option would have been particularly useful in that situation. Evan -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
[EMAIL PROTECTED] wrote: > > Another different but related case is when a package is broken/frozen and > the user is not able to continue (phpbb2-conf-mysql, I'm looking at you!), > it would be nice to have a "skip" button for packages that seem to be > stuck. > > -FFM > "Skip package" wouldn't really work, because later packages might rely on the package that's hung. On the other hand, I should imagine it's possible to kill the process, tidy up any packages that have already been installed, then give the user the option to remove the offending package (and any dependencies) before retrying. Of course, this all goes way beyond my meagre shell-scripting abilities, so now we're just developing a feature request to present to someone else. - Andrew Sayers -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
Evan wrote: > Reading this, I just thought I'd mention that previous upgrades have caused > issues with scrollkeeper-update, in which the only way to continue was to > kill the process. Having a 'skip package' option would have been > particularly useful in that situation. updating the docs database can take a very long time (i dont know why). you need to be patient. sam -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
It was actually spitting out errors in the cli. Something about a malformed prefs file. Killing the update and running "sudo dpkg-reconfigure scrollkeeper" fixed it. On Mon, May 5, 2008 at 5:56 PM, Sam Tygier <[EMAIL PROTECTED]> wrote: > Evan wrote: > >> Reading this, I just thought I'd mention that previous upgrades have >> caused >> issues with scrollkeeper-update, in which the only way to continue was to >> kill the process. Having a 'skip package' option would have been >> particularly useful in that situation. >> > > updating the docs database can take a very long time (i dont know why). > > you need to be patient. > > sam > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
It could work if after the package is skipped apt recreates the dependency list; this might be bad to oversee though (especially without a GUI), however adding a printout a la "These packages were originally meant to be installed: $PACKAGES Since package $PACKAGE was removed after the update began, they are NOT going to be installed [Y/n]" where n would retry with the same package included again. One could even think of a skip-broken-packages option. Since non-installed packages remain in the dpkg/apt system as to-be-upgraded there is no real problem (if apt would additionally save the status then in update-manager they could be shown as unchecked with a hint that they failed to install). 2008/5/5 Andrew Sayers <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] wrote: > > > > Another different but related case is when a package is broken/frozen > and > > the user is not able to continue (phpbb2-conf-mysql, I'm looking at > you!), > > it would be nice to have a "skip" button for packages that seem to be > > stuck. > > > > -FFM > > > > "Skip package" wouldn't really work, because later packages might rely > on the package that's hung. On the other hand, I should imagine it's > possible to kill the process, tidy up any packages that have already > been installed, then give the user the option to remove the offending > package (and any dependencies) before retrying. > > Of course, this all goes way beyond my meagre shell-scripting abilities, > so now we're just developing a feature request to present to someone else. > >- Andrew Sayers > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
Milosz Derezynski wrote: > It could work if after the package is skipped apt recreates the > dependency list; this might be bad to oversee though (especially without > a GUI), however adding a printout a la "These packages were originally > meant to be installed: $PACKAGES Since package $PACKAGE was removed > after the update began, they are NOT going to be installed [Y/n]" where > n would retry with the same package included again. One could even think > of a skip-broken-packages option. Since non-installed packages remain in > the dpkg/apt system as to-be-upgraded there is no real problem (if apt > would additionally save the status then in update-manager they could be > shown as unchecked with a hint that they failed to install). I don't think I'd want the actual apt-get command line to be second-guessing me, so how about this for a feature suggestion (to update-manager and to synaptic): If a package takes more than 60 seconds to install, force the "details" window to open, and also present a dialogue box saying: $PACKAGE has taken more than a minute to install. This is normal for some packages, but might be a sign of a problem. The following packages depend on $PACKAGE: $DEPENDENCIES [ Stop installing ] [ Skip this package ] [ Keep waiting ] Clicking "stop installing", obviously, stops the installation. The package that failed is then highlighted in the main window. "Skip this package" kills the PID of the shell script that apt is running. I'd have to check, but I think that apt does the right thing in that situation. Clicking "keep waiting" sends the dialogue box away for 5 minutes (then for 10 minutes, then for 15 minutes...) - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
RE: Making apt-get powercut-proof
De: Bryce Harrington
Enviado el: lun 05/05/2008 22:51
Para: Andrew Sayers
CC: ubuntu-devel-discuss
Asunto: Re: Making apt-get powercut-proof
On Mon, May 05, 2008 at 08:57:36PM +0100, Andrew Sayers wrote:
> A friend of mine was upgrading to Hardy, and (so far as we can tell)
> there was a power cut while it was halfway through, which left his
> system in a not-especially-useful state. I think the best solution is
> to have a /etc/init.d/{apt-get|dpkg} script that checks for
> half-finished installs, and restarts them if necessary. If so, which
> (or both) would be better, and is there anyone here that knows enough
> about the two to suggest a complete set of commands that need to be run?
> Also, is this something we should be doing in an Ubuntu-specific way
> (e.g. from X), or should I take this idea to Debian?
I think this is an Ubuntu specific way, because wants to be as easy (or even,
more easy) than other operating systems.
And this really would be powercut-proof box, not only related to apt-get.
One could include an entry in the launchpad o brainstorm.
Regards.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
Hi,
On Mon, May 05, 2008 at 08:57:36PM +0100, Andrew Sayers wrote:
> A friend of mine was upgrading to Hardy, and (so far as we can tell)
> there was a power cut while it was halfway through, which left his
> system in a not-especially-useful state. I think the best solution is
> to have a /etc/init.d/{apt-get|dpkg} script that checks for
> half-finished installs, and restarts them if necessary. If so, which
> (or both) would be better, and is there anyone here that knows enough
> about the two to suggest a complete set of commands that need to be run?
> Also, is this something we should be doing in an Ubuntu-specific way
> (e.g. from X), or should I take this idea to Debian?
I added a dpkg/apt recovery to the friendly-recovery package in
intrepid. When booting into recovery mode it will have a "dpkg -
Repair packages" menu item that will do the required steps. I plan to
also extend update-manager so that it is available there.
The new friendly recovery is also in my PPA at
https://edge.launchpad.net/~mvo/+archive
(for those curious to test).
Cheers,
Michael
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
RE: Making apt-get powercut-proof
De: [EMAIL PROTECTED] en nombre de Michael Vogt Enviado el: mar 06/05/2008 9:51 Para: Andrew Sayers CC: ubuntu-devel-discuss@lists.ubuntu.com Asunto: Re: Making apt-get powercut-proof >The new friendly recovery is also in my PPA at https://edge.launchpad.net/~mvo/+archive (for those curious to test). Can you explain more in https://wiki.ubuntu.com/Recovery ? I.e. how to install these packages ?. On the other hand, an interesting address for offline package update: http://offline.debian.net This could be use by update-manager for offline update. Regards. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
Just by my feel of gut I'd guess that some unexperienced people who simply don't want to wait long might find it encouraging to just skip packages even if they are told that this might be normal. However if a package installation aborts (not like with scrollkeeper but simply fails), which is an evident sign of a problem, then being able to skip this item within update-manager or synaptic would be great I think. 2008/5/6 Andrew Sayers <[EMAIL PROTECTED]>: > Milosz Derezynski wrote: > > It could work if after the package is skipped apt recreates the > > dependency list; this might be bad to oversee though (especially without > > a GUI), however adding a printout a la "These packages were originally > > meant to be installed: $PACKAGES Since package $PACKAGE was removed > > after the update began, they are NOT going to be installed [Y/n]" where > > n would retry with the same package included again. One could even think > > of a skip-broken-packages option. Since non-installed packages remain in > > the dpkg/apt system as to-be-upgraded there is no real problem (if apt > > would additionally save the status then in update-manager they could be > > shown as unchecked with a hint that they failed to install). > > I don't think I'd want the actual apt-get command line to be > second-guessing me, so how about this for a feature suggestion (to > update-manager and to synaptic): > > If a package takes more than 60 seconds to install, force the "details" > window to open, and also present a dialogue box saying: > > $PACKAGE has taken more than a minute to install. This is normal for > some packages, but might be a sign of a problem. > > The following packages depend on $PACKAGE: $DEPENDENCIES > > [ Stop installing ] [ Skip this package ] [ Keep waiting ] > > Clicking "stop installing", obviously, stops the installation. The > package that failed is then highlighted in the main window. > > "Skip this package" kills the PID of the shell script that apt is > running. I'd have to check, but I think that apt does the right thing > in that situation. > > Clicking "keep waiting" sends the dialogue box away for 5 minutes (then > for 10 minutes, then for 15 minutes...) > >- Andrew > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
That's a pretty handy tool - would you be interested in an option to start the remote recovery that's being discussed in a nearby thread? Also, how would you feel if I suggested the options/dpkg script to the APT development team as the basis for an init script? I don't expect it would add more than a few seconds to boot time (or less if there's a lockfile that they can check for the existence of), and it would tackle the specific issue I had, where the problem presented as a missing home directory, and only turned out to be a package installation issue after much investigation. - Andrew Sayers -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
If you're amenable to extra scripts being suggested, I'll submit a bug report(s) as and when it's relevant. You're right about requiring a user choice, but I'm a bit concerned that users are going to be confronted with a collection of options that they don't understand, where one of them is known to be the right choice, but they have to poke about until they find it. How would you feel about adding a mechanism to do a quick check before showing the menu, then putting "(recommended)" next to one of the choices? In the case of the current choices, my suggestion would be that fsck be recommended if `touch /` returns false (i.e. read-only root filesystem, even if /etc/mtab denies it), else dpkg is recommended if apt or dpkg lock files exist (I assume they use lock files?), else xfix is recommended (it uses dpkg, so can't be run until dpkg is happy). The root shell would never be recommended, because people that want a shell don't need to be told. If you're happy with this idea, I can submit a skeleton implementation if you'd like. - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Making apt-get powercut-proof
Hi, On Tue, May 06, 2008 at 07:06:35PM +0100, Andrew Sayers wrote: > That's a pretty handy tool - would you be interested in an option to > start the remote recovery that's being discussed in a nearby thread? The design of friendly-recovery makes it easy to drop-in scripts, I wasn't following this thread, but it would certainly be possible to drop in something into /usr/share/recovery-mode/options that is then available in the recovery menu. > Also, how would you feel if I suggested the options/dpkg script to the > APT development team as the basis for an init script? I don't expect it > would add more than a few seconds to boot time (or less if there's a > lockfile that they can check for the existence of), and it would tackle > the specific issue I had, where the problem presented as a missing home > directory, and only turned out to be a package installation issue after > much investigation. I would prefer to make the package repair a explicit choice by the user. It may require manual input (conffile questions, debconf prompts, maintainer script prompts) so it is safer to handle when we know that a human is available. update-manager has support to deal with most brokeness in the packages system nowdays (interrupted dpkg, broken dependencies, packages in req-reinstall state, ...) and update-notifier will display a error symbol that will call update-manager. That should cover most of the desktop use-cases. The friendly-reocvery package with dpkg repair mode is now also available in hardy-proposed and should become available to hardy-updates soonish. Thanks, Michael -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
