Re: [Devil-linux-develop] Issues with remote update of DL

[Heiko Z. <he...@zu...>]

Tim Tait wrote:
> 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.... 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...
> 
>>
>>> 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. 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.

This was my thought too.

Heiko