From: Friedrich L. <fl...@fl...> - 2004-05-26 23:11:14
|
Tim Tait wrote on 27.05.2004 00:38 MET: > Friedrich Lobenstock wrote: > >> Tim Tait wrote on 26.05.2004 19:22 MET: >> >>> >>> While making some fixes to mount_cdrom for live update (due to issues >>> with read-only mounts of disk device) it occured to me there was >>> another issue - after reboot to a new version, pre_init will invoke >>> for the upgrade-config script where the user will be required to >>> provide input on the console. If the user is in fact at a remote >>> location, the box is now hung. >> >> >> >> It times out in 5 minutes in this case. See around line 87 in >> pre_init. In CVS this file is build/scripts/script/pre_init. >> >> When I look at this a second time I think we should change the if >> condition. In case of a timeout the returned character is the empty >> character so the upgrade is done. Then a confirmation asks to use this >> config and times out after 5 minutes and then the old configuration is >> restored and another confirmation times out in 5 minutes. So we are >> finally at 15 minutes till such system boots after remote upgrade >> without local input. >> >> Therefore I think in case of a timeout in the upgrade confirmation we >> should rather not upgrade at all but start the system after a shortend >> timeout of lets say 2 minutes. > > > But I think within the upgrade-config script itself there are infinte > waits for user input.... Ok, but that would be "fixed" if the first timeout would not start upgrade-config at all if a timeout happens. > so that would need to be changed to allow the > option of defaults with timeout so allow an unattended upgrade to > happen. And if we fix the default to "no upgrade" then we may not boot > at all... With the stable series this should be no problem. But you might want to test in a testsystem beforehand anyways ;-) >>> Q: It looks like upgrade-config needs some post-processing to >>> actually upgrade the real config? >>> >>> A few alternatives occurred to me - >>> >>> - Make the choice to run upgrade-config default to "no", and let user >>> ssh in later to run it. Can we setup all interactive logins to check >>> for mismatch and prompt/run the upgrade script there? In some >>> situation, the boot might not be succesfull unless the config is >>> upgraded. >> >> >> >> If you keep your update within the series, eg. update from 1.x.y to >> 1.x.z then the config files should not have changed. You might miss >> one or the other update to a start script but a boot should not fail. >> >> But this is only true if we can keep to ourselfs and only do bugfixes >> to stable releases. With a development version of DL I would not >> advice to do remote update - too much can happen here. >> >> >> >>> - Add another boot-line option like "DL_remote" that would indicate >>> never to require console input. This could be used to skip the >>> upgrade prompt entirely, or just change the default answer. >> >> >> >> Why not just create a special file on the configuration media to >> signal that we should boot without user interaction after the upgrade? > > > Yes that could work also. > >> >> >>> - Add and option to upgrade-config that takes default choices if no >>> answer in n seconds, and leave the pre_init stuff alone. >> >> >> >> See above. >> >>> pre_init could detect the new "DL_remote" flag and call >>> upgrade-config with the right options. The user could ssh in to >>> accept and save the new config, or reject it and run the upgrade >>> script again. >> >> >> >> Bruce, can one run upgrade-config in the running system or will this >> break horribly for sure. One problem would be that we should eg. stop >> all running services but not sshd automatically in this case, right? > > > Well the upgrade-config script makes it's changes in a parallel > directory, so that much is safe. So I was thinking let it auto-upgrade > and take the defaults, switch configs, and finish the boot. We should be > able to boot far enough to get ssh working at least. IMO I think this is far more dangerous than booting with the old config. > Since the new > config has not been saved yet, no permanent harm done. Now the user can > ssh in and review them. If they are not to their exact liking then they > can run upgrade-config again with the right input, and make a new-etc > tree. Save that as etc.tar.bz2 (do the paths need to be munged?) over > the old one, and reboot. Voila! Trick is to try to garantee the 1st boot > has a high likelyhood of success. Hmmmm.....maybe in case of autoupdate we should start a process in the background that does nothing than the following: sleep 10min <restore prev. version of DL and remove disable new one> reboot -n -f This way you'd at least end up with the not updated system back to live if everything else fails. Of course we'd then need to add some kind of warning to the admins login to not forget to kill this process ;-) Anyway those files that could not be upgrade by an auto-upgrade, eg. because they where changed manually, need to be updated manually anyway. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |