Table of Contents
Waiting for root file
system
Перад абнаўленнем прапануем азнаёміцца з інфармацыяй у Chapter 5, Праблемы "lenny", аб якіх варта ведаць. Гэты падзел апісвае патэнцыйныя праблемы, якія не датычацца непасрэдна працэсу абнаўлення, але могуць быць дастаткова істотнымі, каб ведаць аб іх да пачатку працэсу.
Настойліва раім перад абнаўленнем зрабіць поўную рэзервовую копію альбо як мінімум зрабіць копію наладак і інфармацыі, якія занадта дарагія, каб рызыкаваць імі. Падчас абнаўлення выкарыстоўваюцца дастаткова надзейныя cродкі і працэсы, але, напрыклад, апаратны збой пасярэдзіне працэсу абнаўлення можа скончыцца цяжкімі пашкоджаннямі сістэмы.
Асноўныя рэчы, якія варта захаваць: начынне дырэкторый
/etc
, /var/lib/dpkg
,
/var/lib/aptitude/pkgstates
і вывад каманды
dpkg --get-selections "*"
(падвойныя двукоссі істотныя).
Сам працэс абнаўлення не змяняе нічога ў дырэкторыі
/home
. Тым не менш, вядома, што пэўныя праграмы
(напрыклад, кампаненты набору праграм Mozilla альбо працоўных асяродкаў
GNOME ды KDE) могуць перазапісваць існуючыя наладкі карыстальнікаў новымі
стандартнымі значэннямі пры першым запуску новай версіі такой праграмы. У
якасці меры перасцярогі варта зрабіць рэзервовыя копіі схаваных файлаў і
дырэкторый (іх назвы пачынаюцца з кропкі) з хатніх дырэкторыяў
карыстальнікаў. Такія рэзервовыя копіі дапамогуць аднавіць альбо нанова
стварыць старыя наладкі. Мажліва, аб гэткай магчымасці варта паведаміць
карыстальнікам.
Любая працэдура ўсталявання пакетаў мусіць быць запушчаная з правамі
суперкарыстальніка, таму альбо ўвайдзіце ў сістэму як
root
або скарыстайцеся камандамі su ці
sudo для атрымання адпаведных прывілеяў.
Існуе некалькі папярэдніх умоваў, выкананне якіх трэба праверыць перад пачаткам абнаўлення.
Версія бібліятэкі glibc
з выпуску
lenny не будзе працаваць з ядрамі, ранейшымі за
2.6.8
, ні на якой архітэктуры. Некаторыя архітэктуры
маюць нават больш высокія патрабаванні. Настойліва раім абнавіць ядро да
версіяў 2.6.18
ці 2.6.24
з выпуску
etch альбо ўжыць самастойна сабранае ядро версіі не ніжэйшай за
2.6.18
і пераканацца ў працаздольнасці Вашай сістэмы з
абноўленым ядром.
Разумна будзе своечасова паведаміць усім карыстальнікам аб любых абнаўленнях сістэмы, якія Вы плануеце, нягледзячы на тое, што карыстальнікі, якія працуюць у сістэме праз злучэнне ssh могуць амаль не заўважыць працэсу абнаўлення і будуць мець магчымасць спакойна працягваць працу.
Калі Вы лічыце неабходнымі дадатковыя перасцярогі, зрабіце рэзервовую копію
файлавай сістэмы /home
або адмацуйце падзел з ёю перад
пачаткам абнаўлення.
Хутчэй за ўсё, падчас абнаўлення да lenny Вам спатрэбіцца абнаўляць ядро, а значыць, і перазагружаць сістэму. Звычайна гэта робіцца пасля таго, як абнаўленне скончыцца.
Дзякуючы вялікай колькасці зменаў у ядрах паміж etch ды lenny, якія датычацца драйвераў, механізмаў пошуку абсталявання, пагадненняў аб назвах і парадку вызначэння файлаў прылад, існуе рызыка таго, што падчас перазагрузкі сістэмы пасля абнаўлення узнікне шэраг праблем. Гэты і наступныя падзелы распавядаюць аб вялікай колькасці вядомых патэнцыйных праблемных сітуацыяў.
З улікам сказанага мае сэнс упэўніцца ў магчымасці аднавіць кантроль над сістэмай, калі яна не здолее перазагрузіцца або (што актуальна для сістэм, якімі кіруюць дыстанцыйна) не здолее распачаць працу з сецівам.
Калі абнаўленне сістэмы запускаецца дыстанцыйна праз злучэнне ssh настойліва раім выканаць усе магчымыя дзеянні перасцярогі дзеля таго, каб забяспечыць магчымасць дыстанцыйнага доступу да сервера праз паслядоўны тэрмінал. Існуе верагоднасць, што пасля абнаўлення і перазапуску назвы пэўных прыладаў будуць змененыя (гл. Section 4.6.2, “Змена нумароў прылад”), а Вам давядзецца выпраўляць наладкі сістэмы праз лакальную кансоль. Таксама ўжываць лакальную кансоль, магчыма, давядзецца, калі сістэма выпадкова перазагрузіцца падчас абнаўлення.
Відавочны першы крок па выпраўленні сітуацыі -- спроба загрузіцца са старым ядром. Але, дзякуючы розным прычынам, апісаным у гэтым дакуменце, гэткі падыход можа не спрацаваць.
Калі спроба не атрымаецца, спатрэбіцца альтэрнатыўны шлях загрузкі сістэмы і
доступу ў яе. Адным з варыянтаў можа быць выкарыстанне адмысловага
“выратавальнага” дыску альбо загрузачнага дыска Linux live
CD. Пасля загрузкі з такога дыску ў большасці выпадкаў ёсць магчымасць
прымацаваць каранёвую файлавую сістэму і перайсці ў яе з дапамогай
chroot
дзеля вынаходжання і выпраўлення праблемы.
Іншы варыянт, які можна параіць -- выкарыстанне праграмы ўсталявання lenny у гэтак званым рэжыме ратавання. Перавага названага падыходу ў тым, што з розных метадаў усталявання магчыма абраць найбольш прыдатны да ўласных патрэбаў. Больш звестак на гэтую тэму ўтрымліваецца ў восьмай главе Кіраўніцтва па ўсталяванні і ў Частых пытаннях пра праграму ўсталявання Debian
Пакет initramfs-tools
дадае абалонку
адладкі[2] у загрузачныя адбіткі initrd, якія ён генеруе. Калі, напрыклад
адбітак initrd не можа прымацаваць каранёвую файлавую сістэму, карыстальнік
патрапіць у абалонку адладкі з доступам да базавых камандаў, што дазваляюць
выявіць праблему і выправіць яе, калі гэта магчыма.
Асноўныя рэчы, якія трэба правяраць: наяўнасць існых файлаў прылад у
/dev
; спіс загружаных модуляў (cat
/proc/modules
); вывад каманды dmesg, які можа
ўтрымліваць паведамленні аб памылках загрузкі драйвераў. Таксама вывад
каманды dmesg дазваляе даведацца, якія назвы прыладаў
былі празначаныя якім дыскам; таксама варта пераканацца (шляхам праверкі
вываду каманды echo $ROOT
, што каранёвая файлавая сістэма
знаходзіцца менавіта на той прыладзе, дзе спадзяецца карыстальнік.
Калі ў Вас атрымалася выправіць становішча, увядзіце
exit
каб выйсці з абалонкі адладкі і працягнуць загрузку
з таго моманту, як яна была перарваная. Безумоўна, гэта не скасоўвае патрэбы
выправіць асноўную прычыну памылкі і перагенераваць загрузачны адбітак
initrd, каб пры наступнай загрузцы сітуацыя не паўтарылася.
Абнаўленне дыстрыбутыву варта рабіць альбо лакальна ў тэкставым рэжыме (карыстаючыся віртуальнай кансоллю ці непасрэдна падлучаным паслядоўным тэрміналам), альбо дыстанцыйна праз злучэнне ssh.
Каб забяспечыць дадатковую устойлівасць дыстанцыйнага абнаўлення, раім запускаць абнаўленчы працэс у віртуальнай кансолі праграмы screen, якая дае магчымасць бяспечнага перадалучэння. Гэта дазволіць быць упэўненым, што выпадковы разрыў сувязі не прывядзе да спынення абнаўленчага працэсу.
![]() | Important |
---|---|
Катэгарычна не варта запускаць працэс абнаўлення з дапамогай telnet,rlogin,rsh або з графічнай Х-сесіі (запушчанай на машыне, якая абнаўляецца) пад кіраваннем xdm, gdm, kdm і г.д. Усе гэтыя сервісы могуць перазапускацца падчас абнаўлення, што прывядзе на немагчымасці доступу ў напалову абноўленую сістэму. |
Карыстальнікам, што ўжываюць загрузчык LILO, варта
ведаць, што пры стандартных наладках пакету initramfs-tools
будзе генеравацца завялікі
загрузачны адбітак у фармаце initramfs, загрузіць які з дапамогай
LILO немагчыма. Дзеля таго каб вырашыць праблему, варта
альбо перайсці на выкарыстанне grub
альбо выправіць у файле наладак
/etc/initramfs-tools/initramfs.conf
наступны радок:
MODULES=most
на
MODULES=dep
Але варта мець на ўвазе, што ў гэтым выпадку пакет initramfs-tools
будзе ўсталёўваць у файлавую
сістэму загрузачнага адбітку толькі модулі, патрэбныя для працы абсталявання
той сістэмы, на якой ствараецца адбітак. Калі трэба ствараць загрузачныя
носьбіты, што мусяць працаваць на больш шырокім спектры абсталявання, варта
пакінуць згаданы радок у выглядзе
MODULES=most
і пераканацца, што ў сістэме не выкарыстоўваеце LILO.
Надалей апісаны ў гэтым падзеле працэс разлічаны на абнаўленне “чыстай” сістэмы на базе etch без пакетаў, што прадстаўленыя іншымі вытворцамі. Каб дасягнуць найбольшай надзейнасці, магчыма, варта выдаліць пакеты іншых вытворцаў перад пачаткам абнаўлення.
Таксама працэдура разлічаная на тое, што сістэма або ўжо абноўленая да версіі etch або адразу ўсталёўвалася ў гэтай версіі. Калі гэта не так або няма дакладных звестак, скарыстайцеся парадамі з Section A.1, “Абнаўленне сістэмы на базе etch”.
У пэўных умовах выкарыстанне каманды apt-get замест aptitude дзеля ўсталявання пакетаў можа прывесці да таго, што aptitude палічыць пэўны пакет “неўжываным” і заплануе ягонае выдаленне. Збольшага, перад абнаўленнем варта прывесці сістэму ў парадак, пераканаўшыся ў яе актуальнасці і “чысціні”.
Паводле сказанага вышэй, варта пераканацца, што для праграмы кіравання
пакетамі aptitude не засталося запланаваных, але не
выкананых дзеянняў. Наяўнасць пакетаў, запланаваных да выдалення альбо
абнаўлення, можа негатыўна паўплываць на працэдуру абнаўлення сістэмы. Варта
мець на ўвазе, што такое магчыма толькі, калі файл наладак
sources.list
дагэтуль спасылаецца на люстэрка
etch замест stable або
lenny. Больш інфармацыі на гэты конт даступна ў
главе Section A.2, “Праверка спісу крыніц абнаўлення”.
Каб зрабіць згаданую праверку, запусціце каманду aptitude ў “візуальным рэжыме” і націсніце g (“Go”). Калі праграма прадэманструе спіс дзеянняў, варта перагледзець яго і альбо скончыць альбо скасаваць прапанаваныя задачы. Калі праграма не прапанавала ніякіх дзеянняў, Вы пабачыце паведамленне наступнага зместу: “Няма пакетаў, прызначаных для ўсталявання, выдалення альбо абнаўлення” (“No packages are scheduled to be installed, removed or upgraded”).
Калі APT быў наладжаны такім чынам, каб усталёўваць некаторыя пакеты з
дыстрыбутыву, які не з'яўляецца стабільным (напрыклад, з тэставай версіі),
можа спатрэбіцца змяніць адпаведныя прывязкі APT, каб дазволіць абнаўленне
гэтых пакетаў да версій, што ўваходзяць у новы стабільны выпуск. Адпаведныя
наладкі захоўваюцца ў файле
/etc/apt/preferences
. Дадатковую інфармацыю аб
прывязках APT можна атрымаць з даведкі
apt_preferences(5).
Незалежна ад абранага метаду абнаўлення, настойліва раім пераканацца, што ўсе пакеты сістэмы знаходзяцца ў стане, прыдатным да абнаўлення. Пададзеная далей каманда пакажа ўсе пакеты, якія былі ўсталяваныя толькі часткова (Half-Installed) альбо не былі наладжаныя (Failed-Config), а таксама пакеты, пры спробе ўсталявання якіх адбыліся памылкі.
# dpkg --audit
Таксама прагледзець стан усіх пакетаў сістэмы можна з дапамогай праграм dselect, aptitude або пададзеных далей камандаў:
# dpkg -l | pager
або
# dpkg --get-selections "*" > ~/curr-pkgs.txt
Добрая ідэя -- перад абнаўленнем прыбраць блакіроўкі (holds). Калі падчас абнаўлення высветліцца, што нейкі крытычны пакет заблакаваны, працэс абнаўлення скончыцца беспаспяхова.
Майце на ўвазе, што aptitude ужывае іншы спосаб рэгістрацыі заблакаваных пакетаў, чым apt-get ці dselect. Пакеты, заблакаваныя з пункту погляду aptitude, можна выявіць наступным чынам:
# aptitude search "~ahold" | grep "^.h"
Каб даведацца, якія пакеты ў сістэме заблакаваныя з пункту погляду apt-get, трэба ўжыць каманду
# dpkg --get-selections | grep hold
Калі нейкі пакет быў зменены і перасабраны лакальна, але пры гэтым яго назва і час змянення версіі засталіся такімі самымі, варта заблакаваць такі пакет, каб пазбегнуць ягонага абнаўлення.
У aptitude пакет можна заблакаваць пры дапамозе наступнай каманды:
# aptitude hold назва_пакета
Каб скасаваць блакіроўку пакета, замяніце параметр hold
на unhold
.
Калі засталося нешта, што патрабуе выпраўлення, пераканайцеся, што файл
наладак sources.list
дагэтуль спасылаецца на
etch як патлумачана ў Section A.2, “Праверка спісу крыніц абнаўлення”.
Калі ў файле наладак /etc/apt/sources.list
узгадваецца
секцыя proposed-updates
, такую згадку трэба прыбраць да
пачатку абнаўлення, каб зменшыць рызыку канфліктаў.
Калі ў сістэме выкарыстоўваюцца іншыя пакеты, апрэч афіцыйных пакетаў
Debian, варта мець на ўвазе, што яны могуць быць выдаленыя падчас
абнаўлення, дзякуючы магчымым канфліктам залежнасцяў. Калі такія пакеты былі
ўсталяваныя праз дадатковае сховішча, пазначанае ў файле наладак
/etc/apt/sources.list
, варта пераканацца, што згаданае
сховішча прапаноўвае таксама пакеты, сабраныя для lenny. Калі гэта
сапраўды так, дастаткова адмыслова змяніць адпаведны радок у файле наладак
(такім самым чынам, як радкі, што спасылаюцца на афіцыйныя сховішчы пакетаў
Debian).
Некаторыя карыстаюцца неафіцыйнымі адаптацыямі (backports) “навейшых” версій пакетаў Debian у сістэмах на базе etch. Такія пакеты, хутчэй за ўсё, падчас абнаўлення створаць праблемы з-за наяўнасці канфліктуючых файлаў[3]. Старонка Section 4.5.8, “Магчымыя праблемы падчас абнаўлення” утрымлівае пэўныя звесткі аб вырашэнні файлавых канфліктаў, калі яны здараюцца.
backports.org
-- гэта напаўафіцыйнае сховішча пакетаў,
якое падтрымліваецца распрацоўшчыкамі Debian GNU/Linux і ўтрымлівае больш новыя
версіі пакетаў, сабраныя адмыслова для стабільнага рэлізу на падставе
пакетаў з “тэставага” сховішча.
Сховішча backports.org
збольшага утрымлівае пакеты з
“тэставага” дыстрыбутыву, для якіх нумар версіі адмыслова
зніжаны, таму абнаўленне такіх пакетаў ад etch да lenny
мусіць працаваць належным чынам. Але ж частка адаптацый зробленая на базе
пакетаў нестабільнай галіны: абнаўленні бяспекі, а таксама Firefox, ядро
Linux, OpenOffice.org ды X.Org.
Калі адаптаваныя версіі ніводнага са згаданых пакетаў не выкарыстоўваюцца,
сістэму можна бесперашкодна абнаўляць да lenny. У іншым выпадку
трэба часова наладзіць прыярытэт прывязак (Pin Priority, гл. apt_preferences(5)), прызначыўшы значэнне
1001
пакетам з lenny. Пры выкананні гэтай умовы
абнаўленне таксама будзе бесперашкодным.
Каб не даць aptitude выдаліць некаторыя пакеты, якія былі ўсталяваныя праз механізм развязвання залежнасцяў, неабходна самастойна прыбраць з такіх пакетаў адзнаку auto. Для працоўных асяродкаў у лік такіх пакетаў трапляюць OpenOffice ды Vim:
# aptitude unmarkauto openoffice.org vim
А таксама адбіткі ядра версіі 2.6, калі яны ўсталёўваліся праз мета-пакет:
# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6.*' | cut -f1)
![]() | Note |
---|---|
Даведацца, якія пакеты ў сістэме ўсталяваныя аўтаматычна, можна з дапамогай aptitude, запусціўшы каманду: # aptitude search '~i~M' |
Перад пачаткам абнаўлення неабходна змяніць наладкі apt
, што тычацца спісу пакетаў. Гэтыя наладкі
вызначаюцца файлам /etc/apt/sources.list
.
apt
будзе разглядаць усе пакеты,
якія даступныя праз любое са сховішчаў, апісаных радкамі, што пачынаюцца з
“deb
”. Усталёўвацца будуць пакеты з
найбольшым нумарам версіі, пры наяўнасці такога пакету ў некалькіх сховішчах
выкарыстоўваецца будзе сховішча, згаданае раней за іншыя. Таму пры наяўнасці
доступу да некалькіх люстэркаў з пакетамі, звычайна ў першую чаргу апісваюць
люстэрка на лакальным дыску, потым узгадваюць CD-ROM, а
далей -- сеткавыя люстэркі (HTTP/FTP).
![]() | Tip |
---|---|
Верагодна, будзе карысна дадаць выключэнне ў механізм праверкі
GPG, якое датычылася б дыскаў DVD і CD-ROM. Трэба дадаць
наступны радок да файлу наладак APT::Authentication::TrustCDROM "true"; Але такі варыянт не будзе працаваць для файлаў з адбіткамі DVD або CD-ROM. |
Адзін і той жа выпуск можа згадвацца паводле кодавай назвы (напрыклад,
etch
, lenny
) і
паводле назвы стану (г.зн. oldstable
,
stable
, testing
,
unstable
. Спасылка на выпуск паводле ягонай кодавай
назвы дазваляе пазбегнуць нечаканасцяў пры выхадзе новага выпуску, і
менавіта таму надалей мы выкарыстоўваем гэты падыход. Але, адпаведна, Вам
давядзецца самастойна сачыць за выхадам новых выпускаў. Калі замест кодавай
назвы выкарыстаць назву стану, выхад новага выпуску будзе адзначаны толькі
павялічаным аб'ёмам загрузкі абноўленых пакетаў.
Стандартныя наладкі адпавядаюць усталяванню пакетаў з галоўных сервераў
Debian. Магчыма, Вы захочаце выправіць файл наладак
/etc/apt/sources.list
такім чынам, каб выкарыстоўваць
іншыя люстэркі (звычайна, размешчаныя бліжэй да Вас паводле структуры
сеціва).
Адрасы люстэркаў Debian (HTTP ды FTP) апублікаваныя на http://www.debian.org/distrib/ftplist (гл. секцыю “Спіс люстэркаў Debian”). Звычайна HTTP-люстэркі працуюць хутчэй за FTP.
Няхай, для прыкладу, найбліжэйшае да Вас люстэрка мае адрас
http://mirrors.kernel.org
. Пры вывучэнні гэтага люстэрка з
дапамогай вэб-браузера альбо FTP-кліента, можна заўважыць наступную
структуру каталогаў:
http://mirrors.kernel.org/debian/dists/lenny/main/binary-i386/... http://mirrors.kernel.org/debian/dists/lenny/contrib/binary-i386/...
Каб карыстацца гэтым люстэркам праз apt
, неабходна дадаць да файла
sources.list
радок такога зместу:
deb http://mirrors.kernel.org/debian lenny main contrib
Заўважце, што `dists
' дадаецца да шляху неяўным чынам, а
параметры пасля назвы выпуску ўжываюцца, каб пашырыць зону пошуку на
некалькі дырэкторыяў.
Пасля дадання новых крыніцаў трэба адключыць у файле
sources.list
запісы з
“deb
”, што ўжываліся раней. Зрабіць гэта
можна, дадаўшы значак кратаў (#
) у пачатак адпаведных
радкоў.
Замест ужывання сеціўных люстэркаў праз HTTP ці FTP можна наладзіць
/etc/apt/sources.list
такім чынам, каб ужываць люстэрка
на лакальнай файлавай сістэме (магчыма, прымацаванае праз сеціва з дапамогай
NFS).
Няхай, дзеля прыкладу, лакальнае люстэрка месціцца ў дырэкторыі
/var/ftp/debian
і мае наступную структуру каталогаў:
/var/ftp/debian/dists/lenny/main/binary-i386/... /var/ftp/debian/dists/lenny/contrib/binary-i386/...
Каб карыстацца гэтым люстэркам праз apt
, неабходна дадаць да файла
sources.list
радок такога зместу:
deb file:/var/ftp/debian lenny main contrib
Заўважце, што `dists
' дадаецца да шляху неяўным чынам, а
параметры пасля назвы выпуску ўжываюцца, каб пашырыць зону пошуку на
некалькі дырэкторыяў.
Пасля дадання новых крыніцаў трэба адключыць у файле
sources.list
запісы з
“deb
”, што ўжываліся раней. Зрабіць гэта
можна, дадаўшы значак кратаў (#
) у пачатак адпаведных
радкоў.
Калі для працы з пакетамі Вы хочаце выкарыстоўваць
толькі сховішчы на дысках (CD-ROM,DVD), адключыце ў
файле наладак усе існуючыя радкі, што пачынаюцца з
“deb
”. Гэта можна зрабіць, дадаўшы значак
кратаў (#
) у пачатак кожнага радка.
Пераканайцеся, што ў файле наладак /etc/fstab
ёсць
радок, які дазваляе мацаванне Вашай прылады CD-ROM у пункт мацавання
/cdrom
(пункт мацавання мусіць быць менавіта такім, каб
каманда apt-cdrom працавала карэктна). Напрыклад, калі
прылада CD-ROM адлюстроўваецца ў сістэме як /dev/hdc
,
файл наладак /etc/fstab
мусіць утрымліваць радок
прыкладна такога выгляду:
/dev/hdc /cdrom auto defaults,noauto,ro 0 0
Заўважце, што ў чацвёртым полі не мусіць быць ніякіх
прагалаў паміж словамі defaults,noauto,ro
.
Каб пераканацца, што ўсё працуе, устаўце кампакт-дыск і паспрабуйце запусціць каманду
# mount /cdrom # прымацаваць кампакт-дыск у пункт мацавання # ls -alF /cdrom # прагледзець каранёвую дырэкторыю дыску # umount /cdrom # адмацаваць кампакт-дыск
Далей запусціце:
# apt-cdrom add
для кожнага з кампакт-дыскаў Debian, каб дадаць звесткі аб іх у базу APT.
Рэкамендаваным спосабам абнаўлення з папярэдніх выпускаў Debian GNU/Linux з'яўляецца выкарыстанне сродку кіравання пакетамі aptitude. Гэтая праграма прымае больш надзейныя рашэнні аб усталяваных пакетах, чым apt-get.
Не забудзьцеся прымацаваць усе патрэбныя падзелы (асабліва каранёвы падзел і
/usr
) у рэжыме з дазволам чытання і запісу. Гэта можна
зрабіць з дапамогай каманды кшталту наступнай:
# mount -o remount,rw /mountpoint
Далей трэба вельмі пільна пераканацца, што запісы аб крыніцах APT (у файле
наладак /etc/apt/sources.list
) спасылаюцца альбо на
“lenny
” альбо на
“stable
”. У файле не мусіць быць актыўных
запісаў, што спасылаліся б на etch.
![]() | Note |
---|---|
Запісы, што датычацца крыніц CD-ROM, часта спасылаюцца на
“ |
Вельмі раім ужываць праграму /usr/bin/script, каб запісаць копію сэсіі абнаўлення. У гэтым выпадку пры ўзнікненні праблемаў Вы будзеце мець магчымасць прагледзець пратакол сесіі каб зразумець, што здарылася (і магчыма, калі гэта спатрэбіцца, падаць дакладныя звесткі ў паведамленні аб памылцы). Каб пачаць запіс сесіі, набярыце ў камандным радку:
# script -t 2>~/upgrade-lenny.time -a ~/upgrade-lenny.script
альбо нешта падобнае. Не змяшчайце файл з запісам сесіі ў часовых
дырэкторыях кшталту /tmp
альбо
/var/tmp
, таму што файлы ў такіх дырэкторыях могуць
быць выдаленыя падчас абнаўлення альбо пры перазапуску сістэмы.
Запіс сесіі таксама дазваляе прагледзіць паведамленні, якія былі пракручаныя
па-за межы экрану. Пераключыцеся на віртуальны тэрмінал 2 з дапамогай
камбінацыі клавіш Alt+F2, увайдзіце
ў сістэму і праглядзіце файл з дапамогай каманды less -R
~root/upgrade-lenny.script
.
Спыніць праграму script, калі абнаўленне скончыцца,
можна, набраўшы ў камандным радку exit
.
Калі каманда script запускалася з параметрам -t, можна паўтарыць усю сэсію з дапамогай праграмы scriptreplay:
# scriptreplay ~/upgrade-lenny.time ~/upgrade-lenny.script
Спачатку трэба атрымаць спіс пакетаў, даступных у новым выпуску. Гэта робіцца наступным чынам:
# aptitude update
Пры першым запуску са змененым спісам крыніц будзе надрукаваны шэраг папярэджанняў адносна іх дасягальнасці. Гэтыя папярэджанні бясшкодныя і яны не будуць паўтарацца пры наступных запусках каманды.
Перад абнаўленнем сістэмы неабходна пераканацца ў тым, што месца на дыску
хопіць дзеля поўнага абнаўлення, апісанага ў Section 4.5.7, “Абнаўленне астатняй часткі сістэмы”. Па-першае, любы патрэбны дзеля ўсталявання
пакет, які загружаецца з сеціва, захоўваецца ў дырэкторыі
/var/cache/apt/archives
(пакуль загрузка не скончаная,
адпаведныя файлы знаходзяцца ў паддырэкторыі
partial/
). Адпаведна, трэба пераканацца, што файлавая
сістэма падзелу, на якім знаходзіцца дырэкторыя /var
,
можа ўтрымаць усе часовыя файлы з пакетамі, якія будуць
усталёўвацца. Па-другое, пасля загрузкі з сеціва можа спатрэбіцца дадатковае
месца на іншых падзелах дзеля ўсталявання абноўленых пакетаў (якія могуць
быць большага памеру, чым папярэднікі) а таксама новых пакетаў, што дадаюцца
ў сістэму ў межах абнаўлення. Калі дыскавай прасторы не хопіць, сістэма
апынецца абноўленай толькі часткова. Не выключана, што такі яе стан будзе
цяжка выправіць.
Абедзьве каманды (aptitude і apt
) адлюструюць падрабязныя звесткі аб памеры
неабходнай дыскавай прасторы. Да пачатку абнаўлення можна пабачыць гэтыя
лічбы, запусціўшы:
# aptitude -y -s -f --with-recommends dist-upgrade [ ... ] XXX пакетаў будзе абноўлена, XXX пакетаў усталявана, XXX пакетаў выдалена, XXX пакетаў не абноўлена. Неабходна загрузіць xx.xMB/yyyMB архіваў. Пасля распакоўкі будзе дадаткова ўжыта AAAMB дыскавай прасторы. Зараз можна распачаць загрузку/усталяванне/выдаленне пакетаў.
![]() | Note |
---|---|
Запуск гэтай каманды напачатку працэсу абнаўлення можа скончыцца з памылкай дзякуючы прычынам, аб якіх распаведзена далей. У такім выпадку спачатку неабходна выканаць мінімальнае абнаўленне сістэмы, як апісана ў Section 4.5.6, “Мінімальнае абнаўленне сістэмы”, каб абнавіць ядро перад запускам згаданай каманды, што падлічвае памер патрэбнай дыскавай прасторы. |
Калі вольнай дыскавай прасторы недастаткова, трэба перш за ўсё вызваліць яе. Дзеля гэтага можна:
Выдаліць файлы пакетаў, якія былі загружаны з сеціва раней, і захоўваюцца ў
дырэкторыі /var/cache/apt/archives
. Зачысціць
непатрэбныя файлы можна з дапамогай каманд apt-get clean
або aptitude clean на выбар.
Выдаліць пакеты, на якія Вы забыліся і якія Вам непатрэбныя. Калі ў сістэме
ўсталяваны пакет popularity-contest
,
з дапамогай каманды popcon-largest-unused можна даведацца
аб пакетах, што не выкарыстоўваюцца і займаюць найбольш месца. Таксама можна
выкарыстаць каманды deborphan або
debfoster каб выявіць састарэлыя пакеты (гл. Section 4.10, “Састарэлыя пакеты”). Яшчэ адзін спосаб -- запусціць
aptitude у “візуальным рэжыме” і знайсці
састарэлыя пакеты ў секцыі “Састарэлыя і створаныя лакальна
пакеты”.
Выдаліце пакеты, якія спажываюць зашмат дыскавай прасторы і не
выкарыстоўваюцца ў бягучы момант (калі што, іх можна будзе пераўсталяваць
пасля абнаўлення). Вы можаце атрымаць спіс пакетаў, што займаюць найбольш
месца, з дапамогай каманды dpigs (уваходзіць у склад
пакету debian-goodies
) альбо
праграмы wajig (запушчанай з адмысловым параметрам:
wajig size
).
Можна атрымаць спіс пакетаў, што займаюць найбольш месца, з дапамогай
праграмы aptitude
. Запусціце
aptitude у візуальным рэжыме, абярыце пункт меню
→ (даступна толькі ў версіях, навейшых за
etch), націсніце l і ўвядзіце ~i
,
націсніце S і ўвядзіце ~installsize
,
пасля чаго Вы атрымаеце спіс пакетаў, прыдатны для далейшай працы з ім. Гэта
новая магчымасць, якая робіцца даступнай пасля абнаўлення aptitude
.
Пазбаўцеся непатрэбных файлаў перакладаў, усталяваўшы пакет localepurge
. Яго можна наладзіць такім чынам,
каб у сістэме захоўваліся толькі пераклады для некалькіх абраных
лакаляў. Гэта дазволіць зберагчы дыскавую прастору, занятую дырэкторыяй
/usr/share/locale
Часова перамясціце на іншую машыну альбо зусім выдаліце сістэмныя пратаколы,
што месцяцца ў дырэкторыі /var/log
.
Выкарыстайце часовую дырэкторыю
/var/cache/apt/archives
: магчыма ўжыць гэтую
дырэкторыю, размясціўшы яе на іншай файлавай сістэме (носьбіт
USB, часовы жорсткі дыск і г.д.)
![]() | Note |
---|---|
Не ўжывайце для гэтага рэсурсы NFS, таму што злучэнне з сецівам можа перапыняцца падчас абнаўлення. |
Напрыклад, калі ў Вас ёсць носьбіт USB, прымацаваны да
дырэкторыі /media/usbkey
:
выдаліце файлы пакетаў, якія былі папярэдне загружаныя для ўсталявання:
# apt-get clean
зрабіце копію дырэкторыі /var/cache/apt/archives
на
носьбіт USB:
# cp -ax /var/cache/apt/archives /media/usbkey/
прымацуйце часовую дырэкторыю кэша на месца той, што выкарыстоўваецца зараз:
# mount --bind /media/usbkey/archives /var/cache/apt/archives
пасля абнаўлення, аднавіце зыходную дырэкторыю
/var/cache/apt/archives
:
# umount /media/usbkey/archives
выдаліце непатрэбную болей дырэкторыю
/media/usbkey/archives
.
Вы можаце стварыць часовую дырэкторыю кэша на любой прымацаванай файлавай сістэме.
Заўважце, што для бяспечнага выдалення пакетаў лепей пераключыць файл
наладак sources.list
зноў да etch, як
распаведзена ў Section A.2, “Праверка спісу крыніц абнаўлення”.
З некаторых паведамленняў аб памылках вядома, што версіі aptitude
ды apt
, якія ўваходзяць у etch, часта няздольныя
забяспечыць абнаўленне да lenny. У lenny apt
лепей спраўляецца са складанымі чэргамі
пакетаў, што патрабуюць неадкладнай наладкі, а aptitude
больш разумным чынам шукае шляхі да
развязвання залежнасцяў. Абедзве гэтыя асаблівасці дужа запатрабаваныя
падчас абнаўлення дыстрыбутыву да lenny, таму перш за ўсё трэба
абнавіць два згаданых пакета. Каб абнавіць apt
, запусціце каманду:
# apt-get install apt
а для абнаўлення aptitude
(калі
гэтая праграма ўсталяваная ў сістэме) спатрэбіцца каманда:
# aptitude install aptitude
Гэты крок прывядзе да аўтаматычнага абнаўлення пакетаў libc6
ды locales
, а таксама дадатковага ўсталявання
бібліятэк падтрымкі SELinux (libselinux1
). На гэтым этапе пэўныя працуючыя
сервісы будуць перазапушчаныя, ў тым ліку xdm,
gdm ды kdm. У выніку лакальныя
X-сервісы могуць быць
адлучаныя.
Праграма aptitude
вядзе спіс
пакетаў, якія былі ўсталяваныя аўтаматычна (напрыклад, ў якасці залежнасцяў
іншага пакета). У lenny аналагічную магчымасць прадстаўляе нарэшце і
пакет apt
.
Падчас першага запуску версіі aptitude
, якая ўваходзіць у lenny,
праграма прачытае складзены раней спіс аўтаматычна ўсталяваных пакетаў і
канвертуе яго дзеля выкарыстання з новай версіяй apt
. Калі ў сістэме ўсталяваны пакет aptitude
, трэба хаця б раз запусціць каманду
aptitude, каб выканаць канверсію. Адзін са спосабаў
зрабіць гэта -- пашукаць неіснуючы пакет:
# aptitude search "?false"
З-за канфліктаў паміж некаторымі неабходнымі пакетамі з etch і
lenny, непасрэдны запуск aptitude dist-upgrade
часта можа запатрабаваць выдалення вялікай колькасці пакетаў, якія насамрэч
трэба захаваць. Таму лепей выконваць абнаўленне ў два крокі: спачатку
мінімальнае абнаўленне, каб абысці згаданыя канфлікты, потым поўнае
абнаўленне праз dist-upgrade
.
Спачатку запусціце:
# aptitude safe-upgrade
Гэтая каманда дазваляе выканаць усе абнаўленні, якія не вымагаюць выдалення альбо ўсталявання якіх-небудзь іншых пакетаў апрэч тых, што абнаўляюцца.
Далейшыя крокі залежаць ад таго, які набор пакетаў усталяваны ў сістэме. Мэта гэтага дакументу -- даць агульныя парады наконт выбару шляху, але калі Вы сумняваецеся, варта прагледзець і параўнаць варыянты выдалення пакетаў, што будуць прапанаваныя пры выкарыстанні кожнага з метадаў.
У спіс агульных пакетаў, што (хутчэй за ўсё) будуць падлягаць выдаленню,
ўваходзяць base-config
, hotplug
, xlibs
, netkit-inetd
, python2.3
, xfree86-common
ды xserver-common
. Больш звестак аб пакетах, якія
абвешчаны састарэлымі ў lenny, можна знайсці на старонцы Section 4.10, “Састарэлыя пакеты”.
Цяпер можна распачаць асноўны этап абнаўлення. Запусціце:
# aptitude dist-upgrade
Гэтая каманда выканае поўнае абнаўленне сістэмы, г.зн. усталюе найноўшыя даступныя версіі ўсіх пакетаў, і развяжа ўсе магчымыя залежнасці між пакетамі з улікам адрозненняў паміж гэтымі залежнасцямі ў розных выпусках. Калі трэба, будуць усталяваныя новыя пакеты (звычайна новыя версіі бібліятэк або пакеты, што змянілі назву), а несумяшчальныя састарэлыя пакеты будуць выдаленыя.
Пры абнаўленні з набору дыскаў CD-ROM ці DVD у пэўныя моманты сістэма будзе звяртацца да Вас з просьбай уставіць адпаведны дыск. Магчыма, спатрэбіцца ўстаўляць адзін і той жа дыск некалькі разоў; прычына палягае ў тым, што некаторыя залежныя адзін ад аднаго пакеты могуць месціцца на розных дысках.
Новыя версіі раней усталяваных пакетаў, якія немагчыма абнавіць, не змяніўшы
статус усталявання іншага пакету, будуць пакінутыя ў існуючай версіі. Такія
пакеты адлюстроўваюцца як “захаваныя”(“held
back”). Абнавіць іх можна альбо дадаткова прызначыўшы іх усталяванне
з дапамогай праграмы aptitude, альбо паспрабаваўшы
запусціць каманду aptitude -f install
.
package
Калі дзеянне з выкарыстаннем aptitude, apt-get або dpkg скончылася з памылкай
E: Dynamic MMap ran out of room
гэта значыць, што стандартнага памеру кэшу недастаткова. Праблему можна
вырашыць, выдаліўшы або закаментаваўшы непатрэбныя радкі ў
/etc/apt/sources.list
або павялічыўшы памер кэшу. Памер
кэшу павялічваецца праз выстаўленне параметра
APT::Cache-Limit
у файле наладак
/etc/apt/apt.conf
. Наступная каманда ўсталёўвае памер,
якога мусіць хапіць для абнаўлення:
# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf
Маецца на ўвазе, што дагэтуль адпаведная вялічыня не існавала ў файле наладак.
Часам неабходна дазволіць параметр APT::Force-LoopBreak
у
APT, каб было магчыма часова выдаляць крытычныя пакеты, разрываючы замкнёны
цыкл Conflicts/Pre-Depends. Звычайна пры ўзнікненні такога становішча
каманда aptitude выдае папярэджанне і спыняе працэс
абнаўлення. Абысці праблему можна, запусціўшы каманду
aptitude з параметрам -o
APT::Force-LoopBreak=1
.
Магчыма, што структура сістэмных залежнасцяў будзе настолькі пашкоджаная, што спатрэбіцца самастойнае ўмяшанне. Звычайна гэта значыць выкарыстанне праграмы aptitude або
# dpkg --remove package_name
каб выдаліць некаторыя пакеты, што замінаюць, або
# aptitude -f install # dpkg --configure --pending
У выключных выпадках можа спатрэбіцца пераўсталяванне пакета з дапамогай каманды кшталту
# dpkg --install /path/to/package_name.deb
Канфліктаў файлаў не мусіць быць, калі Вы робіце абнаўленне з “чыстага” etch. Але такія праблемы магчымыя, калі ў сістэме ўсталяваныя неафіцыйныя адаптацыі праграм (backports). У выніку файлавага канфлікту Вы пабачыце паведамленне аб памылцы кшталту:
Unpacking<package-foo>
(from<package-foo-file>
) ... dpkg: error processing<package-foo>
(--install): trying to overwrite `<some-file-name>
', which is also in package<package-bar>
dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing:<package-foo>
Вы можаце паспрабаваць развязаць канфлікт файлаў, прымусова выдаліўшы пакет, што ўзгадваецца ў апошнім радку паведамлення аб памылцы:
# dpkg -r --force-depends імя_пакета
Звычайна ў Вас ёсць магчымасць працягнуць абнаўленне пасля выпраўлення гэтай праблемы, паўтарыўшы апісаныя раней каманды aptitude.
Падчас абнаўлення сістэма можа рабіць запыты аб наладцы альбо пераналадцы
некаторых пакетаў. Калі Вам прапаноўваецца замяніць на версію распрацоўшчыка
любы файл ў дырэкторыях /etc/init.d
,
/etc/terminfo
або
/etc/manpath.config
, такую прапанову варта прыняць, каб
забяспечыць цэльнасць сістэмы. Звярнуцца да старых версій змененых файлаў
можна будзе ў любы момант, яны захоўваюцца з пашырэннем
.dpkg-old
.
Калі Вы не ўпэўненыя, што трэба рабіць, запішыце назву пакета або файла і разбярыцеся з адпаведнымі наладкамі пазней. Вы можаце прагледзець запіс сесіі, каб знайсці інфармацыю, што з'яўлялася на экране падчас абнаўлення.
У гэтай секцыі распавядаецца, як абнавіць ядро, і якія праблемы могуць
сустрэцца падчас такога абнаўлення. Вы можаце або ўсталяваць адзін з пакетаў
linux-image-*
, якія ўваходзяць у
Debian, альбо сабраць уласнае ядро.
Майце на ўвазе, што большасць інфармацыі ў гэтым падзеле грунтуецца на
спадзяванні, што ў сістэме ўжываецца адно з модульных ядраў Debian у
спалучэнні з initramfs-tools
ды
udev
. Калі Вы карыстаецеся ўласным
ядром, у якім не ўжываецца пачатковы адбітак initrd, альбо калі адбіткі
initrd ствараюцца іншай праграмай, частка пададзенай далей інфармацыі можа
не датычыцца Вашай сістэмы.
Падчас абнаўлення з выпуску etch да lenny настойліва рэкамендуецца ўсталяваць новы мета-пакет з ядром linux-image-2.6-*. Гэты пакет можа быць усталяваны аўтаматычна падчас працэсу dist-upgrade. Пераканацца, ці гэта так, можна, запусціўшы каманду:
# dpkg -l "linux-image*" | grep ^ii
Калі Вы не пабачыце ніякіх паведамленняў, тады давядзецца ўсталяваць новы пакет linux-image самастойна. Каб пабачыць спіс даступных метапакетаў з сямейства linux-image-2.6, запусціце каманду:
# apt-cache search linux-image-2.6- | grep -v transition
Калі Вы не ўпэўненыя, які пакет абраць, запусціце каманду uname
-r
і пашукайце пакет з падобнай назвай. Напрыклад, калі Вы
пабачылі '2.6.18-6-686
', варта ўсталяваць пакет
linux-image-2.6-686
. (Майце на
ўвазе, што варыянта k7
болей не існуе; калі зараз у
сістэме ўжываецца ядро варыянта k7
, замест яго трэба
ўсталяваць варыянт 686
.) Таксама можна ўжыць праграму
apt-cache каб пабачыць поўнае апісанне кожнага пакета па
чарзе і абраць найлепшы варыянт з даступных. Напрыклад:
# apt-cache show linux-image-2.6-686
Далей трэба выкарыстаць каманду aptitude install
каб
усталяваць пакет. Пасля таго, як пакет усталяваны, варта пры бліжэйшай
магчымасці перазагрузіцца, каб скарыстацца магчымасцямі новага ядра.
Для тых, хто шукае прыгодаў, існуе лёгкі шлях сабраць уласнае ядро на
Debian GNU/Linux. Дастаткова ўсталяваць пакет kernel-package
і прачытаць дакументацыю ў
/usr/share/doc/kernel-package
.
Калі магчыма, лепей абнаўляць пакет ядра асобна ад працэдуры
dist-upgrade
, каб зменшыць рызыку ад знаходжання сістэмы
ў стане, непрыдатным да запуску. Але майце на ўвазе, што гэта трэба рабіць
пасля мінімальнага абнаўлення, апісанага на старонцы Section 4.5.6, “Мінімальнае абнаўленне сістэмы”.
lenny мае больш магутны механізм пошуку абсталявання, чым папярэднія выпускі. Але ў выніку можа змяніцца парадак вынаходжання прылад, што адаб'ецца і на парадку прызначэння ім назваў. Напрыклад, калі ў сістэме існуюць дзве сеткавых карткі, што абслугоўваюцца дзвюма рознымі драйверамі, пасля абнаўлення прылады eth0 і eth1 могуць "памяняцца месцамі". Майце на ўвазе, што, напрыклад, пры змяненні сеткавай карткі ў сістэме на базе lenny, новая картка таксама будзе асацыяваная з новай назвай сеткавага інтэрфэйсу.
У выпадку сеткавых прылад можна пазбегнуць апісанай змены нумароў,
прызначыўшы адпаведныя правілы udev
,
менавіта праз азначэнні ў файле наладак
/etc/udev/rules.d/70-persistent-net.rules
[4]. Таксама можна скарыстацца утылітай ifrename,
якая дазваляе прывязваць фізічныя прылады да канкрэтных назваў падчас
загрузкі сістэмы. Гл. таксама
ifrename(8) ды
iftab(5). Згаданыя спосабы нельга
выкарыстоўваць адначасова, варта абраць альбо udev
альбо ifrename.
У выпадку прылад для захоўвання файлаў змены нумароў можна пазбегнуць,
наладзіўшы пакет initramfs-tools
такім чынам, каб парадак загрузкі модуляў драйвераў быў такім самым, як да
абнаўлення. Дзеля гэтага, трэба вызначыць існуючы парадак загрузкі модуляў
на падставе вываду каманды lsmod. Каманда
lsmod паказвае спіс модуляў у парадку, адваротным адносна
парадку іхнай загрузкі. Майце на ўвазе, што такі падыход будзе працаваць
толькі для прыладаў, нумары якіх прызначаюцца ядром у аднолькавым парадку
(такіх як, напрыклад, прылады PCI).
Тым не менш, выдаленне і перазагрузка модуляў пасля запуску сістэмы зменіць
гэты парадак. Таксама, некаторыя драйверы могуць быць статычна злучаныя з
ядром, і ў гэтым выпадку іх назвы не будуць прысутнічаць у вывадзе каманды
lsmod. Вы можаце здагадацца аб назвах такіх модуляў і
парадку іх загрузкі, прааналізаваўшы файл
/var/log/kern.log
альбо вывад каманды
dmesg.
Дадайце назвы адпаведных модуляў да
/etc/initramfs-tools/modules
у парадку, які адпавядае
жаданаму парадку іх загрузкі падчас запуску сістэмы. Некаторыя назвы модуляў
маглі змяніцца паміж etch і lenny. Напрыклад, модуль
sym53c8xx_2
змяніў назву на sym53c8xx
.
Пасля гэтага неабходна нанова стварыць адбітак (альбо адбіткі) initramfs,
запусціўшы каманду update-initramfs -u -k all
.
Пасля таго, як сістэма будзе запушчаная на базе ядра з lenny і
пакету udev
, можна наладзіць яе
такім чынам, каб доступ да дыскаў ажыццяўляўся паводле сіноніму (alias), які
б не залежыў ад парадку загрузкі модуляў драйвераў. Cінонімы месцяцца ў
іерархіі /dev/disk
.
Калі для запуску сістэмы ўжываецца створаны з дапамогай initramfs-tools
адбітак initrd, у некаторых
выпадках файлы прыладаў могуць быць створаныя udev
запозна. Гэта прывядзе да немагчымасці
працы скрыптоў запуску з такімі прыладамі.
Звычайнай прыкметай такога становішча з'яўляецца немагчымасць запуску
сістэмы з-за таго, што каранёвая файлавая сістэма не можа быць
прымацаваная. Пры гэтым карыстальнік трапляе ў дапаможную абалонку. Калі
пазней праверыць стан сістэмы, ўсе патрэбныя файлы прыладаў будуць
прысутнічаць у дырэкторыі /dev
. Такое здаралася, калі
каранёвая файлавая сістэма месцілася на USB-дыску альбо на масіве RAID
(асабліва калі пры гэтым выкарыстоўваўся загрузчык
LILO).
Абыйсці праблему можна, вызначыўшы параметр загрузкі
rootdelay=
. Канкрэтная
працягласць затрымкі ў секундах можа быць іншай.
9
Калі aptitude dist-upgrade
скончыць працу,
“фармальнае” абнаўленне будзе выканана, але пры гэтым
застануцца некалькі крокаў, аб якіх варта паклапаціцца да
таго, як рабіць перазагрузку сістэмы.
Калі Вы карыстаецеся загрузчыкам lilo
(гэта быў стандартны варыянт у некаторых
усталяваннях etch), вельмі раім пасля абнаўлення перазапусціць
каманду lilo:
# /sbin/lilo
Майце на ўвазе, што гэты крок патрэбны нават калі ядро сістэмы не абнаўлялася. Справа ў тым, што падчас абнаўлення пакета змяняецца другі ўзровень (second stage) загрузчыка.
Таксама перагледзьце змест файлу /etc/kernel-img.conf
і
пераканайцеся, што ў ім прысутнічае параметр do_bootloader =
Yes
. Параметр гарантуе перазапуск загрузчыка пасля кожнага
абнаўлення ядра.
Калі падчас запуску каманды lilo узнікнуць праблемы,
пераканайцеся, што сімвалічныя спасылкі /vmlinuz
ды
/initrd
адпавядаюць зместу файла наладак
/etc/lilo
.
Калі забыцца перазапусціць каманду lilo альбо калі
сістэма нечакана перазагрузіцца сама да таго, як Вы паспееце зрабіць гэта,
магчыма ўзнікненне памылкі пры спорбе далейшай загрузкі сістэмы. Замест
запрашэння lilo будуць бачныя толькі літары LI
.[5]. Парады па выпраўленні гэтай сітуацыі пададзеныя ў параграфе
Section 4.1.3, “Падрыхтуйцеся да аднаўлення”.
Асобныя карыстальнікі паведамлялі аб тым, што ў іхных сістэмах ядро не здолела знайсці каранёвую файлавую сістэму пасля перазагрузкі.
У такім выпадку загрузка спыняецца пасля вываду паведамлення:
Waiting for root file system ...
і праз некалькі секунд з'яўляецца камандны радок busybox.
Праблема ўзнікае, калі ў выніку абнаўлення ядро пачынае выкарыстоўваюць
драйверы IDE новага пакалення. Паводле пагаднення, якое
выкарыстоўвалася ў старых драйверах, дыскам IDE
прызначаліся назвы hda
, hdb
,
hdc
, hdd
. Новыя драйверы адпаведна
прызначаюць гэтым дыскам назвы sda
,
sdb
, sdc
,
sdd
. Праблема ўзнікае, калі падчас абнаўлення не створана
новай версіі файлу /boot/grub/menu.lst
, якая мусіла б
адлюстроўваць гэтыя змены. У выніку падчас запуску сістэмы загрузчык перадае
ядру назву каранёвага падзела, паводле якой падзел немагчыма знайсці.
Калі згаданая праблема ўзнікла ў Вашай сістэме пасля абнаўлення, скарыстайцеся звесткамі з параграфа Section 4.8.2, “Як выправіць праблему пасля абнаўлення”. Парады наконт таго, як пазбегнуць праблемы загадзя, змешчаныя далей.
Праблемы можна гарантавана пазбегнуць, калі ўжываць ідэнтыфікатар каранёвай файлавай сістэмы, што не будзе змяняцца між перазагрузкамі. Гэтага можна дасягнуць дзвюма шляхамі: або прызначыць метку файлавай сістэме, або ўжываць яе ўніверсальны ідэнтыфікатар (UUID). Абодва спосабы падтрымліваюцца ў Debian пачынаючы з выпуску 'etch'.
Кожны з падыходаў мае свае плюсы і мінусы. Меткі больш спрыяльныя для чытання, але няма гарантыі, што іншая файлавая сістэма не будзе мець такую самую метку. Падыход з выкарыстаннем UUID выглядае менш прывабна, але пры гэтым выключана сітуацыя канфлікту UUID-аў.
У пададзеных ніжэй прыкладах каранёвая файлавая сістэма месціцца на падзеле
/dev/hda6
. Таксама ў сістэме мусяць працаваць udev і
падтрымка фарматаў файлавых сістэм ext2 ды ext3.
Каб выкарыстаць спосаб з прызначэннем меткі:
Прызначце метку (назва мусіць быць не болей за 16 сімвалаў) з дапамогай наступнай каманды: e2label /dev/hda6 rootfilesys
Выпраўце файл наладак /boot/grub/menu.lst
, змяніўшы
радок:
# kopt=root=/dev/hda6 ro
на
# kopt=root=LABEL=rootfilesys ro
![]() | Note |
---|---|
Не выдаляйце знак |
У файле наладак menu.lst
абнавіце радкі, што датычацца
ядраў, запусціўшы каманду update-grub.
Выпраўце файл наладак /etc/fstab
, змяніўшы радок, што
датычыцца мацавання падзелу /
, напрыклад:
/dev/hda6 / ext3 defaults,errors=remount-ro 0 1
на
LABEL=rootfilesys / ext3 defaults,errors=remount-ro 0 1
Змяненне датычыцца толькі першай калонкі адпаведнага радку, астатнія калонкі мусяць застацца такімі самымі, як былі.
Каб выкарыстаць спосаб на базе UUID:
Даведайцеся унікальны ідэнтыфікатар файлавай сістэмы з дапамогай наступнай каманды: ls -l /dev/disk/by-uuid | grep hda6
Вы пабачыце радок накшталт наступнага:
lrwxrwxrwx 1 root root 24 2008-09-25 08:16 d0dfcc8a-417a-41e3-ad2e-9736317f2d8a -> ../../hda6
Унікальным ідэнтыфікатарам з'яўляецца назва сімвалічнай спасылкі, што вядзе
да /dev/hda6
. У пададзеным вышэй прыкладзе гэта
d0dfcc8a-417a-41e3-ad2e-9736317f2d8a
.
![]() | Note |
---|---|
На Вашай канкрэтнай сістэме значэннем UUID будзе нейкі іншы радок. |
Выпраўце файл наладак /boot/grub/menu.lst
, змяніўшы
радок:
# kopt=root=/dev/hda6 ro
на
# kopt=root=UUID=d0dfcc8a-417a-41e3-ad2e-9736317f2d8 ro
![]() | Note |
---|---|
Не выдаляйце знак |
У файле наладак menu.lst
абнавіце радкі, што датычацца
ядраў, запусціўшы каманду update-grub.
Выпраўце файл наладак /etc/fstab
, змяніўшы радок, што
датычыцца мацавання падзелу /
, напрыклад:
/dev/hda6 / ext3 defaults,errors=remount-ro 0 1
на
UUID=d0dfcc8a-417a-41e3-ad2e-9736317f2d8 / ext3 defaults,errors=remount-ro 0 1
Змяненне датычыцца толькі першай калонкі адпаведнага радку, астатнія калонкі мусяць застацца такімі самымі, як былі.
Гэты спосаб можна ўжыць, калі загрузчык Grub дэманструе меню варыянтаў загрузкі. Калі такое меню не з'яўляецца, паспрабуйце націснуць клавішу Esc перад загрузкай ядра. Калі ў меню ўсё адно не атрымалася патрапіць, скарыстайцеся адным з наступных шляхоў: Section 4.8.2.2, “Спосаб 2”, Section 4.8.2.3, “Спосаб 3”.
У меню Grub абярыце пункт, які трэба загрузіць. Націсніце клавішу e, каб перайсці ў рэжым рэдагавання параметраў загрузкі. Вы пабачыце нешта накшталт:
root (hd0,0) kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro initrd /initrd.img-2.6.26-1-686
Перайдзіце на радок
kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro
яшчэ раз націсніце e і замяніце
hd
на
X
sd
(X
X
можа
быць адной з літараў a
, b
,
c
або d
, у залежнасці ад канфігурацыі
Вашай канкрэтнай сістэмы). У згаданым прыкладзе радок мусіць атрымаць
наступны выгляд:
kernel /vmlinuz-2.6.26-1-686 root=/dev/sda6 ro
Потым націсніце клавішу Увод, каб захаваць зменены
радок. Калі назва hd
прысутнічае ў яшчэ нейкіх радках, выпраўце іх адпаведна. Не змяняйце назвы,
якія выглядаюць як X
root (hd0,0)
. Пасля ўсіх змяненняў,
націсніце клавішу b. Сістэма мусіць загрузіцца звычайным
чынам.
Пасля таго, як сістэму атрымаецца загрузіць, трэба будзе выправіць праблему канчаткова. Перайдзіце да параграфа Section 4.8.1, “Як перасцерагчы сябе ад праблемы перад абнаўленнем” і скарыстайцеся адной з пададзеных там парадаў.
Загрузіце сістэму з усталявальнага носьбіту Debian GNU/Linux (CD
або DVD). У адказ на запыт аб варыянтах загрузкі абярыце
рэжым rescue
. Абярыце мову, краіну і раскладку
клавіятуры; дазвольце праграме ўсталявання наладзіць сетку (неважна, ці
атрымаецца гэта ці не). Пасля згаданых крокаў, Вам будзе зададзенае пытанне,
які з падзелаў дыску трэба выкарыстаць як каранёвую файлавую
сістэму. Прапанаваныя варыянты будуць выглядаць прыкладна так:
/dev/ide/host0/bus0/target0/lun0/part1 /dev/ide/host0/bus0/target0/lun0/part2 /dev/ide/host0/bus0/target0/lun0/part5 /dev/ide/host0/bus0/target0/lun0/part6
Калі Вам вядома, на якім з падзелаў месціцца каранёвая файлавая сістэма, абярыце адпаведны варыянт. Калі ўпэўненасці няма, паспрабуйце першы падзел. У выпадку скаргі на неправільную каранёвую сістэму спрабуйце наступны падзел і г.д. Такі перабор не мусіць пашкодзіць Вашыя падзелы, і калі на дыску ўсталяваная толькі адна аперацыйная сістэма, знайсці правільны варыянт атрымаецца хутка. Калі на дыску ўсталяваныя некалькі аперацыйных сістэм, лепей усё ж дакладна ведаць, які з падзелаў патрэбны.
Пасля выбару падзелу, Вам будзе прапанаваны выбар магчымых дзеянняў. Абярыце варыянт з запускам каманднай абалонкі ў абраным падзеле. У выпадку скаргі на немагчымасць выканаць такі запуск паспрабуйце іншы падзел.
У выніку Вы мусіце патрапіць у камандную абалонку з правамі карыстальніка
root
. Каранёвая файлавая сістэма прымацаваная ў
дырэкторыі /target
. Вам неабходна атрымаць доступ да
дырэкторыяў /boot
, /sbin
і
/usr
на сваім жорсткім дыску, якія будуць зараз
даступныя адпаведна як /target/boot
,
/target/sbin
ды /target/usr
. Калі
гэтыя дырэкторыі трэба дадаткова прымацаваць з іншых падзелаў, зрабіце гэта
(гл. файл наладак /etc/fstab
, калі няма ўпэўненасці,
якія канкрэтна падзела варта прымацоўваць).
Перайдзіце да параграфу Section 4.8.1, “Як перасцерагчы сябе ад праблемы перад абнаўленнем” і
скарыстайцеся адной са згаданых там парадаў. Пасля выканання патрэбных
дзеянняў, увядзіце exit
, каб выйсці з каманднай абалонкі
рэжыму ратавання і reboot
, каб перазагрузіць сістэму
звычайным чынам (не забудзьцеся прыбраць усталявальны носьбіт, з якога Вы
загружаліся ў рэжыме ратавання).
Загрузіцеся са сваёго ўлюбёнага LiveCD, такога як Debian Live, Knoppix або Ubuntu Live.
Прымацуйце падзел, на якім знаходзіцца сістэмная дырэкторыя
/boot
. Калі дакладна невядома, які падзел варта
прымацоўваць, скарыстайцеся з вываду каманды dmesg каб
даведацца, якую назву мае жорсткі дыск (магчымыя варыянты:
hda
, hdb
, hdc
,
hdd
або sda
, sdb
,
sdc
, sdd
). Калі вядома, з якім дыскам
трэба працаваць (дзеля прыкладу няхай гэта будзе sdb
),
запусціце наступную каманду, каб пабачыць табліцу падзелаў дыску і
вызначыць, які падзел трэба выкарыстоўваць: fdisk -l
/dev/sdb
Няхай адпаведны падзел атрымалася прымацаваць да дырэкторыі
/mnt
і гэты падзел утрымлівае дырэкторыю
/boot
з адпаведным утрыманнем. Засталося выправіць файл
наладак /mnt/boot/grub/menu.lst
.
Знайдзіце секцыю, якая выглядае падобным чынам:
## ## End Default Options ## title Debian GNU/Linux, kernel 2.6.26-1-686 root (hd0,0) kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro initrd /initrd.img-2.6.26-1-686 title Debian GNU/Linux, kernel 2.6.26-1-686 (single-user mode) root (hd0,0) kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro single initrd /initrd.img-2.6.26-1-686 ### END DEBIAN AUTOMAGIC KERNELS LIST
і замяніце ўсе ўзгадкі hda
, hdb
,
hdc
, hdd
адпаведна на
sda
, sdb
, sdc
,
sdd
. Не змяняйце радок, падобны на:
root (hd0,0)
Перазагрузіце сістэму, прыбярыце загрузачны дыск і Вашая сістэма загрузіцца належным чынам.
Пасля таго як сістэму атрымалася загрузіць, скарыстайцеся адной з парадаў, пададзеных у параграфе Section 4.8.1, “Як перасцерагчы сябе ад праблемы перад абнаўленнем”, каб выправіць праблему канчаткова.
Існуе некалькі крокаў, якія можна выканаць пасля абнаўлення, каб падрыхтаваць сістэму да наступнага выпуску.
Калі пакет з новай версіяй ядра быў усталяваны дзеля развязання залежнасцяў пакета са старой версіяй, ён будзе пазначыны як усталяваны аўтаматычна. Гэта варты выправіць:
# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1)
Прыбярыце састарэлыя і непатрэбныя пакеты, паводле параграфу Section 4.10, “Састарэлыя пакеты”. Варта праверыць, якія файлы наладак выкарыстоўваюць гэтыя пакеты і разгледзець магчымасць поўнага выдалення, уключна з файламі наладак.
Прадстаўляючы карыстальніку некалькі тысячаў новых пакетаў, lenny адначасова пазбаўляецца прыкладна двух тысячаў састарэлых пакетаў, якія ўваходзілі ў etch. Для такіх пакетаў не існуе магчымасці абнаўлення. Нішто не замінае карыстацца састарэлымі пакетамі, але праект Debian звычайна спыняе падтрымку абнаўленняў бяспекі для іх праз год пасля выпуску lenny[6], i не забяспечвае ніякай іншай падтрымкі. Раім замяніць састарэлыя пакеты на аналагі, калі гэта магчыма.
Існуе шмат прычынаў, чаму пакет можа быць выдалены з дыстрыбутыву: спыненне падтрымкі асноўным распрацоўшчыкам; адсутнасць афіцыйных распрацоўшчыкаў Debian, якім было б цікава надалей падтрымліваць пакет; функцыянальнасць, якую забяспечвае пакет, перакрываецца магчымасцямі іншых праграм (альбо найноўшага пакалення такой самай праграмы); урэшце, выключэнне пакету з lenny можа быць выкліканае колькасцю выяўленых і не выпраўленых памылак. У апошнім выпадку выдалены пакет можа надалей прысутнічаць у “нестабільным” дыстрыбутыве.
Высветліць, якія менавіта пакеты ў абноўленай сістэме з'яўляюцца “састарэлымі”, даволі лёгка: яны адпаведным чынам пазначаюцца ў інтэрфэйсах праграм для кіравання пакетамі. Праграма aptitude пералічвае такія пакеты ў секцыі “Састарэлыя і лакальна створаныя пакеты”. Праграма dselect забяспечвае аналагічную секцыю, але выгляд спісу ў ёй можа адрознівацца.
Праграма aptitude захоўвае спіс пакетаў, якія былі ўсталяваныя з яе дапамогай у лакальным рэжыме. Таксама aptitude можа пазначыць як састарэлыя тыя пакеты, што былі ўсталяваныя выключна дзеля развязання залежнасцяў і больш не патрэбныя пасля выдалення пакета, які ад іх залежыў. У адрозненне ад deborphan, aptitude не пазначае ўсталяваныя лакальна пакеты, як састарэлыя.
Існуюць дадатковыя праграмныя сродкі пошуку састарэлых пакетаў, напрыклад,
deborphan, debfoster або
cruft. Лепш за ўсё выкарыстоўваць
deborphan, нягледзячы на тое, што ў стандартным рэжыме ён
паведаміць толькі аб састарэлых бібліятэках (пакетах з секцыяў
“libs
” або
“oldlibs
”, якія не выкарыстоўваюцца ніякімі
іншымі пакетамі). Не варта безаглядна выдаляць усё, што пералічана ў вывадзе
згаданых праграмаў, асабліва, калі ўжываюцца нестандартныя агрэсіўныя
наладкі, якія дакладна могуць прыводзіць да фальшывых спрацоўванняў. Дужа
раім перагледзець па адным усе пакеты, прапанаваныя да выдалення (г.зн. іх
змесціва, памер і апісанне) перад тым, як прымаць рашэнне на карысць
выдалення.
Сістэма кантролю памылак Debian часта ўтрымлівае дадатковыя звесткі аб прычынах выдалення таго ці іншага пакета з дыстрыбутыву. Варта перагледзець архіў паведамленняў аб памылках для самога пакета а таксама для псеўда-пакета ftp.debian.org.
У спіс састарэлых пакетаў уваходзяць:
Некаторыя пакеты з etch у lenny падзеленыя на некалькі розных пакетаў, збольшага дзеля паляпшэння магчымасцяў кіравання сістэмай. Каб палегчыць абнаўленне ў такіх выпадках lenny часта забяспечвае “фіктыўныя (dummy)” пакеты, якія залежаць ад новых такім чынам, каб забяспечыць іх усталяванне. Такія “фіктыўныя” пакеты пасля абнаўлення лічацца састарэлымі і іх можна бесперашкодна выдаляць.
У большасці выпадкаў (але не заўсёды) апісанні фіктыўных пакетаў
утрымліваюць звесткі аб іх прызначэнні. Тым не менш, стандартнага шляху
апісання фіктыўных пакетаў няма, таму можна дадаткова выкарыстаць
deborphan з параметрам --guess
дзеля
іх пошуку. Майце на ўвазе, што некаторыя фіктыўныя пакеты не разлічаныя на
выдаленне, бо яны могуць ужывацца дзеля кантролю версіяў адпаведнай
праграмы.
[2] Гэтую магчымасць можна адключыць, дадаўшы параметр
panic=0
да спісу параметраў загрузкі.
[3] Сістэма кіравання пакетамі Debian звычайна не дазваляе пакетам выдаляць альбо замяняць файлы, якія належаць іншым пакетам (за выключэннем выпадкаў калі адзін пакет фармальна з'яўляецца заменай іншага).
[4]
Правілы ў гэтым файле аўтаматычна ствараюцца скрыптом
/etc/udev/rules.d/75-persistent-net-generator.rules
,
каб забяспечыць сталыя назвы для сеткавых інтэрфэйсаў. Калі выдаліць гэтую
сімбалічную спасылку, рэжым нязменных назваў для сеткавых картак будзе
адключаны.
[5] Больш інфармацыі аб кодах памылак lilo змешчана на старонцы The Linux Bootdisk HOWTO.
[6] Альбо з выхадам наступнага выпуску. Звычайна, толькі два стабільных выпускі падтрымліваюцца адначасова.