On 10 October 2016 at 00:04, Gerald B. Cox <gb...@bzb.us> wrote: > You have 3 options how to resolve it: > > 1. You ignore it completely and you patiently wait until your system > crash. > 2. Do Offline Updates > <http://fedoraproject.org/wiki/Features/OfflineSystemUpdates>. > 3. After restart you carefully restart only those applications and > daemons, which needs to be restarted. > > You have still 4th option: - create from snapshots separated boot environment (BE) - do upgrade in BE - restart system from new BE
To be honest only tis method solves all hazards which are not listed in your 3 points and additionally you will have possibility to create packages without any post install/uninstall scripts which are biggest risk factor of ANY upgrades. Really Linux needs to start learning from what has been done on Solaris more than decade ago. What old SySV packages maintainers found that majority of different customers problems on applying upgrades where generated by fully customizable post install/uninstall scripts. This was main driving force on implementing in IPS something which is called package action which is well tested sequence of operation in some class of installed resources. BE has very precise properties. It keeps only one kernel instance in each BE and boot loader must collect on boot stage informations about available BEs to present them as boot menu. Whatever needs to be customized as command line boot parameter needs to be part of BE description. Only with above approach is possible to stop updating boot entries and stop fighting with many other problems with which all Linux distros are fighting more than one and half decade. Again: to solve all upgrade issues it needs to be synchronized few technologies related to boot manager, package manager and used file systems. At least using btrfs, grub2 and rpm with removed post install/uninstall custom scripts is possible to solve finally all issues. It is possible to prepare packages in some way allowing to use post install/uninstall in case not using btrfs but it could be exact amin decision to accept some well known risk coming with choosing old/legacy approach. Whatever would be not done if not done using above idea will be still with non-zero risk of well known and new issues. Some people must understand that whatever they will be trying to archive without radical change which Solaris acceped and implemented decade ago it will be only WASTE OF TIME. kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
