Будучи уведомленным о 1404_HWE_EOL, я рассматриваю обновление важной производственной системы к 16.04.1. Я говорю "важную производственную систему", потому что это - рабочая станция, которую я ежедневно использую на работе. Я хочу избежать ошибок или других проблем, потому что у меня нет избытка времени для расходов проблем отладки и разбираний (отдел ИТ не помогают с системами Linux). У меня есть все сохраненные данные, но не текущий раздел ОС (я могу dd диск ОС как другой слой нейтрализации). Что другие шаги я должен выполнить прежде, чем обновить? Я хочу знать, как минимизировать сложности при использовании обновления версии, предлагаемого в Ubuntu.
Я читал об удалении PPAs перед обновлением. У меня есть 27 установленные PPAs, это займет время для удаления всех их, программы, которые они приносят, затем инвертируют это после обновления. Это обладает значительным преимуществом?Что-нибудь еще?
важная производственная система
я не обновил бы систему как этот. Я установил бы 16.04 на другой машине, скопировал бы живые данные в ту машину. Тест, протестируйте еще немного. И затем сделайте ту машину рабочим сервером.
И можно восстановить это с 18,04 с текущими 14,04 серверами.
, Почему рискуют вообще?
Я взял бы Резервное копирование образа ("dd" в Linux Живая Система) Рабочей станции и преобразовал бы это в VirtualBox VM. (НЕОБРАБОТАННОЕ изображение к VDI). После этого сделайте снимок и выполните это Изображение в VB. Играйте весь шаг к обновлению. Если что-то не работает, откладывает снимок. После наличия обновленной системы можно преобразовать VDI назад в сырые данные и "dd" это к системе или играть книгу выполнения.
, Но всегда делают последнее "dd" Резервное копирование образа перед перезаписью старой системы.
я предпочитаю выполнять свои системы от Карты флэш-памяти USB, таким образом, системная установка, покончили "VDI-> СЫРЫЕ ДАННЫЕ->, tumb-диск usb" и начальная загрузка от обновили/установили систему. готовый. Хорошо Вы "освобождаете" один USB-порт, но у Вас никогда не будет напряжения, и Вы можете alway делать легкий системное резервное копирование. Я делаю это со своей рабочей станцией и серверами в производстве уже много лет.
Вот изменение ответа @rinzwind, который мог бы работать с аппаратными средствами, которые Вы уже имеете.
, Если Вы имеете (или может освободить) достаточно свободного пространства на Вашем внутреннем дисковом накопителе (накопителях), можно создать 2 новых раздела (использующий что-то как gparted от живого дистрибутива CD/USB) и скопировать корень (/) в одного из них и / домой к другой и маркировать их чем-то как root2 и home2, таким образом, их легко найти.
, Если корень и домой находятся в том же разделе, можно просто скопировать это, но намного более хорошо по многим причинам, если они являются отдельными.
необходимо будет указать на новый корень на новый / домой путем редактирования изменений в /etc/fstab
на новом корневом разделе (обновляющий UUID нового / домой и корневых разделов).
Вы получаете их путем выполнения ls -l /dev/disk/by-label
для нахождения устройств новым корнем и домой в настоящее время включены и затем рабочие ls -l /dev/disk/by-uuid
для получения от имен устройств до uuids.
Затем, личинка обновления (от Вашей производственной системы) с чем-то как личинка-customizer для добавления нового корня к меню личинки.
Теперь, у Вас будет точная копия Вашей живой системы на тех разделах. Можно выполнить обновление на этой копии и все еще иметь производственную неповрежденную версию. Можно загрузиться в то, какой бы ни один Вы хотите продолжить работать.
, После того как Вы сделаны с обновлением, можно просто сказать личинке, что копия является живой (запись по умолчанию) и что оригинал является теперь резервным копированием. личинка-customizer делает выполнение вещей как это довольно легким.
, Если у Вас есть слишком много данных в / домой или корне (создание их слишком большой для дублирования), поместите его в его собственный раздел сначала (являющийся убеждающимся сказать программы что доступ он о перемещении). Это не должно быть дублировано - просто сохраненный.
Это также делает резервное копирование Ваших данных намного легче, потому что это больше не смешивается в с системным материалом.
Со вторым набором "тестовых" разделов, можно теперь попробовать все виды вещей, которыми Вы не хотели бы рисковать в системе, от которой Вы зависите для повседневной работы.
я в настоящее время выполняю Kubuntu 12.04 как это с 16,04 в моих разделах "разработки", пока он не настроил способ, которым я хочу его.
С ценами на дисководы, настолько низкими в эти дни, Вы могли даже скопировать свой существующий внутренний диск в новый больший и использование, что при необходимости - если Ваша компания позволит Вам.
Этот ответ касается всех главных деталей того, как сделать это. Я не пытался покрыть каждую маленькую деталь каждого шага. Но так как Вы работаете с копией всего, которое не должно быть никаких серьезных проблем, и все остальное было уже покрыто где-нибудь здесь на stackexchange.
Хотя это не относится к Вашему конкретному случаю, если система Ubuntu является VM, можно обойти эту проблему путем взятия снимка прежде, чем обновить и вернуться, если это не работает.
я когда-то обновил один из своих VMs, и хотя неудавшееся обновление и предположительно откатывало, я не получил чистую/функциональную систему.
ответ @Rinzwind также работает с VMs: создайте новый VM, установите новую версию Ubuntu на ней и начните копировать вещи.