Table of Contents
Waiting for root file system
എന്നു് പറഞ്ഞു് സിസ്റ്റം
ബൂട്ട് സ്തംഭിയ്ക്കുന്നുനവീകരിക്കുന്നതിനു മുമ്പായി ഇതു Chapter 5, lenny യെക്കുറിച്ചു് അറിഞ്ഞിരിക്കേണ്ട പ്രശ്നങ്ങള് കൂടി വായിക്കാന് താല്പര്യപ്പെടുന്നു.നവീകരിക്കല് പ്രക്രിയയുമായി നേരിട്ടു ബന്ധമില്ലാത്ത ചില സുപ്രധാന പ്രശ്നങ്ങള് ഈ അധ്യായത്തില് പറഞ്ഞിട്ടുണ്ട്. പ്രക്രിയ തുടങ്ങുന്നതിനു മുമ്പ് ഇവ അറിഞ്ഞിരിക്കുന്നതു നന്നായിരിക്കും.
നിങ്ങളുടെ സിസ്റ്റം നവീകരിയ്ക്കുന്നതിനു് മുമ്പു് നിങ്ങള് ഒരു മുഴുവന് കരുതല് പകര്പ്പു് അല്ലെങ്കില് ഒരു കാരണവശാലും നഷ്ടപ്പെടാന് പറ്റാത്ത ഡാറ്റയുടേയോ ക്രമീകരണ വിവരത്തിന്റേയോ കരുതല് പകര്പ്പു് എടുത്തിരിയ്ക്കണമെന്നു് ശുപാര്ശ ചെയ്തിരിയ്ക്കുന്നു. നവീകരിയ്ക്കാനുള്ള ഉപകരണങ്ങള് വളരെ വിശ്വസ്ഥമാണു്, എങ്കിലും നവീകരണത്തിനിടയില് ഒരു ഹാര്ഡ്വെയര് തകരാറു് വന്നാല് സിസ്റ്റം വളരെ ഗുരുതരമായി പരിക്കേറ്റ അവസ്ഥയില് കിടന്നേയ്ക്കാം.
നിങ്ങള്ക്കു് കരുതല് പകര്പ്പെടുക്കേണ്ടി വരുന്ന പ്രധാന സംഗതികള്
/etc
, /var/lib/dpkg
,
/var/lib/aptitude/pkgstates
എന്നിവയുടെ ഉള്ളടക്കവും
dpkg --get-selections "*"
(ക്വോട്ടുകള് പ്രധാനമാണു്)
എന്നതിന്റെ ഫലവുമാണു്.
നവീകരണ പ്രക്രിയ സ്വന്തമായി /home
തട്ടിലെ ഒന്നും
മാറ്റുകയില്ല. എന്നാല്, ചില പ്രയോഗങ്ങള് (ഉദാ. മോസില്ല സ്വീറ്റിലെ ഭാഗങ്ങള്,
ഗ്നോം, കെഡിഇ പണിയിട പരിസരങ്ങള്) ഒരു ഉപയോക്താവു് ആദ്യമായി അവയുടെ പുതിയ
പതിപ്പുകള് തുടങ്ങുമ്പോള് നിലവിലുള്ള ഉപയോക്താവിന്റെ സജ്ജീകരണങ്ങള്
മായ്ച്ചു് കളഞ്ഞു് പകരമായി പുതിയവയുടെ സഹജവിലകള് എഴുതുന്നതായി
കേട്ടിട്ടുണ്ടു്. ഒരു മുന്കരുതലായി ഉപയോക്താവിന്റെ ആസ്ഥാന തട്ടുകളിലെ
ഒളിപ്പിച്ച ഫയലുകളുടേയും തട്ടുകളുടേയും (“dotfiles”) ഒരു കരുതല്
പകര്പ്പെടുത്തു് വച്ചേയ്ക്കൂ. ഈ കരുതല് പകര്പ്പു് പഴയ സജ്ജീകരണങ്ങള്
തിരിച്ചു് വയ്ക്കാനോ പുനര്നിമ്മിയ്ക്കാനോ സഹായിച്ചേയ്ക്കാം. ഉപയോക്താക്കളെ
ഇതിനെക്കുറിച്ചറിച്ചേയ്ക്കൂ.
പൊതികള് ഇന്സ്റ്റോള് ചെയ്യാനുള്ള നടപടികളെല്ലാം സൂപ്പര്ഉപയോക്താവിന്റെ
അനുമതികളോടെ പ്രവര്ത്തിപ്പിയ്ക്കേണ്ടതിനാല് root
ആയി
അകത്തുകയറുകയോ ആവശ്യമായി അനുമതികള് കിട്ടാന് su
അല്ലെങ്കില് sudo ആജ്ഞകള് ഉപയോഗിയ്ക്കുകയോ ചെയ്യാം.
നവീകരിക്കല് പ്രക്രിയയ്ക്കു കുറച്ചു മുന് ഉപാധികളുണ്ടു്.; നവീകരിക്കുന്നതിനു മുമ്പ് അവയെല്ലാം പരിശോധിക്കേണ്ടതാണു്.
ssh ബന്ധം വഴി നിങ്ങളുടെ സിസ്റ്റം ഉപയോഗിയ്ക്കുന്ന ഉപയോക്താക്കള്ക്കു് നവീകരണത്തിനിടയില് അസാധാരണമായെന്തെങ്കിലും അറിയാതെ തുടര്ന്നു പ്രവര്ത്തിയ്ക്കാന് സാധിയ്ക്കുമെങ്കിലും നിങ്ങള് തയ്യാറെടുത്തുകൊണ്ടിരിയ്ക്കുന്ന നവീകരണത്തെക്കുറിച്ചു് നിങ്ങളുടെ ഉപയോക്താക്കളെ അറിയിയ്ക്കുന്നതു് ബുദ്ധിപരമാണു്.
ഇനിയും കൂടുതല് മുന്കരുതലെടുക്കണമെന്നുണ്ടെങ്കില് നവീകരണത്തിന് മുമ്പ്
ഉപയോക്താക്കളുടെ ഭാഗങ്ങളുടെ (/home
) കരുതല്
പകര്പ്പെടുക്കുകയോ അവ വേര്പ്പെടുത്തുകയോ ചെയ്യാം.
lenny യിലേയ്ക്കു് കയറുമ്പോള് നിങ്ങള്ക്കു് കെര്ണല് പുതുക്കേണ്ടി വരാനുള്ള സാധ്യതയുള്ളതിനാല് സാധാരണയായി ഒരു റീബൂട്ട് ആവശ്യമാണു്. പൊതുവെ ഇതു് നവീകരണം കഴിഞ്ഞ ശേഷമാണു് ചെയ്യാറു്.
etch നും lenny യ്ക്കുമിടയില് കെര്ണലില് പ്രവര്ത്തകങ്ങള്, ഹാര്ഡ്വെയര് കണ്ടെത്തല്, ഉപകരണ ഫയലുകളുടെ പേരും സ്ഥാനവും നിര്ണ്ണയിയ്ക്കുന്നതു് തുടങ്ങി വളരെയധികം മാറ്റങ്ങള് വന്നതു് കൊണ്ടു് നവീകരണത്തിനു് ശേഷം നിങ്ങള്ക്കു് വീണ്ടും ബൂട്ട് ചെയ്യാന് പറ്റാതാവാനുള്ള ശരിയ്ക്കുമൊരു അപകടമസാധ്യതയുണ്ടു്. ഈ പ്രസാധനക്കുറിപ്പുകളുടെ ഈ അദ്ധ്യായത്തിലും വരാനുള്ളവയിലും വളരെയധികം അറിയാവുന്ന പ്രശ്ന സാധ്യതകളെക്കുറിച്ചു് വിവരിച്ചിട്ടുണ്ടു്.
ആ കാരണം കൊണ്ടു് തന്നെ നിങ്ങളുടെ സിസ്റ്റം വീണ്ടും ബൂട്ട് ചെയ്യുന്നതില് പരാജയപ്പെടുകയോ വിദൂരത്തുള്ള സിസ്റ്റങ്ങളില് ശൃംഖലാബന്ധം തുടങ്ങാന് പരാജയപ്പെടുകയോ ചെയ്താല് നിങ്ങളുടെ സിസ്റ്റം പഴയ അവസ്ഥയില് കൊണ്ടു് വരാന് സാധ്യമാണെന്നുറപ്പു് വരുത്തുന്നതു് നല്ലതാണു്.
നിങ്ങള് ദൂരെയിരുന്നൊരു ssh ബന്ധത്തിലൂടെയാണു് നവീകരിയ്ക്കുന്നതെങ്കില് വിദൂരമായ സീരിയല് കണ്സോള് വഴി സെര്വറിനെ സമീപിയ്ക്കാന് സാധ്യമാകുന്ന തരത്തിലുള്ള എല്ലാ മുന്കരുതലുകളുമെടുക്കാന് ശക്തമായി ശുപാര്ശ ചെയ്യുന്നു. കെര്ണല് പുതുക്കി വീണ്ടും ബൂട്ട് ചെയ്യുമ്പോള് ചില ഉപകരണങ്ങളുടെ പേരുകള് മാറിയിരിയ്ക്കാന് (Section 4.6.2, “ഉപകരണങ്ങള്ക്കു് സംഖ്യയിടുന്നതില് മാറ്റം” ല് വിശദീകരിച്ചിരിയ്ക്കുന്നു) സാധ്യതയുള്ളതു് കൊണ്ടു് ഒരു പ്രദേശിക കണ്സോളിലൂടെ നിങ്ങളുടെ സിസ്റ്റം ക്രമീകരണം ശരിയാക്കേണ്ടി വരാം. നവീകരണത്തിനിടയില് സിസ്റ്റം വീണ്ടും ബൂട്ടു് ചെയ്യുകയാണെങ്കില് ഒരു പ്രാദേശിക കണ്സോളുപയോഗിച്ചു് വീണ്ടെടുക്കേണ്ടിയും വന്നേയ്ക്കാം.
ആദ്യമായി ചെയ്യേണ്ടതു നിങ്ങളുടെ കമ്പ്യുട്ടറിലെ പഴയ കെര്ണല് വച്ച് റീബൂട്ട് ചെയ്യുക എന്നതാണു് . എന്നാലും, ഈ വിവരണത്തില് മറ്റു പലയിടത്തും പറഞ്ഞ കാരണങ്ങള് കൊണ്ട്, ഇതു പ്രവര്ത്തിക്കുമെന്നു ഉറപ്പില്ല.
അതു പരാജയപ്പെടുകയാണെങ്കില്, നിങ്ങളുടെ സിസ്റ്റം ബൂട്ട് ചെയ്യാന് മറ്റൊരു വഴി
വേണ്ടതാണു്. പ്രത്യേകമായി തയ്യാറാക്കിയ ഒരു റെസ്ക്യു ഇമേജോ ലിനക്സ് ലൈവ് സിഡിയോ
ഉപയോഗിക്കുകയാണു് ഒരു വഴി. ഇതു ഉപയോഗിച്ച് ബൂട്ട് ചെയ്തതിനുശേഷം, റൂട്ട് ഫയല്
സിസ്റ്റം മൌണ്ട് ചെയ്തു chroot
ഉപയോഗിച്ച് പ്രശ്നം കണ്ടു
പിടിച്ച് പരിഹരിക്കാവുന്നതാണു്.
ഞങ്ങള് ശുപാര്ശ ചെയ്യുന്ന മറ്റൊരു വഴി lenny ഡെബിയന് ഇന്സ്റ്റോളറിന്റെ rescue mode ഉപയോഗിയ്ക്കാനാണു്. ഇന്സ്റ്റോളര് ഉപയോഗിയ്ക്കുന്നതു് കൊണ്ടുള്ള മെച്ചം നിങ്ങള്ക്കു് പല ഇന്സ്റ്റലേഷന് രീതികളില് നിന്നും നിങ്ങളുടെ അവസ്ഥയ്ക്കനുയോജ്യമായ രീതി തെരഞ്ഞെടുക്കാം എന്നതാണു്. കൂടുതല് വിവരങ്ങള്ക്കു് ഇന്സ്റ്റലേഷന് വഴികാട്ടിയിലെ 8 മത്തെ അദ്ധ്യായത്തിലെ “Recovering a Broken System” എന്ന ഭാഗവും ഡെബിയന് ഇന്സ്റ്റോളറിനെക്കുറിച്ചുള്ള ചോദ്യോത്തരങ്ങളും കാണുക.
initramfs-tools
ഒരു പിഴവു്
തിരുത്താനുള്ള ഷെല് ഉള്ക്കൊള്ളുന്നു[2] ഇതു് സൃഷ്ടിയ്ക്കുന്ന ഇനിറ്റാര്ഡികളില്. ഉദാഹരണത്തിനു് ഈ
ഇനിറ്റാര്ഡി നിങ്ങളുടെ റൂട്ട് ഫയല് സിസ്റ്റം ചേര്ക്കുന്നതില്
പരാജയപ്പെട്ടാല്, ഈ പ്രശ്നത്തിന്റെ കാരണം കണ്ടുപിടിയ്ക്കാനും ഒരു പക്ഷേ
പരിഹാരം കാണാനും സഹായകമാകുന്ന അടിസ്ഥാന ആജ്ഞകള് ലഭ്യമായ ഈ പിഴവു്
തിരുത്താനുള്ള ഷെല്ലില് നിങ്ങള് എത്തിച്ചേരും.
പരിശോധിയ്ക്കേണ്ട അടിസ്ഥാന കാര്യങ്ങളിവയാണു്: /dev
ല്
ശരിയായ ഉപകരണ ഫയലുകള്; ഏതൊക്കെ ഭാഗങ്ങളാണു് ചേര്ത്തിരിയ്ക്കുന്നതു്
(cat /proc/modules
); പ്രവര്ത്തകങ്ങള്
ചേര്ക്കുമ്പോഴുണ്ടായ പിശകുകള്ക്കു് dmesg ന്റെ
ഫലം. dmesg ന്റെ ഫലം ഏതൊക്കെ ഉകരണ ഫയലുകള് ഏതൊക്കെ
ഡിസ്ക്കുകള്ക്കു് നല്കിയിരിയ്ക്കുന്നു എന്നതു് കാണിയ്ക്കും; echo
$ROOT
എന്നതിന്റെ ഫലവുമായി ഒത്തുനോക്കി പ്രതീക്ഷിച്ച ഉപകരണത്തില്
തന്നെയാണു് റൂട്ട് ഫയല് സിസ്റ്റം എന്നു് നിങ്ങള് പരിശോധിയ്ക്കണം.
നിങ്ങള് പ്രശ്നം പരിഹരിയ്ക്കുന്നതില് വിജയിച്ചാല് exit
എന്നടിച്ചാല് അതു് നിങ്ങളെ പിഴവു് തിരുത്താനുള്ള ഷെല്ലില് നിന്നും പുറത്തു്
കൊണ്ടുവരുകയും പരാജയപ്പെട്ട സ്ഥാനത്തു് നിന്നും ബൂട്ട് പ്രക്രിയ തുടരുകയും
ചെയ്യും. തീര്ച്ചയായും അടുത്ത ബൂട്ട് പരാജയമാവില്ലെന്നുറപ്പാക്കാന് നിങ്ങള്
അടിസ്ഥാന പ്രശ്നം പരിഹരിച്ചു് ഇനിറ്റാര്ഡി വീണ്ടു് സൃഷ്ടിയ്ക്കണം.
വിതരണത്തിന്റെ നവീകരണം പദാവലി ദശയിലെ മായാ കണ്സോളില് (അല്ലെങ്കില് നേരിട്ടു് കുത്തിയ സീരിയല് ടെര്മിനലില്) നിന്നും പ്രാദേശികമായോ, അല്ലെങ്കില് വിദൂരമായി ഒരു ssh ബന്ധം വഴിയോ ചെയ്യണം.
ദൂരെ നിന്നും നവീകരിയ്ക്കുമ്പോള് കൂടുതല് സുരക്ഷയ്ക്കായി വിദൂര ബന്ധം നല്കുന്ന പ്രക്രിയ പരാജയപ്പെട്ടാല് കൂടി നവീകരണ പ്രക്രിയ തടസ്സപ്പെടില്ല എന്നതുറപ്പാക്കാന് വീണ്ടും ബന്ധിപ്പിയ്ക്കുന്നതു് സാധ്യമായ screen പ്രോഗ്രാം നല്കുന്ന മായാ കണ്സോളില് വച്ചു് നവീകരണ പ്രക്രിയ പ്രവര്ത്തിപ്പിയ്ക്കണം.
![]() | Important |
---|---|
നിങ്ങള് telnet, rlogin, rsh, അല്ലെങ്കില് നിങ്ങള് നവീകരിയ്ക്കുന്ന മഷീനിലുള്ള xdm, gdm or kdm തുടങ്ങിയവ കൈകാര്യം ചെയ്യുന്നൊരു എക്സ് പ്രവര്ത്തനവേളയില് വച്ചോ നിങ്ങള് നവീകരണം നടത്തരുതു്. ഈ പറഞ്ഞ ഓരോ സേവനങ്ങളും നവീകരണത്തിനിടയില് നിന്നു പോകുകയും നിങ്ങളുടെ സിസ്റ്റം പകുതി നവീകരിച്ചതും കയറാന് സാധ്യമല്ലാത്തതുമായ അവസ്ഥയില് വരാനും സാധ്യതയുണ്ടു് എന്നതാണു് അതിനു് കാരണം. |
initramfs-tools
ഇപ്പോള്
സൃഷ്ടിയ്ക്കുന്ന initramfs ലിലോയ്ക്കു്
എടുക്കാവുന്നതിനേക്കാളും വളരെ വലുതാണു് എന്നു് ലിലോ
ബൂട്ട്ലോഡര് ഉപയോഗിയ്ക്കുന്നവര് ഓര്ക്കണം. അങ്ങനെയുള്ളവര് grub
ലേയ്ക്കു് മാറുകയോ
/etc/initramfs-tools/initramfs.conf
എന്ന ഫയല്
തിരുത്തി, താഴെ പറഞ്ഞ വരി മാറ്റണം
MODULES=most
വായിക്കാനുള്ളതു
MODULES=dep
എന്നിരുന്നാലും ഇങ്ങനെ ചെയ്യുന്നത് initramfs-tools
പ്രവര്ത്തിയ്ക്കുന്ന
വാസ്തുവിദ്യയ്ക്കുള്ള ഭാഗങ്ങള് മാത്രം initramfs ലേയ്ക്ക് ഇന്സ്റ്റോള്
ചെയ്യുന്നതിന് കാരണമാകും; നിങ്ങള്ക്ക് സൃഷ്ടിയ്ക്കുന്ന വാസ്തുവിദ്യയേക്കാളും
കൂടുതല് ഹാര്ഡ്വെയറില് പ്രവര്ത്തിയ്ക്കുന്ന ബൂട്ട് മാദ്ധ്യമം
സൃഷ്ടിയ്ക്കണമെങ്കില് നിങ്ങള് സജ്ജീകരണം താഴെ പറയുന്ന പോലെ വയ്ക്കുകയും
MODULES=most
ലിലോ ഉപയോഗിയ്ക്കുന്നില്ലെന്നു് ഉറപ്പുവരുത്തുകയും വേണം.
ഈ അദ്ധ്യായത്തില് വിവരിച്ച നവീകരണ പ്രക്രിയ മറ്റുള്ളവരില് നിന്നുള്ള പൊതികളില്ലാത്ത “ശുദ്ധമായ” etch ല് നിന്നും കയറാനുള്ളതായാണു് രൂപകല്പന ചെയ്തിരിയ്ക്കുന്നതു്. ഏറ്റവും കൂടി ഉറപ്പിനു് മറ്റുള്ളവരില് നിന്നുളള പൊതികള് നവീകരണത്തിനു് മുമ്പു് നീക്കം ചെയ്യുന്നതു് നന്നായിരിയ്ക്കും.
ഈ രീതി നിങ്ങള് etch ന്റെ ഏറ്റവും പുതിയ പോയിന്റ് പതിപ്പിലേയ്ക്കു് കയറിയിട്ടുണ്ടെന്നു് ഊഹിയ്ക്കുന്നു. നിങ്ങളിതു് ചെയ്തിട്ടില്ലെങ്കിലോ ഉറപ്പില്ലെങ്കിലോ Section A.1, “നിങ്ങളുടെ പഴയ etch സിസ്റ്റത്തെ അപ്ഗ്രേഡ് ചെയ്യാന്” ല് നല്കിയ നിര്ദ്ദേശങ്ങള് പിന്തുടരുക.
ചില സമയങ്ങളില് പൊതികള് ഇന്സ്റ്റോള് ചെയ്യാന് aptitude നു് പകരം apt-get ഉപയോഗിയ്ക്കുന്നതു് aptitude ആ പൊതിയെ “ഉപയോഗിയ്ക്കാത്തതു് (unused)” ആയി കണക്കാക്കുവാനും നീക്കം ചെയ്യാനുള്ളവയുടെ പട്ടികയില് ചേര്ക്കാനും കാരണമാകും. പൊതുവെ, നവീകരണത്തിനു് മുമ്പേ നിങ്ങളുടെ സിസ്റ്റം ഏറ്റവും പുതിയതും (fully up-to-date) “വൃത്തിയുള്ളതും (clean)” ആണെന്നു് ഉറപ്പാക്കണം.
ഇതു കാരണം aptitudeപൊതിനിര്വ്വാഹകത്തില് എന്തെങ്കിലും
നടപടിക്രമങ്ങള് ബാക്കിയുണ്ടോ എന്ന് പരിശോധിക്കേണ്ടിയിരിക്കുന്നു. ഏതെങ്കിലും
പൊതികള് പുതുക്കാനോ നീക്കം ചെയ്യാനോ നിര്വ്വാഹകത്തില് ചട്ടം
കെട്ടിയിട്ടുണ്ടെങ്കില് അത് പുതുക്കല് നാപടിയെ പ്രതികൂലമായി
ബാധിക്കും. നിങ്ങളുടെ
സ്രോതസ്സ്.പട്ടിക
stable ഓ
അല്ലെങ്കില് lennyഓ അല്ലാതെ
etchലേക്ക് മുഖം തിരിച്ചിരിക്കുകയാണെങ്കില്
മാത്രമേ ഇത് ശരിപ്പെടുത്താന് കഴിയൂ എന്ന് ശ്രദ്ധിക്കുമല്ലൊ ; Section A.2, “നിങ്ങളുടെ സോഴ്സ് പട്ടിക പരിശോധിയ്ക്കുന്നതു്”കാണുക.
പുന:പരിശോധനക്കായി “visual mode” ല് aptitude വിക്ഷേപിച്ച് g (“Go”)അമര്ത്തുക. എന്തെങ്കിലും പ്രതികരണം കാണുകയാണെങ്കില് അവ പരിശോധിച്ച് തെറ്റുകള് തിരുത്തുകയോ നിര്ദ്ദേശിക്കപ്പെട്ട നടപടികള് നടപ്പിലാക്കുകയോ ചെയ്യണം. നടപടിക്രമങ്ങളൊന്നും നിര്ദ്ദേശിക്കപ്പെട്ടിട്ടില്ലെങ്കില് “പൊതികള് പ്രതിഷ്ഠിക്കാനോ, പുതുക്കാനോ, നീക്കം ചെയ്യാനോ ഇല്ല”എന്ന് ഒരു സന്ദേശം പ്രദര്ശിപ്പിക്കപ്പെടും.
നിങ്ങള് സ്റ്റേബിള് അല്ലാത്തൊരു വിതരണത്തില് നിന്നും (ഉദാ. ടെസ്റ്റിങ്ങ്)
ചില പൊതികള് ഇന്സ്റ്റോള് ചെയ്യാന് ആപ്റ്റ് ക്രമീകരിച്ചിട്ടുണ്ടെങ്കില്,
പുതിയ സ്റ്റേബിള് പതിപ്പില് നിന്നുള്ള പൊതികളുടെ പതിപ്പുകളേയ്ക്കു്
കയറ്റുവാന് നിങ്ങളുടെ ആപ്റ്റ് പിന്നിങ്ങ് ക്രമീകരണം
(/etc/apt/preferences
ല് സൂക്ഷിച്ചിരിയ്ക്കുന്നു)
മാറ്റേണ്ടി വന്നേയ്ക്കാം. ആപ്റ്റ് പിന്നിങ്ങിനെക്കുറിച്ചുള്ള കൂടുതല്
വിവരങ്ങള് apt_preferences(5) ല് കാണാം.
നവീകരിയ്ക്കാനുള്ള മാര്ഗ്ഗം ഏതു് തന്നെ തെരഞ്ഞെടുത്താലും എല്ലാ പൊതികളുടേയും അവസ്ഥയെന്താണെന്നു് പരിശോധിയ്ക്കാനും എല്ലാ പൊതികളും നവീകരിയ്ക്കാവുന്ന അവസ്ഥയിലാണെന്നുറപ്പു് വരുത്താനും ശക്തമായി ശുപാര്ശ ചെയ്തിരിയ്ക്കുന്നു. താഴെ പറയുന്ന ആജ്ഞകള് പകുതി-ഇന്സ്റ്റോള് ചെയ്തതോ ക്രമീകരിയ്ക്കാന്-പരാജയപ്പെട്ടതോ ഏതെങ്കിലും തരത്തിലുള്ള പിശകു് വന്ന അവസ്ഥയിലുള്ള പൊതികളുടെ പട്ടിക കാണിയ്ക്കും.
# dpkg --audit
നിങ്ങളുടെ സിസ്റ്റത്തിലെ എല്ലാ പൊതികളുടേയും അവസ്ഥ dselect, aptitude എന്നിവയുപയോഗിച്ചോ അല്ലെങ്കില് താഴെ പറയുന്ന ആജ്ഞകള് ഉപയോഗിച്ചോ പരിശോധിയ്ക്കാവുന്നതാണു്
# dpkg -l | pager
അല്ലെങ്കില്
# dpkg --get-selections "*" > ~/curr-pkgs.txt
തടഞ്ഞുവച്ചിരിയ്ക്കുന്നവയേതെങ്കിലുമുണ്ടെങ്കില് നവീകരണത്തിനു് മുമ്പു് അവ നീക്കം ചെയ്യുന്നതാണു് നല്ലതു്. നവീകരണത്തിനത്യാവശ്യമുള്ള ഏതെങ്കിലും പൊതി തടഞ്ഞുവച്ചിരിയ്ക്കുകയാണെങ്കില് നവീകരണം പരാജയപ്പെടും.
apt-get ഉം dselect ഉം പൊതികള് തടഞ്ഞുവയ്ക്കാന് ഉപയോഗിയ്ക്കുന്ന രീതിയില് നിന്നും വ്യത്യസ്തമായാണു് aptitude തടയാനുള്ള പൊതികളെ രേഖപ്പെടുത്തുന്നതെന്നു് ഓര്ക്കുക. aptitude തടഞ്ഞുവച്ച പൊതികളെ നിങ്ങള്ക്കു് താഴെ പറയുന്ന ആജ്ഞ ഉപയോഗിച്ചു് തിരിച്ചറിയാം.
# aptitude search "~ahold" | grep "^.h"
apt-get ഉപയോഗിച്ചു് തടഞ്ഞുവച്ച പൊതികള് പരിശോധിയ്ക്കണമെങ്കില് നിങ്ങള് ഉപയോഗിയ്ക്കേണ്ടതു്
# dpkg --get-selections | grep hold
നിങ്ങളൊരു പൊതി പ്രാദേശികമായി മാറ്റം വരുത്തുകയും വീണ്ടും കമ്പൈല് ചെയ്യുകയും പേരു് മാറ്റാതിരിയ്ക്കുകയോ പതിപ്പില് സമയം രേഖപ്പെടുത്താതിരിയ്ക്കുകയോ ചെയ്തിട്ടുണ്ടെങ്കില് അതിനെ നവീകരിയ്ക്കുന്നതില് നിന്നും ഒഴിവാക്കാന് നിങ്ങളതിനെ തടഞ്ഞുവയ്ക്കണം.
aptitude നുള്ള പൊതിയുടെ “തടഞ്ഞുവച്ച (hold)”അവസ്ഥ മാറ്റാന് താഴെ പറയുന്ന ആജ്ഞ ഉപയോഗിയ്ക്കാം:
# aptitude hold package_name
hold
നു് പകരം unhold
ഉപയോഗിച്ചു്
“hold” അവസ്ഥ ഇല്ലാതാക്കാം.
നിങ്ങള്ക്കെന്തെങ്കിലും പരിഹരിയ്ക്കാന് ബാക്കിയുണ്ടെങ്കില് Section A.2, “നിങ്ങളുടെ സോഴ്സ് പട്ടിക പരിശോധിയ്ക്കുന്നതു്” ല് പറഞ്ഞ പോലെ sources.list
ഇപ്പോഴും etch നെയാണു് സൂചിപ്പിയ്ക്കുന്നതെന്നുറപ്പാക്കുക.
proposed-updates
വിഭാഗം
/etc/apt/sources.list
ഫയലില് നിങ്ങള്
ചേര്ത്തിട്ടുണ്ടെങ്കില്, നവീകരിയ്ക്കാന് ശ്രമിയ്ക്കുന്നതിനു് മുമ്പു്
നിങ്ങളതു് നീക്കം ചെയ്യണം. കൂട്ടിമുട്ടലിനുള്ള സാധ്യത തടയാനുള്ള
മുന്കരുതലാണതു്.
നിങ്ങളുടെ സിസ്റ്റത്തില് ഡെബിയനു് പുറമെ നിന്നുള്ള
പൊതികളേതെങ്കിലുമുണ്ടെങ്കില് ആശ്രയത്വങ്ങളുടെ കൂട്ടിമുട്ടലുകള് മൂലം
നവീകരണത്തിനിടയില് ഇവ നീക്കം ചെയ്യപ്പെടാമെന്നു്
മനസ്സിലാക്കിയിരിയ്ക്കണം. നിങ്ങളുടെ
/etc/apt/sources.list
ല് അധികം വരികള് ചേര്ത്താണു്
നിങ്ങള് ഇവ ഇന്സ്റ്റോള് ചെയ്തതെങ്കില് lenny യ്ക്കു് വേണ്ടി
കമ്പൈല് ചെയ്ത പൊതികളും ആ ശേഖരത്തിലുണ്ടെങ്കില് ഡെബിയന് പൊതികള്ക്കു്
വേണ്ടി വരികള് മാറ്റുന്ന സന്ദര്ഭത്തില് അനുയോജ്യമായ മാറ്റങ്ങള് ഇവയ്ക്കു്
കൂടി നടത്തണം.
ചില ഉപയോക്താക്കള് അനൌദ്യോഗികമായി ബാക്ക്പോര്ട്ട് ചെയ്ത ഡെബിയനില് ഉള്ള പൊതികളുടെ “പുതിയ” പതിപ്പുകള് etch ല് തന്നെ ഇന്സ്റ്റോള് ചെയ്തിട്ടുണ്ടാകാം. അങ്ങനെയുള്ള പൊതികള് നവീകരണത്തിനിടയില് ഫയലുകള് കൂട്ടിമുട്ടി പ്രശ്നമുണ്ടാക്കാന് സാധ്യതയുണ്ടു്[3]. കൂട്ടിമുട്ടലുകള് ഉണ്ടാകുകയാണെങ്കില് അവയെ എങ്ങനെ നേരിടാം എന്നു് Section 4.5.8, “നവീകരിക്കുമ്പോള് ഉണ്ടാകാന് സാധ്യതയുള്ള പ്രശ്നങ്ങള്” ല് ചില വിവരങ്ങളുണ്ടു്.
സ്റ്റേബിള് ശേഖരത്തിനു് വേണ്ടി “ടെസ്റ്റിങ്ങ്” ശേഖരത്തില്
നിന്നും വിണ്ടും നിര്മ്മിച്ച പുതിയ പൊതികള് നല്കുന്ന Debian GNU/Linux രചയിതാക്കള്
നല്കുന്ന പാതി-ഔദ്യോഗികമായ ശേഖരമാണു് backports.org
.
“testing”ല്നിന്നുള്ള ചുരുക്കിയ വെര്ഷന് നമ്പറുകളോടുകൂടിയ
പൊതികളാണ് backports.org
ശേഖരത്തില് പ്രധാനമായും ഉള്ളത്;
അതുകൊണ്ട് etchbackports ല് നിന്ന് lennyലേക്കുള്ള
പുതുക്കല് മാര്ഗ്ഗം ഇപ്പോഴും സജീവമാണ്. എങ്ങനെയായാലും അസ്ഥിരമായ
സുരക്ഷാപുതുക്കലുകള്, പിന്നെ ഒഴിവാക്കാവുന്ന താഴെപ്പറയുന്നവ എന്നിവയില്നിന്ന്
സൃഷ്ടിക്കപ്പെട്ട ചില ചില്ലറ backports ഉണ്ട്: ഫയര്ഫോക്സ്, ലീനക്സ്
കേര്ണല്, ഓപ്പണ്ഓഫീസ്.ഓര്ഗ്, പിന്നെ എക്സ്.ഓര്ഗ്ഗും.
If you do not use one of these exceptions, you can safely upgrade to
lenny. If you use one of these exceptions, set the
Pin-Priority
(see apt_preferences(5)) temporarily to 1001
for all packages
from lenny, and you should be able to do a safe dist-upgrade too.
ആശ്രിതത്വം കാരണം ഉള്ളിലേക്ക് വലിച്ചെടുത്ത ചില പൊതികള് aptitude നീക്കം ചെയ്യാതിരിക്കണമെങ്കില് അവ കൈയോടെ autoപൊതികളെന്ന് ചിഹ്നപ്പെടുത്തേണ്ടിയിരിക്കുന്നു. പണിയിട പ്രതിഷ്ഠാനത്തിലെ വിം ഓപ്പണ് ഓഫീസ് ഇവ അതില് പെടുന്നു.
# aptitude unmarkauto openoffice.org vim
നിങ്ങളൊരു കെര്ണല് മെറ്റാപാക്കേജുപയോഗിച്ചിട്ടുണ്ടെങ്കില് 2.6 കെര്ണല് ഇമേജുകളും:
# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6.*' | cut -f1)
![]() | Note |
---|---|
aptitude ല് auto എന്നടയാളപ്പെടുത്തിയിരിയ്ക്കുന്നതേതെല്ലാമെന്നു് താഴെ പറയുന്ന പോലെ പ്രവര്ത്തിപ്പിച്ചാലറിയാം: # aptitude search '~i~M |
നവീകരണം തുടങ്ങുന്നതിനു് മുമ്പു് നിങ്ങള് പൊതികളുടെ പട്ടികയ്ക്കായുള്ള
apt
ന്റെ ക്രമീകരണ ഫയലായ
/etc/apt/sources.list
സജ്ജീകരിച്ചിരിയ്ക്കണം.
apt
ഏതു്
“deb
” വരിയുപയോഗിച്ചും കാണാവുന്ന എല്ലാ
പൊതികളേയും കണക്കിലെടുക്കുകയും, ഫയലിലെ ആദ്യത്തെ വരിയ്ക്കു് മുന്ഗണന കൊടുത്തു്
(അതുകൊണ്ടു് തന്നെ ഒന്നിലധികം മിററുകളുടെ സ്ഥാനമുണ്ടെങ്കില് സാധാരണയായി
നിങ്ങള് ഒരു പ്രാദേശിക ഹാര്ഡ് ഡിസ്ക് ആദ്യവും, അതിനു ശേഷം
സിഡി-റോമുകളും, പിന്നെ എച്ച്ടിടിപി/എഫ്ടിപി മിററുകളും
കൊടുക്കും), ഏറ്റവും ഉയര്ന്ന പതിപ്പിന്റെ സംഖ്യയുള്ള പൊതി തെരഞ്ഞെടുക്കുകയും
ചെയ്യും.
![]() | Tip |
---|---|
ഡിവിഡികള്ക്കും സിഡിറോംകള്ക്കുമുള്ള
വ്യത്യസ്ഥതകള് പരിശോധിച്ച് ജിപിജിക്കുള്ള ഒരു
ചുരുക്കപ്പേര്
ചേര്ക്കണ്ടതാണ്. APT::Authentication::TrustCDROM "true"; എന്നാലും, ഇതു് ഡിവിഡി/സിഡി-റോം ഇമേജ് ഫയലുകള്ക്കു് ബാധകമല്ല. |
ഓരോ പ്രകാശനവും പലപ്പോഴും രണ്ടു വിധത്തില് പരാമര്ശിക്കപ്പെടാറുണ്ട്. ഒന്ന്,
അതിന്റെ രഹസ്യപ്പേര് ഉപയോഗിച്ചും (ഉദാ:etch
,
lenny
)രണ്ട്: അതിന്റെ പദവി അനുസരിച്ചും (ഉദാ:
(i.e. oldstable
, stable
,
testing
,
unstable
). രഹസ്യനാമത്തിനാല് പരാമര്ശിക്കപ്പെടുമ്പോള്
ഒരു പുതിയ പ്രകാശനം നിങ്ങളെ ഒരിക്കലും അത്ഭുതപ്പെടുത്തില്ല എന്ന
മെച്ചമുണ്ട്. ഇക്കാരണത്താലാണ് ഇങ്ങനെ ഒരു നിലപാടെടുത്തത്. അതിന്റെ പ്രകാശന
പ്രഖ്യാപനത്തിനായി നിങ്ങള് സ്വയം ശ്രദ്ധിച്ചിരിക്കണമെന്ന് അതിന് ഒരിക്കലും
അര്ത്ഥമില്ല. പകരം പദവിയുടെ പേരാണ് ഉപയോഗിക്കുന്നതെങ്കില് പ്രകാശനം നടന്ന
ഉടനെത്തന്നെ പുതുക്കാനായി വണ്ടിക്കണക്കിന് പൊതികളുടെ ലഭ്യത കണ്ടെത്താനാവും.
സഹജമായ ക്രമീകരണത്തില് ഡെബിയന്റെ പ്രധാന ഇന്റര്നെറ്റ് സെര്വറുകളില് നിന്നും
ഇന്സ്റ്റോള് ചെയ്യാനാണു് സജ്ജീകരിച്ചിരിയ്ക്കുന്നതു്, പക്ഷേ
/etc/apt/sources.list
തിരുത്തി ശൃംഖലയില് നിങ്ങളുടെ
അടുത്തുള്ളൊരു മിറര് ഉപയോഗിയ്ക്കാന് നിങ്ങള് ആഗ്രഹിച്ചേയേക്കാം.
ഡെബിയനിലെ എച്ച്ടിടിപി അല്ലെങ്കില് എഫ്ടിപി മിറര് അഡ്രസ്സുകള് http://www.debian.org/distrib/ftplist ല് കാണാം (“list of Debian mirrors” എന്ന വിഭാഗത്തില് നോക്കുക). എച്ച്ടിടിപി മിററുകള് സാധാരണയായി എഫ്ടിപി മിററുകളേക്കാള് വേഗത കൂടിയതാണു്.
നിങ്ങളുടെ ഏറ്റവും അടുത്തുള്ള ഡെബിയന് മിറര്
http://mirrors.kernel.org
ആണെന്നിരിയ്ക്കട്ടെ. ഒരു ബൌസറോ
എഫ്ടിപി പ്രോഗ്രാമോ ഉപയോഗിച്ചു് ആ മിറര് പരിശോധിയ്ക്കുമ്പോള് പ്രധാന
തട്ടുകള് ഇങ്ങനെ ക്രമീകരിച്ചതായി നിങ്ങള്ക്കു് കാണാം:
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
”
വരികള് ഹാഷ് ചിഹ്നം (#
) മുന്നില് ചേര്ത്തു്
പ്രവര്ത്തനരഹിതമാക്കുക.
എച്ച്ടിടിപി അല്ലെങ്കില് എഫ്ടിപി പൊതികളുടെ മിററുകള്ക്കു് പകരം ഒരു
പ്രാദേശിക ഡിസ്കിലെ മിറര് ഉപയോഗിയ്ക്കാനായി (ഒരു പക്ഷേ
എന്എഫ്എസ് വഴി ചേര്ത്തതു്)
/etc/apt/sources.list
മാറ്റം വരുത്താന്
നിങ്ങളാഗ്രഹിയ്ക്കുന്നുണ്ടാവാം.
ഉദാഹരണത്തിനു് നിങ്ങളുടെ പൊതികളുടെ മിറര്
/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
”
വരികള് ഹാഷ് ചിഹ്നം (#
) മുന്നില് ചേര്ത്തു്
പ്രവര്ത്തനരഹിതമാക്കുക.
നിങ്ങള് സിഡികള് മാത്രം
ഉപയോഗിയ്ക്കാനാഗ്രഹിയ്ക്കുന്നെങ്കില്
/etc/apt/sources.list
നിലവിലുള്ള
“deb
” വരികള് ഒരു ഹാഷ് ചിഹ്നം
(#
) മുന്നില് ചേര്ത്ത് അഭിപ്രായമാക്കുക.
/etc/fstab
ല് നിങ്ങളുടെ സിഡി-റോം ചേര്ക്കാനായി
/cdrom
എന്ന സ്ഥാനത്തിനുള്ള (/cdrom
എന്നു് തന്നെ ആയിരിയ്ക്കണമെന്നു് apt-cdrom നു്
നിര്ബന്ധമുണ്ടു്) ഒരു ചാര്ത്തുണ്ടെന്നു് ഉറപ്പാക്കുക. ഉദാഹരണത്തിനു്
/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 GNU/Linux പതിപ്പില് നിന്നും കയറാന് ശുപാര്ശ ചെയ്തിരിയ്ക്കുന്നതു് പൊതികളെ കൈകാര്യം ചെയ്യുന്നതിനുള്ള ഉപകരണമായ aptitude ഉപയോഗിയ്ക്കാനാണു്. ഇതു് apt-get നേരിട്ടു് പ്രവര്ത്തിപ്പിയ്ക്കുന്നതിനേക്കാള് സുരക്ഷിതമായി പൊതികളുടെ ഇന്സ്റ്റലേഷനെക്കുറിച്ചുള്ള തീരുമാനങ്ങള് എടുക്കും.
ആവശ്യമായ എല്ലാ ഡിസ്ക് ഭാഗങ്ങളും (റൂട്ട്, /usr
എന്നീ
ഡിസ്ക്ക് ഭാഗങ്ങള് പ്രത്യേകിച്ചു്) എഴുതാനും വായിയ്ക്കാനും പറ്റുന്ന തരത്തില്
താഴെ പറയുന്ന പൊലൊരു ആജ്ഞ ഉപയോഗിച്ചു് ചേര്ക്കാന് മറക്കരുതു്:
# mount -o remount,rw /mountpoint
അടുത്തതായി നിങ്ങള് (/etc/apt/sources.list
ലെ) ആപ്റ്റ്
ഉറവിട ചാര്ത്തുകള് “lenny
”
അല്ലെങ്കില് “stable
” എന്നാണു്
സൂചിപ്പിയ്ക്കുന്നതെന്നു് ഒന്നുകൂടി ഉറപ്പാക്കുക. etch നെ
സൂചിപ്പിയ്ക്കുന്ന ഒരു വരികളും ഉണ്ടാകരുതു്.
![]() | Note |
---|---|
സിഡി-റോമിനുള്ള വരികള് പലപ്പോഴും “ |
/usr/bin/script എന്ന ആജ്ഞ ഉപയോഗിച്ചു് നിങ്ങളുടെ നവീകരണ പ്രവര്ത്തനവേളയുടെ ഒരു ട്രാന്സ്ക്രിപ്റ്റ് സൂക്ഷിച്ചു് വയ്ക്കണമെന്നു് ശക്തമായി ശുപാര്ശ ചെയ്യുന്നു. ഇങ്ങനെ ചെയ്താല് എന്തെങ്കിലും പ്രശ്നം സംഭവിയ്ക്കുന്ന സന്ദര്ഭത്തില് നിങ്ങള്ക്കു് എന്താണു് സംഭവിച്ചതെന്നതിന്റെ ഒരു നാള്വഴി കയ്യിലുണ്ടാവുകയും, ആവശ്യം വന്നാല്, പിഴവറിയിയ്ക്കുമ്പോള് നല്കുകയും ചെയ്യാം. പിടിച്ചു് വയ്ക്കാന്, താഴെ പറയുമ്പോലെ അടിച്ചു് വയ്ക്കുക:
# script -t 2>~/upgrade-lenny.time -a ~/upgrade-lenny.script
ടൈപ്പ്സ്ക്രിപ്റ്റ് ഫയല് /tmp
അല്ലെങ്കില്
/var/tmp
പോലൊരു താത്കാലിക തട്ടില് വയ്ക്കരുതു് (ഈ
തട്ടില് വച്ച ഫയലുകള് നവീകരണത്തിനിടയിലോ വീണ്ടും തുടങ്ങുന്നതിനിടയിലോ നീക്കം
ചെയ്യാന് സാധ്യതയുണ്ടു്).
യവനികയില് നിന്ന് മാറിക്കഴിഞ്ഞാലും വിവരങ്ങളുടെ പുന:പരിശോധനക്ക് അച്ചടി
അക്ഷരങ്ങള് (typescript) നിങ്ങളെ അനുവദിക്കുന്നു. Alt+F2 ഉപയോഗിച്ച്
VT2വിലേക്കിടുകയേ വേണ്ടൂ, എന്നിട്ട് അകത്തുകടന്ന് less -R
~root/upgrade-lenny.script
ഉപയോഗിച്ച് ഫയല് വീക്ഷിക്കാം.
നവീകരണം പൂര്ത്തിയാക്കിയ ശേഷം exit
എന്നു് പ്രോംറ്റില്
അടിച്ചു് script നിര്ത്താം.
scriptന് വേണ്ടി -tസ്വിച്ച് ഉപയോഗിച്ചിട്ടുണ്ടെങ്കില് scriptreplay പരിപാടി ഉപയോഗിച്ച് ആ മണ്ഡലം(session) മുഴുവന് പുനര്പ്രവര്ത്തനം നടത്താം.
# scriptreplay ~/upgrade-lenny.time ~/upgrade-lenny.script
ആദ്യം പുതിയ പതിപ്പിനു് ലഭ്യമായ എടുക്കേണ്ട പൊതികള് കാണുക. താഴെ പറയുന്നതു് പ്രവര്ത്തിപ്പിച്ചു് ഇതു് ചെയ്യാം:
# aptitude update
പുതിയ ഉറവിടങ്ങള് ചേര്ത്തതിനു് ശേഷം ആദ്യമായി ഇതു് പ്രവര്ത്തിപ്പിയ്ക്കുമ്പോള് ഉറവിടങ്ങളുടെ ലഭ്യതയെക്കുറിച്ചു് മുന്നറിയിപ്പുകള് എഴുതിക്കാണിച്ചേയ്ക്കാം. ഈ മുന്നറിയിപ്പുകള് പ്രശ്നമില്ലാത്തതും വീണ്ടും ഈ ആജ്ഞകള് പ്രവര്ത്തിപ്പിച്ചാല് വരാത്തതുമാണു്.
Section 4.5.7, “ബാക്കിയുള്ള സിസ്റ്റം നവീകരിയ്ക്കുന്നതു്”.ല് വിവരിച്ച പോലെ മുഴുവന് വ്യവസ്ഥിതിയും പുതുക്കാന് തുടങ്ങുമ്പോള് നിങ്ങളുടെ ഹാര്ഡ് ഡിസ്കില് മതിയായ സ്ഥലമുണ്ടെന്ന് മുന്കൂട്ടി ഉറപ്പ് വരുത്തിയിരിക്കണം.
aptitude ഉം apt
ഇന്സ്റ്റലേഷനു് വേണ്ട ഡിസ്ക്ക് സ്ഥലത്തെപ്പറ്റി വിശദമായ വിവരം നിങ്ങളെ
കാണിയ്ക്കും. നവീകരണം തുടങ്ങുന്നതിനു് മുമ്പു് ഇതു് കാണാന് നിങ്ങള് താഴെ
പറയുന്നതു് പ്രവര്ത്തിപ്പിയ്ക്കാം:
# aptitude -y -s -f --with-recommends dist-upgrade [ ... ] XXX upgraded, XXX newly installed, XXX to remove and XXX not upgraded. Need to get xx.xMB/yyyMB of archives. After unpacking AAAMB will be used. Would download/install/remove packages.
![]() | 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 “visual mode” ല്
തുറന്നു് “Obsolete and Locally Created Packages” എന്ന
വിഭാഗത്തില് പഴയ പ്രാധാന്യം കഴിഞ്ഞുപോയ പൊതികളെ കാണാം.
കൂടുതല് സ്ഥലമെടുക്കുന്നതു് നിങ്ങള്ക്കിപ്പോള് ആവശ്യമില്ലാത്തതുമായ പൊതികള്
നീക്കം ചെയ്യുക (നവീകരണത്തിനു് ശേഷം നിങ്ങള്ക്കവ വീണ്ടും ഇന്സ്റ്റോള്
ചെയ്യാം). ഏറ്റവും കൂടുതല് ഡിസ്ക്ക് സ്ഥലം ഉപയോഗിയ്ക്കുന്ന പൊതികളെ കാണാന്
നിങ്ങള്ക്കു് (debian-goodies
എന്ന
പൊതിയിലുള്ള) dpigs അല്ലെങ്കില് wajig
ഉപയോഗിയ്ക്കാം (wajig size
പ്രവര്ത്തിപ്പിച്ചു്).
You can list packages that take up most of the disk space with aptitude
. Start aptitude
into “visual mode”, select
→ (this menu entry is available only after
etch version), press l and enter ~i
,
press S and enter ~installsize
, then it
will give you nice list to work with. Doing this after upgrading
aptitude
should give you access to
this new feature.
ആവശ്യമില്ലാത്ത പരിഭാഷകളും പ്രാദേശികവത്കരണ ഫയലുകളും നീക്കം
ചെയ്യുക. localepurge
എന്ന പൊതി
ഇന്സ്റ്റോള് ചെയ്തു് തെരഞ്ഞെടുത്ത ലൊക്കേലുകള് മാത്രമേ സിസ്റ്റത്തില്
സൂക്ഷിയ്ക്കുന്നുള്ളൂ എന്നു് ക്രമീകരിയ്ക്കുക. ഇതു്
/usr/share/locale
ല് എടുക്കുന്ന ഡിസ്ക്ക് സ്ഥലം
കുറയ്ക്കും.
/var/log/
ലെ നാള്വഴികള് തത്കാലം മറ്റൊരു
സിസ്റ്റത്തിലേയ്ക്കു് നീക്കുകയോ എന്നേയ്ക്കുമായി നീക്കം ചെയ്യുകയോ ചെയ്യാം.
താത്കാലികമായി ഒരു /var/cache/apt/archives
ഉപയോഗിയ്ക്കുക: താത്കാലികമായി സൂക്ഷിച്ചുവയ്ക്കുന്ന തട്ടു് മറ്റൊരു ഫയല്
സിസ്റ്റത്തില് നിന്നും എടുക്കാം (USB സൂക്ഷിപ്പു് ഉപകരണം,
താത്കാലിക ഹാര്ഡ് ഡിസ്ക്ക്, നേരത്തെ തന്നെ ഉപയോഗിയ്ക്കുന്ന ഫയല്
സിസ്റ്റം. ...)
![]() | Note |
---|---|
ശൃംഖലാ ബന്ധം നവീകരണത്തിനിടയില് തടസ്സപ്പെടാനിടയുള്ളതിനാല് എന്എഫ്എസ് വഴി ചേര്ത്തതുപയോഗിയ്ക്കരുതു്. |
ഉദാഹരണത്തിനു്, നിങ്ങളുടെ കയ്യില് /media/usbkey
ചേര്ത്ത ഒരു യുഎസ്ബി ഡ്രൈവുണ്ടെങ്കില്:
ഇന്സ്റ്റോള് ചെയ്യാനായി നേരത്തെ എടുത്തുവച്ച പൊതികള് നീക്കം ചെയ്യുക:
# apt-get clean
/var/cache/apt/archives
എന്ന തട്ടു്
യുഎസ്ബി ഡ്രൈവിലേയ്ക്കു് പകര്ത്തുക:
# 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
ന്റേയും വെര്ഷനുകള് എച്ചിലെ പൊതികളുടെ
lennyലേക്കുള്ള ചുവട് മാറ്റം കൈകാര്യംചെയ്യാന് അശക്തമാണെന്ന് പല
ശല്യപ്രസ്താവനകളും (bugreport) കാണിക്കുന്നുണ്ട്. lennyല്
apt
ഉടനടി ക്രമീകരണം ആവശ്യമുള്ള
പൊതികളുടെ നൂലാമാലകളുമായി ഇടപെടാന് ത്രാണിയുള്ളതും aptitude
ആശ്രിതത്വ പ്രശ്നങ്ങള് ഫലപ്രദമായി
പരിഹരിക്കാന്വേണ്ടി അന്വേഷണചാതുര്യമുള്ളതുമാണ്. ഈ രണ്ടു സവിശേഷതകളും
lennyലേക്കുള്ള അധിരോഹണ(upgrade) വ്യവസ്ഥയില് ശക്തമായി
ഉള്ക്കൊള്ളിച്ചിട്ടുണ്ട്. അതുകൊണ്ട് മറ്റുള്ള പൊതികളുടെ അധിരോഹണത്തിന് മുമ്പേ
ഈ രണ്ടു പൊതികളും അധിരോഹണം നടത്തേണ്ടതുണ്ട്. apt
നുവേണ്ടി പ്രവര്ത്തിപ്പിക്കുക:
# apt-get install apt
നിങ്ങള് aptitude
ഇന്സ്റ്റോള്
ചെയ്തിട്ടുണ്ടെങ്കില് താഴെ പറയും പോലെ പ്രവര്ത്തിപ്പിയ്ക്കുക:
# aptitude install aptitude
ഈ ചുവട് വെപ്പില് libc6
ഉം
locales
ഉം സ്വയം പുതുക്കപ്പെടുകയും
SELinux പിന്തുണക്കുള്ള ഗ്രന്ഥാവലികള് ഉള്ളിലേക്ക് വലിച്ചെടുക്കപ്പെടുകയും
ചെയ്യും. ഈ സമയത്ത് ഓടിക്കൊണ്ടിരിക്കുന്ന xdm,
gdm and kdm മുതലായ ചില സേവനങ്ങള്
പുനരാരംഭിക്കും. തദ്ഫലമായി X11ഘട്ടം
വിച്ഛേദിക്കപ്പെടും.
aptitude
യാന്ത്രികമായി
ഇന്സ്റ്റോള്ചെയ്ത (ഉദാഹരണത്തിനു് മറ്റൊരു പൊതിയുടെ ആശ്രയത്വമായി) പൊതികളുടെ
പട്ടിക സൂക്ഷിയ്ക്കുന്നുണ്ടു്. lenny യില് apt
നും ഈ കഴിവുണ്ടു്.
ആദ്യമായി aptitude
ലെ lenny
വെര്ഷന് ഓടിച്ചാല്, അത് പ്രതിഷ്ഠാപനം നടത്തിയ എല്ലാ പൊതികളും യാന്ത്രികമായി
വായിച്ചെടുത്ത് apt
ന്റെ
lenny വെര്ഷനന് ഉപയോഗിക്കത്തക്കവിധം മാറ്റിയെടുക്കും. 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
, and xserver-common
എന്നിവ
ഉള്പ്പെടുന്നു. lennyല് കാലഹരണപ്പെട്ട പൊതികളുടെ കൂടുതല്
വിവരങ്ങള്ക്ക് Section 4.10, “കാലഹരണപ്പെട്ട പൊതികള്”കാണുക.
നിങ്ങളിപ്പോള് നവീകരണത്തിന്റെ പ്രധാന ഭാഗവുമായി തുടരാന് തയ്യാറാണു്. പ്രവര്ത്തിപ്പിയ്ക്കേണ്ടതു്:
# aptitude dist-upgrade
വ്യവസ്ഥിതിയുടെ മുഴുവന് പുതുക്കലും ഇത് നടത്തിക്കൊള്ളും. അതായത്, ലഭ്യമായ എല്ലാ പൊതികളുടേയും ഏറ്റവും പുതിയ പതിപ്പുകള് പ്രതിഷ്ഠിക്കുകയും, വ്യത്യസ്ത പ്രകാശനങ്ങളിലെ പൊതികള് തമ്മില് വരാവുന്ന ആശ്രിതത്വ പ്രശ്നങ്ങള് പരിഹരിക്കുകയും ചെയ്യും. വേണ്ടിവന്നാല്, പുതിയ ചില പൊതികള് (സാധാരണയായി ഗ്രന്ഥാവലിയുടെ പുതിയ പതിപ്പുകളോ പുനര്നാമകരണം ചെയ്യപ്പെട്ട പൊതികളോ) കൂടി സ്ഥാപിക്കുകയും, വൈരുദ്ധ്യമുള്ള കാലഹരണപ്പെട്ട പൊതികള് നീക്കിക്കളയുകയും ചെയ്യും.
ഒരു കൂട്ടം സിഡിറോമുകള് (ഡിവിഡികള്) ഉപയോഗിച്ച് പുതുക്കല് നടത്തുമ്പോള് ഒരു പ്രത്യേക സിഡിതന്നെ പുതുക്കലിനിടയ്ക്കുള്ള വിവിധ ഘട്ടങ്ങളില് ഇടാനാവശ്യപ്പെട്ടെന്നു വരും.ഒരേ സിഡി തന്നെ പലതവണ ഇടേണ്ടതായി വരും. സിഡിയില് പലയിടത്തായി ചിതറിക്കിടക്കുന്ന പരസ്പര ബന്ധമുള്ള പൊതികളാണതിന് കാരണം.
മറ്റു പൊതികളുടെ പ്രതിഷ്ഠാപന നിലവാരം മാറാതെ പുതുക്കാന് കഴിയാത്തതും
നിലവിലുള്ളതുമായ പൊതികളുടെ പുതിയ വെര്ഷനുകള് മാറ്റങ്ങള് വരുത്താതെ അതേപടി
തുടരാന് വിടും (“held back”എന്ന് പ്രദര്ശിപ്പിച്ചുകൊണ്ട്). ഈ
പൊതികള് പ്രതിഷ്ഠാപനത്തിന് തെരഞ്ഞെടുക്കാന് aptitude
ഉപയോഗിച്ചുകൊണ്ടോ അല്ലെങ്കില് aptitude -f install
.പ്രയോഗിച്ചോ ഇതു
പരിഹരിക്കാവുന്നതാണ്.
package
ഒരു aptitude, apt-get, അല്ലെങ്കില് dpkg നടപടി താഴെ പറയുന്നൊരു പിശകോടെ പരാജയപ്പെടുകയാണെങ്കില്
E: Dynamic MMap ran out of room
സഹജമായ സൂക്ഷിപ്പ്സ്ഥലം വേണ്ടത്ര ഇല്ല. സൂക്ഷിപ്പ് സ്ഥലത്തിന്റെ വ്യാപ്തി
വര്ദ്ധിപ്പിച്ചോ /etc/apt/sources.list
ലെ നിങ്ങള്ക്ക്
അവശ്യമില്ലാത്ത വരികളില് അഭിപ്രായപ്രകടനം നടത്തിയോ നീക്കംചെയ്തോ ഇത്
പരിഹരിക്കാവുന്നതേ ഉള്ളൂ. തഴെകൊടുത്ത ആജ്ഞ പുതുക്കല് നടപടികള്ക്കാവശ്യമായ
ഒരു മൂല്യം നല്കിക്കൊള്ളും.
# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf
ആ ഫയലില് ഈ ചരം നിങ്ങള് സജ്ജീകരിച്ചിട്ടില്ലെന്നിതു് ഊഹിയ്ക്കുന്നു.
സംഘട്ടനാത്മകത്വം/മുന്-ആശ്രിതത്വ ലൂപ്പ് കാരണം ചില അത്യാവശ്യമായ പൊതികള്
താല്ക്കാലികമായി നീക്കം ചെയ്യാന് കഴിവുറ്റതാക്കാന് ചില സന്ദര്ഭങ്ങളില്
APT::Force-LoopBreak
ഐച്ഛികം
സജീവമാക്കേണ്ടിവരും. aptitude ഇതിനെപ്പറ്റി നിങ്ങളെ
ജാഗ്രതയുള്ളവരാക്കുകയും പുതുക്കല് നടപടി ഉപേക്ഷിക്കുകയും ചെയ്യും.
ഒരു വ്യവസ്ഥിതിയിലെ ആശ്രിതത്വഘടന മാനുഷികമായ ഇടപെടല് അനിവാര്യമാക്കുന്ന വിധത്തില് കെട്ടുപോയ സന്ദര്ഭങ്ങളുണ്ടാവാം.സാധാഅണ ഇതുകൊണ്ട് അര്ത്ഥമാക്കേണ്ടത് aptitudeന്റെ ഉപയോഗം അല്ലെങ്കില്
# dpkg --remove package_name
വഴി ചില പ്രശ്നക്കാരായ പൊതികളെ നീക്കം ചെയ്യാം, അല്ലെങ്കില്
# aptitude -f install # dpkg --configure --pending
വിരളമായ സന്ദര്ഭങ്ങളില് നിങ്ങള്ക്കു് താഴെ പറയു പോലൊരു ആജ്ഞ ഉപയോഗിച്ചു് വീണ്ടും ഇന്സ്റ്റോള് ചെയ്യാന് നിര്ബന്ധിയ്ക്കേണ്ടി വന്നേയ്ക്കാം
# dpkg --install /path/to/package_name.deb
“pure” etchല് നിന്ന് പുതുക്കല് നടത്തുമ്പോള് ഫയലുകളുടെ സംഘട്ടനം ഉണ്ടാവാന് പാടില്ല; എന്നാല് അനൌദ്യോഗിക പരിപാടികള് പ്രതിഷ്ഠിച്ചിട്ടുണ്ടെങ്കില് ഇങ്ങനെ സംഭവിക്കാം. ഒരു ഫയല് സംഘട്ടനം ഇതുപോലൊരു പിശകിന് കാരണമായേക്കും:
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>
പിശക് കാണിക്കുന്ന സന്ദേശത്തിന്റെ last വരിയില് പരാമര്ശിച്ച പൊതി നിര്ബ്ബന്ധമായി നീക്കം ചെയ്തുകൊണ്ട് ഫയല് സംഘട്ടനം നിങ്ങള്ക്ക് ഒഴിവാക്കാം:
# dpkg -r --force-depends package_name
ഇത്തരത്തില് കാര്യങ്ങള് ശരിയാക്കിയ ശേഷം മുമ്പ് വിശദീകരിച്ച aptitude ആജ്ഞ ആവര്ത്തിച്ചുകൊണ്ട് പുതുക്കല് നടപടി പുനരാരംഭിക്കാന് കഴിയണം.
പുതുക്കല് നടന്നുകൊണ്ടിരിക്കേ, പല പൊതികളുടേയും ക്രമീകരണങ്ങളേയും
പുന:ക്രമീകരണങ്ങളേയും കുറിച്ച് നിങ്ങളോട് ചോദ്യങ്ങള് ഉണ്ടായേക്കാം. ഇങ്ങനെ
/etc/init.d
ലേയോ,
/etc/terminfo
തട്ടുകളിലേയോ അല്ലെങ്കില്
/etc/manpath.config
ലേയോ ഏതെങ്കിലും ഫയല് പൊതിപരിപാലന
വെര്ഷന് കൊണ്ട് പുനസ്ഥാപിക്കണോ എന്ന ചോദ്യം വരുമ്പോള് സാധാരണയായി
വ്യവസ്ഥിതിയുടെ കെട്ടുറപ്പിന് 'വേണം' എന്ന ഉത്തരം നല്കണം. നിങ്ങള്ക്കെപ്പോഴും
പഴയ പതിപ്പിലേക്ക് മടങ്ങിപ്പോകാന് കഴിയും, കാരണം .dpkg-old
അനുബന്ധത്തില് അവ സൂക്ഷിക്കപ്പെട്ടിട്ടുണ്ട്.
എന്താണ് ചെയ്യേണ്ടതെന്ന് കൃത്യമായി നിങ്ങള്ക്ക് അറിയില്ലെങ്കില്, പൊതികളുടേയോ, ഫയലുകളുടേയോ പേര് കുറിച്ചെടുത്ത് പിന്നീടൊരിക്കല് ശരിയാക്കാം. പുതുക്കിക്കൊണ്ടിരിക്കുമ്പോള് യവനികയില് തെളിഞ്ഞിരുന്ന വിവരങ്ങള് typescript ഫയലില് നിന്ന് തെരഞ്ഞെടുക്കാവുന്നതാണ്.
ഈ വിഭാഗം കെര്ണല് നവീകരിക്കുന്നതിനെ കുറിച്ചും അതുമായി ബന്ധപ്പെട്ട
സുപ്രധാനമായ പ്രശ്നങ്ങളും വിവരിക്കുന്നു. ഡെബിയന് നല്കുന്ന linux-image-*
പൊതികളില് ഒരെണ്ണം
സ്ഥാപിക്കുകയോ,അല്ലെങ്കില് ഉറവിടത്തില് നിന്നും കമ്പൈല് ചെയ്തു സ്വന്തമായി
ഒരു കെര്ണല് ഉണ്ടാക്കുകയെ ചെയ്യാം.
ഈ വകുപ്പിലെ ഒട്ടനവധി വിവരങ്ങളും ഉള്പ്പെടുത്തിയിട്ടുള്ളത് നിങ്ങള്
initramfs-tools
ന്റേയും udev
ന്റേയും കൂടെ വിഘടിത ഡെബിയന് കേര്ണലാണ്
ഉപയോഗിക്കുന്നത് എന്ന നിഗമനം അടിസ്ഥാനമാക്കിയാണ്. initrd ആവശ്യമില്ലാത്ത
നിങ്ങള്ക്കിഷ്ടപ്പെട്ട വേറൊരു കേര്ണലാണ് നിങ്ങള് തെരഞ്ഞെടുക്കുന്നതെങ്കില്,
വ്യത്യസ്തമായൊരു initrd ഉത്പാദകമാണ് ഉപയോഗിക്കുന്നതെങ്കില് ഇതിലെ ചില
വിവരങ്ങള് നിങ്ങള്ക്ക് സംഗതമായിരിക്കില്ല.
etchല്നിന്ന് lennyലേക്ക് നവീകരണം നടത്തുമ്പോള്, ലീനക്സ്-ഇമേജ്-2.6-*മെറ്റാപാക്കേജ് പ്രതിഷ്ഠിക്കാന് ശക്തമായി ശുപാര്ശ ചെയ്യുന്നു. പുതുക്കലിനിടെ ഈ പൊതി യാന്ത്രികമായിത്തന്നെ പ്രതിഷ്ഠിക്കപ്പെടും. ഇത് പ്രവര്ത്തിപ്പിച്ചുകൊണ്ട് നിങ്ങള്ക്കത് മനസ്സിലാക്കാവുന്നതാണ്.
# dpkg -l "linux-image*" | grep ^ii
ഫലപ്രാപ്തി ഒന്നും കാണുന്നില്ലെങ്കില്, നിങ്ങള്ക്ക് ഒരു പുതിയ ലീനക്സ്- ഇമേജ് പൊതി കൈയോടെ പ്രതിഷ്ഠിക്കേണ്ടതായിവരും. നിലവില് ലഭ്യമായ ലീനക്സ്-ഇമേജ്-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 ല് ഇഷ്ടപ്പെട്ട കേര്ണല് സമാഹരിക്കാന് (compile) സാഹസികരായവര്ക്ക്
വേറൊരു എളുപ്പവഴിയുണ്ട്. kernel-package
ആയുധം പ്രതിഷ്ഠിച്ച്
/usr/share/doc/kernel-package
ലുള്ള വിവരണം നോക്കുക.
താല്ക്കാലികമായി ബൂട്ട് ചെയ്യാത്ത ഒരവസ്ഥ വരാതിരിക്കാന്, കഴിയുമെങ്കില്
പ്രധാനപ്പെട്ട dist-upgrade
നവീകരണത്തില്നിന്ന് ഭിന്നമായി
കേര്ണല് പൊതി ഒറ്റക്ക് നവീകരിക്കുന്നതാണ് നിങ്ങളുടെ നന്മക്ക് നല്ലത്. Section 4.5.6, “ചുരുങ്ങിയ സിസ്റ്റത്തിന്റെ നവീകരണം”ല് വിവരിച്ച കുറഞ്ഞ നവീകരണപ്രക്രിയക്ക് ശേഷം
മാത്രമേ ചെയ്യാവൂ എന്ന് ശ്രദ്ധിച്ചിരിക്കണം.
മുന്പതിപ്പുകളെ അപേക്ഷിച്ച് ഖരസാമാഗ്രികള് കണ്ടെത്തുന്നതിന് lenny കൂടുതല് കരുത്തുള്ള പ്രകടനമാണ് കാഴ്ചവെക്കുന്നത്. എന്നിരുന്നാലും, ഉപകരണങ്ങള്ക്ക് പേരുകള് നല്കുന്ന ക്രമത്തെ ബാധിക്കുന്ന മട്ടില് നിങ്ങളുടെ വ്യവസ്ഥിതിയില് ഉപകരണനാമങ്ങള് കണ്ടെത്തുന്ന മുറയ്ക്ക് മാറ്റം വരാന് കാരണമാകുന്നുണ്ട്. ഉദാഹാണത്തിന്, നിങ്ങള്ക്ക് രണ്ട് വ്യത്യസ്ഥ സാരഥി (drivers) കളുമായി ബന്ധപ്പെട്ട രണ്ട് ശൃംഖലാ കര്മ്മ അഡാപ്റ്ററുകളുണ്ടെന്ന് കരുതുക, eth0 എന്നും eth1എന്നും സൂചിപ്പിക്കപ്പെട്ട അവ തമ്മില് പരസ്പരം മാറിപ്പോവാം. ഓടിക്കൊണ്ടിരിക്കുന്ന ഒരു വ്യവസ്ഥിതിയില് ഈതര്നെറ്റ് അഡാപ്റ്ററുകള് പരസ്പരം മാറ്റുകയാണെങ്കില് പുതിയ അഡാപ്റ്ററിന് ഒരു പുതിയ ഇടനിലനാമം(interface name) ലഭിക്കും എന്നുള്ളതാണ് പുതിയ ഘടനകൊണ്ട് ഉദ്ദേശിക്കുന്നത്.
ശൃംഖലാകര്മ്മ ഉപകരണങ്ങളെ സംബധിച്ചിടത്തോളം udev
നിയമങ്ങള് ഉപയോഗിച്ച് , കൂടുതല്
കൃത്യമായി പറഞ്ഞാല്,
/etc/udev/rules.d/70-persistent-net.rules
[4]. ലെ നിര്വ്വചനം വഴി ഇത്തരം പുന:ക്രമീകരണങ്ങള് ഒഴിവാക്കാം. ഭൌതിക
ഉപകരണങ്ങള് പ്രത്യേക പേരുകളുമായി ബൂട്ടിംഗ് സമയത്തുതന്നെ ബന്ധിക്കാന്
ifrenameചെറു പ്രയോഗം ഉപയോഗിക്കുന്നത് വേറൊരു
പോംവഴിയാണ്. കൂടുതല് വിവരങ്ങള്ക്ക് ifrename(8) and iftab(5) കാണുക. (udev
, ifrename) എന്നീ രണ്ട്
പോംവഴികളും ഒരേസമയം ഉപയോഗിക്കരുത്.
സൂക്ഷിപ്പ് ഉപകരണങ്ങളുടെ കാര്യത്തില് , initramfs-tools
ഉപയോഗിച്ച്, നിലവില് സൂക്ഷിപ്പ്
ഉപാധികളുടെ സാരഥീഘടകങ്ങള് (driver modules) കയറ്റിയ അതേ ക്രമത്തില് കയറ്റാന്
ക്രമീകരിച്ചാല് ഈ ക്രമീകരണമാറ്റങ്ങള് ഒഴിവാക്കാം. അതിനായി
lsmodന്റെ ഉത്പന്നം നോക്കി സൂക്ഷിപ്പ് ഉപാധികള് കയറ്റുന്ന
ക്രമം മനസ്സിലാക്കണം. lsmod പുറത്ത് വിടുന്ന പട്ടികയിലെ
ക്രമത്തിന് നേര്വിപരീത ക്രമത്തിലാണ് അവ കയറ്റിയിട്ടുണ്ടാവുക, അതായത്;
പട്ടികയിലെ ആദ്യത്തെ ഘടകം അവസാനമാണ് കയറ്റുക. കേര്ണല് സ്ഥിരസ്വഭാവത്തോടെ
കണക്കിടുന്ന (PCI ഉപകരണങ്ങളെപ്പോലെ) ഉപകരണങ്ങളുടെ കാര്യത്തില് മാത്രമെ ഇത്
പ്രാവര്ത്തികമാകൂ എന്ന് പ്രത്യേകം ശ്രദ്ധിക്കണം.
ഏതായാലും, ആദ്യത്തെ ബൂട്ടിങ്ങിന് ശേഷം ഘടകങ്ങള് നീക്കലും വീണ്ടും കയറ്റലും ഈ
ക്രമം മാറ്റിമറിക്കും. മാത്രമല്ല, നിങ്ങളുടെ കേര്ണലിന് സ്ഥിരമായി ബന്ധപ്പെട്ട
ചില സാരഥികളുണ്ടാവും, അവയുടെ പേരുകള് lsmodന്റെ
ഉത്പന്നത്തില് പ്രത്യക്ഷപ്പെടില്ല. ഈ സാരഥീനാമങ്ങള്
/var/log/kern.log
ല് നോക്കിയോ,
dmesgന്റെ ഉത്പന്നത്തില്നിന്നോ ഊഹിച്ചെടുത്ത് ക്രമത്തില്
കയറ്റാന് കഴിഞ്ഞേക്കും.
ബൂട്ടിങ്ങ് സമയത്ത് കയറ്റിവിടേണ്ട അതേ ക്രമത്തില് ഘടകങ്ങളുടെ പേരുകള്
/etc/initramfs-tools/modules
ല്
ചേര്ക്കുക. etch നും lennyനും ഇടക്ക് ചില ഘടകങ്ങളുടെ
പേരുകള്ക്ക് മാറ്റം വന്നിട്ടുണ്ടാവും;.ഉദാഹരണത്തിന്,
sym53c8xx_2
എന്നത് sym53c8xx
എന്നായി
മാറിയിട്ടുണ്ട്.
അതിനു ശേഷം update-initramfs -u -k
all
.പ്രവര്ത്തിപ്പിച്ചുകൊണ്ട് നിങ്ങളുടെ initramfs image(s)ന്റെ
പുന:സൃഷ്ടി നടത്തേണ്ടിവരും.
ഒരിക്കല് ഒരു lenny കേര്ണലും udev
വും ഓടിത്തുടങ്ങിയാല്, സാരഥിയെ കയറ്റുന്ന
ക്രമത്തിനെ ആശ്രയിക്കാത്ത ഉപനാമത്താല് ഡിസ്കിനെ സമീപിക്കാന് നിങ്ങളുടെ
വ്യവസ്ഥിതി പുന:ക്രമീകരിക്കേണ്ടതായിട്ടുണ്ട്. ഈ ഉപനാമങ്ങള്
/dev/disk/
പരമ്പരയിലാണ് കുടിപാര്ക്കുന്നത്.
വ്യവസ്ഥിതി ബൂട്ട് ചെയ്യാന് initramfs-tools
കൊണ്ട് സൃഷ്ടിച്ച initrd
ഉപയോഗിക്കുമ്പോള്, ചില സന്ദര്ഭങ്ങളില് udev
കൊണ്ടുള്ള ഉപകരണ ഫയലുകളുടെ നിര്മ്മാണത്തിന്
ബൂട്ടിന്റെ ചെറു ആജ്ഞ പ്രവര്ത്തനക്ഷമമാകുന്നത് അസാധാരണമായി
നീണ്ടുപോയെന്നുവരാം. .
അടിസ്ഥാന ഫയലുകള് കയറ്റാന് കഴിയാതെ നിങ്ങളെ ഒരു ഡീബഗ്ഷെല്ലില് വിട്ടേച്ച്
പോകുന്ന കാരണം ബൂട്ടിംഗ് പരാജയമായിരിക്കും സാധാരണ ലക്ഷണം. പിന്നീടൊരിക്കല്
നിങ്ങളത് പരിശോധിച്ചാല് /dev
ല്
ആവശ്യമുണ്ടായിരിക്കേണ്ട ഫയലുകള് ഉള്ളതായികാണാം. അടിസ്ഥാന ഫയല് വ്യവസ്ഥ
USB ഡിസ്കിലോ RAIDലോ ആയിരിക്കുമ്പോഴോ,
അല്ലെങ്കില്
LILO
ഉപയോഗിക്കുമ്പോഴോ ആണ് ഇങ്ങനെ കണ്ടെത്തിയിട്ടുള്ളത്.
rootdelay=
എന്ന ബൂട്ട്
പരാമീറ്റര് ഉപയോഗിക്കുന്നതാണു ഈ പ്രശ്നത്തിന്റെ ഒരു പരിഹാരംഇടവേള സമയത്തിന്റെ
(സെക്കന്ഡ്) വില മാറ്റേണ്ടി വരും
9
aptitude dist-upgrade
തീര്ന്നാല്
“ഔപചാരികമായ” നവീകരണം പൂര്ത്തിയായിട്ടുണ്ടാവും എന്നാല് അടുത്ത
റീബൂട്ടിനു മുന്പ് ചെയ്യേണ്ടതായ മറ്റു ചില കാര്യങ്ങള് ഉണ്ടു്
നിങ്ങളുടെ ബൂട്ട് ലോഡറായി lilo
ആണ്
ഉപയോഗിക്കുന്നതെങ്കില് (etchലെ ചില പ്രതിഷ്ഠാപനങ്ങള്ക്ക് ഇതാണ്
സഹജമായ ബൂട്ട്ലോഡറായി ഉപയോഗിക്കുന്നത്) നവീകരണത്തിനു ശേഷം
lilo വീണ്ടും ഓടിക്കാന് ശുപാര്ശ ചെയ്യുന്നു:
# /sbin/lilo
വ്യവസ്ഥിയുടെ കേര്ണല് പരിഷ്കരിക്കപ്പെട്ടിട്ടില്ലെങ്കിലും ഇത് അത്യാവശ്യമാണെന്ന് ഓര്മ്മിക്കണം, കാരണം പൊതികളുടെ പുതുക്കല് കാരണം liloയുടെ രണ്ടാംഘട്ടം മാറിയിരിക്കും.
/etc/kernel-img.conf
എന്ന ഫയലിന്റെ ഉള്ളടക്കം
പരിശോധിച്ച് do_bootloader = Yes
ഉണ്ടോ എന്നു
പരിശോധിക്കുക. ഇങ്ങനെ ഓരോ കെര്ണല് നവീകരണത്തിനു ശേഷം ബൂട്ട്ലോഡര് വീണ്ടും
പ്രവര്ത്തിപ്പിക്കുന്നതാണു്.
lilo ഓടിക്കുന്ന സമയത്ത് എന്തെങ്കിലും പ്രയാസം
നേരിടുകയാണെങ്കില് /
to
vmlinuz
ലേയും initrd
ലേയും
പ്രതീകാത്മക കണ്ണികള്ളും, നിങ്ങളുടെ /etc/lilo.conf
ഫയലിന്റെ ഉള്ളടക്കവും പരിശോധിക്കുമല്ലോ.
വീണ്ടും ബൂട്ട് ചെയ്യുന്നതിന് മുമ്പേ lilo ഓടിക്കാന്
മറക്കുകയോ അല്ലെങ്കില് അതിന് മുമ്പേ വ്യവസ്ഥിതി തനിയേ വീണ്ടും ബൂട്ട്
ചെയ്യപ്പെടുകയോ ആണെങ്കില് നിങ്ങളുടെ വ്യവസ്ഥിതിയുടെ ബൂട്ടിങ്ങ്
പരാജയപ്പെടും. ലിലോ കണിശമായി കാണിക്കുന്നതിന് പകരം വ്യവസ്ഥിതി ബൂട്ട് ചെയ്യുന്ന
സമയത്ത് LI
മാത്രമേ കാണാന് കഴിയൂ.[5]. ഇതില് നിന്നും കരകയറുന്നതു എങ്ങനെയെന്നറിയാന് ഇവിടെ Section 4.1.3, “തിരിച്ചെടുക്കാന് തയ്യാറെടുക്കുക” നോക്കുക
ഒരു നവീകരണത്തിനു ശേഷം വ്യവസ്ഥിതി വീണ്ടും ബൂട്ട് ചെയ്യുമ്പോള് അടിസ്ഥാന വിഭാജനം കണ്ടെത്താന് കേര്ണലിനാവുന്നില്ലെന്ന് ചില ഉപയോക്താക്കള് പരാതിപ്പെട്ടിട്ടുണ്ട്.
അത്തരം സന്ദര്ഭങ്ങളില്, വ്യവസ്ഥാബൂട്ട് താഴെപ്പറയുന്ന സന്ദേശവുമായി തൂങ്ങിനില്ക്കും:
റൂട്ട് ഫയല് സിസ്റ്റത്തിനായി കാത്തു നില്ക്കുന്നു ...
അല്പസമയത്തിന് ശേഷം ഒരു നഗ്നമായ ബുസിബോക്സ് പ്രോംപ്റ്റ് പ്രത്യക്ഷപ്പെടുകയും ചെയ്യും.
കേര്ണലിന്റെ നവീകരണം പുതിയ തലമുറയിലെ IDE സാരഥികളെ
തിരുകിക്കയറ്റുമ്പോള് ഇങ്ങനെ സംഭവിക്കാറുണ്ട്. IDE
ഡിസ്കിന്റെ പഴയ സാരഥികളുടെ നാമകരണ കീഴ്വഴക്കം hda
,
hdb
, hdc
, hdd
എന്നിങ്ങനെയായിരുന്നു. അതേ ഡിസ്കുകളുടെ പുതിയ സാരഥികള്ക്ക് ക്രമത്തില്
sda
, sdb
, sdc
,
sdd
എന്നുമായിരിക്കും പേര്. പുതിയ നാമകരണ കീഴ്വഴക്കം
കണക്കിലെടുക്കാന് നവീകരണ പ്രക്രിയ ഒരു പുതിയ
/boot/grub/menu.lst
ഫയലുണ്ടാക്കുന്നില്ലെങ്കിലാണ്
പ്രശ്നങ്ങള് പ്രത്യക്ഷപ്പെടുന്നത്. ബൂട്ടിങ്ങിനിടെ ഗ്രബ് അയച്ചുകൊടുക്കുന്ന
അടിസ്ഥാന വിഭാജനം കേര്ണലിന് കണ്ടെത്താനാവുന്നില്ല.
നവീകരണത്തിനു ശേഷം ഇങ്ങനെ ഒരു പ്രശ്നം നേരിടേണ്ടി വന്നിട്ടുണ്ടെങ്കില് Section 4.8.2, “നവീകരിച്ചതിനുശേഷമുള്ള പ്രശ്നത്തില് നിന്നും എങ്ങനെ രക്ഷപ്പെടാം”ലേക്ക് കടക്കുക. നവീകരണത്തിന് മുമ്പ് ഇത് സംഭവിക്കാതിരിക്കന് തുടര്ന്ന് വായിക്കുക.
രണ്ടു തുടര്ബൂട്ടിങ്ങുകള്ക്കിടക്ക് മാറ്റം വരാത്ത അടിസ്ഥാന ഫയല്വ്യവസ്ഥയുടെ താദാത്മ്യനിരൂപകം(Identifier) ഉപയോഗിച്ചാല് ഈ പ്രശ്നം അപ്പാടെ ഒഴിവാക്കാവുന്നതാണ്. ഇത് സാധിച്ചെടുക്കാന് രണ്ടു പോംവഴികളുണ്ട് - ഫയല്വ്യവസ്ഥക്ക് നാമപത്രം(label) ഘടിപ്പിക്കുക, അല്ലെങ്കില് ഫയല് വ്യവസ്ഥക്ക് ആഗോള പ്രത്യേകതയുള്ള തിരിച്ചറിയല് ഉപാധി (UUID) ഉപയോഗിക്കുക. ഡെബിയന്റെ എച് പ്രകാശനത്തിന് ശേഷം ഈ രീതിക്ക് പിന്തുണ ലഭ്യമാണ്.
ഈ രണ്ടു രീതിക്കും ഗുണങ്ങളും ദോഷങ്ങളുമുണ്ട്. ലേബല് ഇടുന്ന രീതി കൂടുതല് വായിക്കത്തക്കതാണ്, എന്നാല് നിങ്ങളുടെ യന്ത്രത്തിലെ വേറൊരു ഫയല് വ്യവസ്ഥിതിയില് ഇതെ ലേബലുണ്ടെങ്കില് പ്രശ്നങ്ങള് sഷ്ടിക്കും. UUIDസമീപനം വളരെ വിരൂപമാണ്, എങ്കിലും രണ്ട് UUIDകള് ഏറ്റുമുട്ടുന്നത് അസംഭാവ്യമാണ്.
താഴെകൊടുത്ത ഉദാഹരണത്തിന് അടിസ്ഥാന ഫയല്വ്യവസ്ഥ
/dev/hda6
ലാണെന്ന് സങ്കല്പ്പിക്കുക. നിങ്ങളുടെ
വ്യവസ്ഥയില് udevസ്ഥാപിച്ചിട്ടുണ്ടെന്നും ext2 അല്ലെങ്കില് ext3 ഫയല്
വ്യവസ്ഥയണെന്നും കൂടി സങ്കല്പ്പിക്കുക.
ലേബലിംഗ് സമീപനം നടപ്പിലാക്കാന്:
e2label /dev/hda6 rootfilesys: ആജ്ഞ നടത്തിക്കൊണ്ട് ഫയല് വ്യവസ്ഥ ലേബല് ചെയ്യുക (പേരിന് <16 അക്ഷരങ്ങള് വേണം)
/boot/grub/menu.lst
തുറന്നു ഈ വരി :
# kopt=root=/dev/hda6 ro
ഇങ്ങനെ മാറ്റുക
# kopt=root=LABEL=rootfilesys ro
![]() | Note |
---|---|
വരിയുടെ തുടക്കത്തിലുള്ള ഈ |
menu.lst
എന്ന ഫയലിലെ kernel
വരികള്
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
യുടെ സാങ്കല്പിക കണ്ണിയുടെ പേരാണു്
UUID, അതായതു
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
എന്ന ഫയലിലെ kernel
വരികള്
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
ഇതില് ആദ്യത്തെ കളം മാത്രം മാറ്റിയാല് മതി. മറ്റുള്ളവ മാറ്റേണ്ട കാര്യമില്ല
നിങ്ങള്ക്ക് ബൂട്ട് ചെയ്യാനുള്ള ചേര്പ്പ് തെരഞ്ഞെടുക്കാന് വിഭവങ്ങളുടെ വിനിമയ തലം ഗ്രബ് കാണിച്ചുതരുന്നു എങ്കില് ഇത് പ്രാവര്ത്തികമാക്കാം. അങ്ങനെ ഒരു വിഭവപട്ടിക പ്രത്യക്ഷമാകുന്നില്ലെങ്കില്, കേര്ണല് ബൂട്ട് ചെയ്യുന്നതിന് മുമ്പ് Escകീ അമര്ത്തുന്നത് അത് പ്രത്യക്ഷമാകാന് സഹായിക്കും. ആ വിഭവങ്ങളിലേക്ക് ഇറങ്ങിചെല്ലാന് നിങ്ങള്ക്കാവുന്നില്ലെങ്കില്, Section 4.8.2.2, “പരിഹാരം 2” ഓ Section 4.8.2.3, “പ്രതിവിധി 3”ഓ പരീക്ഷിക്കാവുന്നതാണ്.
ഗ്രബ് മെനുവില് നിന്നും നിങ്ങള്ക്കു ബൂട്ട ചെയ്യേണ്ട വരി തെരഞ്ഞെടുക്കുക. ഈ വരിയുടെ ഐച്ഛികങ്ങള് മാറ്റുന്നതിനായി കീബോര്ഡില് നിന്നും 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
a
, b
,
c
or d
അക്ഷരങ്ങളാകയാല്
a
, b
, c
or
d
മാറ്റിവെയ്ക്കുക. എന്റെ ഉദാഹരണത്തില് ആ വരി ഇങ്ങനെ വരും:
kernel /vmlinuz-2.6.26-1-686 root=/dev/sda6 ro
കീബോര്ഡില് Enter അമര്ത്തി വരുത്തിയ മാറ്റങ്ങള്
സംരക്ഷിക്കുക. മറ്റുള്ള വരികളില് ഇങ്ങനെ
hd
കാണുന്നുവെങ്കില്,അതും
മാറ്റുക. X
root (hd0,0)
എന്ന വരി മാറ്റരുതു്. എല്ലാ
മാറ്റങ്ങളും ചെയ്തു കഴിഞ്ഞാല് b അമര്ത്തുക. താങ്കളുടെ
സിസ്റ്റം സാധാരണപോലെ ബൂട്ട് ചെയ്യേണ്ടതാണു്.
താങ്കളുടെ സിസ്റ്റം വിജയകരമായി ബൂട്ട് ചെയ്ത സ്ഥിതിക്ക് , ഈ പ്രശ്നം സ്ഥിരമായി പരിഹരിക്കേണ്ടതാണു. Section 4.8.1, “നവീകരിക്കുന്നതിനു മുന്പ് പ്രശ്നം എങ്ങനെ ഒഴിവാക്കാം” എന്ന കണ്ണിയിലേക്കു പോയി, പറഞ്ഞിട്ടുള്ള രണ്ടു വഴികളില് ഒരെണ്ണം അവലംബിക്കുക
ഡെബിയന് പ്രതിഷ്ഠാപന മാദ്ധ്യമം
(CD/DVD) ഉപയോഗിച്ച് ബൂട്ട് ചെയ്ത്
തയ്യാറാകുമ്പോള് വീണ്ടെടുക്കല് ഭാവം (Rescue mode) കയറ്റാന്
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
നിങ്ങളുടെ അടിസ്ഥാന ഫയല് വ്യവസ്ഥ ഏതു വിഭാജനത്തിലാണെന്ന് അറിയാമെങ്കില് യോജിച്ചത് തെരഞ്ഞെടുക്കുക. അറിയില്ലെങ്കില്, ആദ്യത്തേത് പരിശോധിക്കുക. അസാധുവായ അടിസ്ഥാന ഫയല് വ്യവസ്ഥയാണെന്ന് ആക്ഷേപമുണ്ടായാല്, അടുത്തത് പരിശോധിക്കാം.അങ്ങനെ തുടരാം. ഒന്നിന് ശേഷം വേറൊന്ന് എന്ന പരിശോധനാരീതി നിങ്ങളുടെ വിഭാജനങ്ങളെ ബാധിക്കരുത്. നിങ്ങളുടെ ഡിസ്കില് ഒരു പ്രവര്ത്തകവ്യവസ്ഥ മാത്രമേ സ്ഥാപിച്ചിട്ടുള്ളൂ എങ്കില് ശരിയായ അടിസ്ഥാന ഫയല് വ്യവസ്ഥാ വിഭാജനം കണ്ടെത്തുന്നത് എളുപ്പമാണ്. ഡിസ്കില് കൂടുതല് പ്രവര്ത്തക വ്യവസ്ഥകള് പ്രതിഷ്ഠിച്ചിട്ടുണ്ടെങ്കില് അടിസ്ഥാന ഫയല് വ്യവസ്ഥാ വിഭാജനം ഏതെന്ന് കൃത്യമായി അറിഞ്ഞിരിക്കുന്നതാണ് നന്നാവുക. താങ്കളുടെ റൂട്ട് ഫയല് സിസ്റ്റം പാര്ട്ടീഷന് ഏതെന്നു അറിയാമെങ്കില് അനുയോജ്യമായതു തെരഞ്ഞെടുക്കുക. അല്ലെങ്കില്
ഒരിക്കല് ഒരു വിഭാജനം തെരഞ്ഞെടുത്തു കഴിഞ്ഞാല്, ഐച്ഛികങ്ങളുടെ ഒരു നിരതന്നെ വിട്ടുതരും. തെരഞ്ഞെടുത്ത വിഭാജനത്തില് (Partition) ഒരു തൊണ്ട്(ഷെല്) നിര്വ്വഹണ ഐച്ഛികം തെരഞ്ഞെടുക്കുക. അത് നടപ്പിലാക്കാന് പറ്റില്ലെന്ന് ആക്ഷേപം ഉന്നയിക്കുകയാണെങ്കില് വേറൊരു വിഭാജനം സ്വീകരിക്കുക.
ഇപ്പോള് നിങ്ങള്ക്ക് ഒരു ഉപഭോക്താവായി /target
ല്
കയറ്റിയ അടിസ്ഥാന ഫയല്വ്യവസ്ഥയെ സമീപിക്കാനാവും. ഖരഡിസ്കിലുള്ള
/boot
, /sbin
ഉം,
/usr
തട്ടുകളും എന്നിവയുടെ ഉള്ളടക്കത്തിലേക്കാണ്
നിങ്ങള്ക്ക് പ്രവേശിക്കേണ്ടത്. അവ ഇപ്പോള്
/target/boot
, /target/sbin
/target/usr
എന്നിവയില് ലഭ്യമാവണം. ഈ തട്ടുകള് മറ്റു
വിഭാജനങ്ങളില് കയറ്റണ്ട ആവശ്യമുണ്ടെങ്കില്, അങ്ങനെ ചെയ്യാം.( എന്താണ്
ചെയ്യേണ്ടതെന്ന് നിങ്ങള്ക്ക് അറിയില്ലെങ്കില്
/etc/fstab
കാണുക).
സ്ഥിരമയ ഒരു പ്രശ്ന പരിഹാരത്തിന് Section 4.8.1, “നവീകരിക്കുന്നതിനു മുന്പ് പ്രശ്നം എങ്ങനെ ഒഴിവാക്കാം”ല് എത്തി രണ്ടിലൊരു നിര്ദ്ദിഷ്ട
മാര്ഗ്ഗം സ്വീകരിക്കാവുന്നതാണ്. exit
എന്ന് അടിച്ചു
ചേര്ത്ത് വീണ്ടെടുപ്പില്നിന്ന് പുറത്ത് കടന്നശേഷം സാധാരണപോലെ വീണ്ടും ബൂട്ട്
ചെയ്യാന് reboot
തെരഞ്ഞെടുക്കുക.( ബൂട്ട് മാദ്ധ്യമം
നീക്കം ചെയ്യാന് മറക്കണ്ട.)
സജീവ ഡെബിയന്(Debiyan Live), നോപ്പിക്സ്, സജീവ ഉബുണ്ടു ഇവയില് നിങ്ങളുടെ പ്രിയ വിതരണ സജീവ സിഡി വഴി ബൂട്ട് ചെയ്യുക.
നിങ്ങളുടെ /boot
തട്ട് കിടക്കുന്ന വിഭാജനം കയറ്റുക. ഇത്
ഏതാണെന്ന് നിങ്ങള്ക്ക് അറിയില്ലെങ്കില് dmesgആജ്ഞയുടെ
ഉത്പന്നം പരിശോധിച്ച് നിങ്ങളുടെ ഡിസ്ക് hda
,
hdb
, hdc
, hdd
എന്നാണോ, അതോ sda
, sdb
,
sdc
, sdd
എന്നാണോ അറിയപ്പെടുന്നത് എന്ന്
കണ്ടെത്തുക. ഏതു ഡിസ്കിലാണ് ജോലി എന്ന് ഒരിക്കല് മനസ്സിലാക്കി കഴിഞ്ഞാല്
ഉദാഹരണത്തിന്, sdb
,ഡിസ്കിന്റെ വിഭാജന പട്ടികയും ശരിയായ
വിഭാജനവും കണ്ടെത്താന് താഴെ കൊടുത്ത ആജ്ഞ നടപ്പിലാക്കുക: fdisk -l
/dev/sdb
നിങ്ങള് ശരിയായ വിഭാജനം /mnt
ല് കയറ്റിയിട്ടുണ്ടെന്നും ഈ
വിഭാജനത്തില് /boot
തട്ട് ഉള്പ്പെടുനുണ്ടെന്നും
അനുമാനിച്ചാല് /mnt/boot/grub/menu.lst
ഫയലില്
തിരുത്തുകള് വരുത്താം.
ഇതുപോലൊരു ഭാഗം കണ്ടെത്തുക:
## ## സഹജമയ ഐച്ഛികങ്ങള് അവസാനിക്കുന്നു ## ## title ഡെബിയന് ഗ്നൂ ലീനക്സ്, കേര്ണല് 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 ഡെബിയന് ഗ്നൂ ലീനക്സ്, കേര്ണല് 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 ### ഡെബിയന് യാന്ത്രിക കേര്ണല് പട്ടിക അവസാനിക്കുന്നു.
എന്നിട്ട് hda
, hdb
,
hdc
, hdd
എന്നിവ യഥാക്രമം
sda
, sdb
, sdc
,
sdd
എന്നാക്കി മാറ്റുക. വരികള് ഇങ്ങനെ പരിഷ്കരിക്കരുത്:
root (hd0,0)
വീണ്ടും ബൂട്ട് ചെയ്യുക, സജീവ സിഡി എടുത്തു മാറ്റുക നിങ്ങളുടെ വ്യവസ്ഥിതി ശരിയായി ബൂട്ട് ചെയ്യും.
ബൂട്ട് ചെയ്തു കഴിഞ്ഞാല്, സ്ഥിരമായ പ്രശ്നപരിഹാരത്തിന് Section 4.8.1, “നവീകരിക്കുന്നതിനു മുന്പ് പ്രശ്നം എങ്ങനെ ഒഴിവാക്കാം”ലെ രണ്ടു നിര്ദ്ദിഷ്ട പോംവഴികളിലൊന്ന് പ്രയോഗിക്കാം.
നവീകരണത്തിന് ശേഷം അടുത്ത പ്രസാധനത്തിനുള്ള തയ്യാറെടുപ്പിനായി നിങ്ങള്ക്ക് ഒട്ടനവധി കാര്യങ്ങള് ചെയ്യാനാവും.
പുതിയ കേര്ണല് ബിംബ (image)ത്തിന്റെ മെറ്റാപാക്കേജ് പഴയതിന്റെ ആശ്രിതത്വ നിലക്ക് ഉള്ളിലേക്ക് വലിച്ചെടുത്തിട്ടുണ്ടെങ്കില്, അത് യാന്ത്രികമായി പ്രതിഷ്ഠിക്കപ്പെട്ടതായി കണക്കാക്കും, ഇത് ഒഴിവാക്കപ്പെടേണ്ടതാണ്.
# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1)
കാലഹരണപ്പെട്ടതും ഉപയോഗശൂന്യവുമായ പൊതികള് Section 4.10, “കാലഹരണപ്പെട്ട പൊതികള്”ല് പറഞ്ഞ പ്രകാരം നീക്കം ചെയ്യണം. അവ ഏതു ക്രമീകരണ ഫയലുകളാണ് ഉപയോഗപ്പെടുത്തുന്നത് എന്ന് പുനപരിശോധിച്ച് ക്രമീകരണ ഫയലുകള് നീക്കം ചെയ്യാന് പൊതികള് ഒഴിവാക്കല് പരിഗണിക്കാം.
പുതിയതായി വളരെ അധികം പൊതികള് ഉള്ക്കൊള്ളിക്കുന്നുണ്ട്, etchല്നിന്ന് ഏതാണ്ട് രണ്ടായിരത്തോളം പൊതികള്ക്ക് സ്ഥിരവിശ്രമം നല്കി ഒഴിവാക്കുന്നുമുണ്ട്. കാലാനുസൃതമല്ലാത്ത ഇത്തരം പൊതികള്ക്ക് മേലില് നവീകരണ സാദ്ധ്യത ഉണ്ടായിരിക്കില്ല. ആഗ്രഹിക്കുന്നു എങ്കില്, ഇത്തരം കാലഹരണപ്പെട്ട പൊതികള് തുടര്ന്നും ഉപയോഗിക്കുന്നതില്നിന്ന് നിങ്ങളെ ആരും വിലക്കുന്നില്ല, എങ്കിലും lennyന്റെ പ്രകാശനത്തിന് ശേഷം ഒരു വര്ഷം കഴിഞ്ഞാല് ഇവക്കുള്ള സുരക്ഷ ഡെബിയന് പദ്ധതി തുടരുകയില്ല.[6], ഇതിനിടക്ക് മറ്റു തരത്തിലുള്ള പിന്തുണയും സാധാരണ ഉണ്ടാവില്ല. ലഭ്യമായ മറ്റ് ഏതെങ്കിലും ഉപയോഗിച്ച് പകരം വെയ്ക്കാന് ശുപാര്ശ ചെയ്യുന്നു.
വിതരണങ്ങളില്നിന്ന് പൊതികള് നീക്കം ചെയ്യപ്പെടേണ്ടിവരുന്നതിന് പല കാരണങ്ങളുമുണ്ട്: അവയൊന്നും വരുംകാലത്തേക്കായി പരിപാലിക്കപ്പെടില്ല; ഡെബിയന് നിര്മ്മാതാക്കളിലാരും അവ പരിപാലിക്കാന് ഒരിക്കലും താത്പര്യം കാണിക്കില്ല; അവയുടെ പ്രവര്ത്തന ശേഷി മറ്റു സോഫ്റ്റ്വേറുകള് (മറ്റു പതിപ്പുകള്) അതിലംഘിച്ചുകഴിഞ്ഞു: അല്ലെങ്കില്, അവയിലെ പിഴവുകള് കാരണം lennyനു യോജിച്ചതായി പരിഗണിക്കാനാവില്ല. എങ്കിലും അത്തരം പൊതികള് വിതരണത്തിലെ “unstable”പതിപ്പില് ഉണ്ടായിരിക്കും.
നവീകരിക്കപ്പെട്ട വ്യവസ്ഥിതിയിലെ “obsolete”പൊതികള് കണ്ടെത്തുന്നത് വളരെ എളുപ്പമാണ്, കാരണം പൊതികള് കൈകാര്യം ചെയ്യുന്ന മുന്തല (front end) അങ്ങനെ അടയാളപ്പെടുത്തിയിരിക്കും. നിങ്ങള് aptitudeആജ്ഞ ഉപയോഗിക്കുകയാണെങ്കില്, ഇത്തരത്തിലുള്ള പൊതികളെ “Obsolete and Locally Created Packages”ല് പട്ടിക തിരിച്ചു കാണിക്കും. dselect ആജ്ഞ ഇതുപോലുള്ള ഒരു അദ്ധ്യായം സൃഷ്ടിയ്ക്കും, എന്നാല് പട്ടികയില് അല്പം ചില മാറ്റങ്ങളുണ്ടാകും.
etchല് പൊതികളുടെ പ്രതിഷ്ഠാനത്തിന് aptitudeആജ്ഞ നിങ്ങള് ഉപയോഗിച്ചിട്ടുണ്ടെങ്കില്; കായികമായി പ്രതിഷ്ഠിച്ച അത്തരം പൊതികള് നിരീക്ഷിക്കപ്പെട്ട്, പൊതികള് നീക്കം ചെയ്തതുകൊണ്ട് മേലില് ആവശ്യമില്ലാതെവന്നതും ആശ്രിതത്വം മാത്രം കാരണം ഉള്ളിലേക്കെടുത്തതുമായ അവ കാലഹരണപ്പെട്ടതായി മുദ്രകുത്താന് കഴിയും. മാത്രവുമല്ല, deborphan പോലെ aptitude ആജ്ഞ, ആശ്രിതത്വം കാരണം യാന്ത്രികമായി പ്രതിഷ്ഠിക്കപ്പെട്ടവയെപ്പോലെ കൈയാല് പ്രതിഷ്ഠിക്കപ്പെട്ട പൊതികള് കാലഹരണപ്പെട്ടതായി അടയാളപ്പെടുത്തില്ല.
deborphan, debfoster or
cruft പോലുള്ള മറ്റു അധിക ഉപകരണങ്ങള് ഉപയോഗിച്ചും
കാലഹരണപ്പെട്ട പൊതികള്
കണ്ടെത്താവുന്നതാണ്. deborphanആജ്ഞയാണ് ശക്തിയായി ശുപാര്ശ
ചെയ്യുന്നത്, തനതായ രീതിയില് കാലഹരണപ്പെട്ട ഗ്രന്ഥാവലികളും
“libs
”ലെ അല്ലെങ്കില് വേറൊരു പൊതികളും
ഉപയോഗിക്കതെ കിടക്കുന്ന “oldlibs
”ലെ ഭാഗങ്ങളും
മാത്രമേ കാലഹരണപ്പെട്ടതായി പ്രസ്താവിക്കൂ. അബദ്ധമായ ഫലങ്ങള് ഉണ്ടാക്കാന്
സാദ്ധ്യതയുളള സഹജമല്ലാത്ത പരുക്കന് ഐച്ഛികങ്ങള് ഉപയോഗിക്കുന്നുണ്ടെങ്കില്
പ്രത്യേകിച്ചും, ഈ ഉപകരണങ്ങള് മുന്നോട്ട് വെയ്ക്കുന്ന പൊതികള് കണ്ണടച്ച്
നീക്കം ചെയ്യരുത്. അവ നീക്കം ചെയ്യുന്നതിന് മുമ്പായി, നീക്കം ചെയ്യാനായി
നിര്ദ്ദേശിക്കപ്പെട്ട പൊതികളുടെ ഉള്ളടക്കം നിങ്ങള് വ്യക്തിപരമായി
പുന:പരിശോധിക്കാന് ശക്തമായി ശുപാര്ശ ചെയ്യുന്നു.
ഡെബിയന്റെ പിഴവ് കണ്ടെത്തല് സംവിധാനം(Debian Bug Tracking System) പലപ്പോഴും പൊതികള് നീക്കം ചെയ്തതിന്റെ അധികവിവരണം തരാറുണ്ട്. പൊതിയുടെ സംഗ്രഹിക്കപ്പെട്ട പിഴവ് ശേഖരങ്ങളും ftp.debian.org pseudo-packageലെ പിഴവ് ശേഖരങ്ങളും രണ്ടും നിങ്ങള് പരിശോധിച്ചിരിക്കണം.
The list of obsolete packages includes:
വ്യവസ്ഥിയുടെ പരിപാലനധര്മ്മം മെച്ചപ്പെടുത്തുന്നതിന് etchലെ ചില പൊതികള് പിളര്ന്ന് lennyല് പ്രയോഗിച്ചിരിക്കും. അത്തരം സന്ദര്ഭങ്ങളില് lennyലേക്കുള്ള നവീകരണമാര്ഗ്ഗം എളുപ്പമാക്കാന് പുതിയ പൊതികള് പ്രതിഷ്ഠിക്കനാവശ്യമായ ആശ്രിതത്വത്തോടുകൂടിയ “dummy” പൊതികള് ചേര്ക്കാറുണ്ട്: etchലെ പഴയ പൊതികളുടെ അതേ പേരുള്ള ഒഴിഞ്ഞ പൊതികള്: നവീകരണത്തിന് ശേഷം ഇത്തരം പൊതികള് കാലഹരണപ്പെട്ടതായി കണക്കാക്കി സുരക്ഷിതമായി നീക്കം ചെയ്യാവുന്നതാണ്.
മിക്കവാറും (എല്ലാമില്ല.) വ്യാജപ്പൊതികളുടെ വിശദീകരണങ്ങളില് ആവശ്യകത
വെളിപ്പെടുത്താറുണ്ട്. വ്യാജപ്പൊതികളുടെ വിശദീകരണങ്ങള്
ഏകീകരിക്കപ്പെട്ടവയല്ല, എങ്കിലും, നിങ്ങളുടെ വ്യവസ്ഥിതിയില് അവ
കണ്ടെത്തുന്നതിന് ഉപകാരപ്പെടുന്ന deborphanനോടൊപ്പം
--guess
ഐച്ഛികം കൂടി കാണണം. നവീകരണത്തിനു ശേഷം നീക്കം
ചെയ്യപ്പെടാനുദ്ദേശിക്കപ്പെട്ടവയല്ല ചില വ്യാജപ്പൊതികള്, മറിച്ച്,
കാലങ്ങള്ക്കു ശേഷം പരിപാടിയുടെ നിലവിലുള്ള പതിപ്പിന്റെ വിവരങ്ങള്
ലഭ്യമാക്കാന് കൂടിയാണ് എന്നു കൂടി ഓര്മ്മിക്കണം.
[2] നിങ്ങളുടെ ബൂട്ട് പരാമീറ്ററില് panic=0
എന്നു് ചേര്ത്തു്
ഈ കഴിവു് പ്രവര്ത്തനരഹിതമാക്കാം.
[3] ഡെബിയനിലെ പൊതികളുടെ നടത്തിപ്പു് സാധാരണയായി ഒരു പൊതിയ്കു് പകരമാണെന്നു് പറയാത്ത സന്ദര്ഭങ്ങളില് മറ്റേ പൊതിയുടെ ഫയലുകള് മാറ്റാനോ നീക്കം ചെയ്യാനോ സമ്മതിയ്ക്കാറില്ല.
[4]
ശൃംഖലാകര്മ്മ വിനിമയതലങ്ങള്ക്ക് വിടാതെ പിന്തുടരുന്ന പേരുകളുണ്ടാവാന്
/etc/udev/rules.d/75-persistent-net-generator.rules
ചെറു
ആജ്ഞ ഉപയോഗിച്ച് യാന്ത്രികമായി സൃഷ്ടിക്കാം. udev
കൊണ്ട് NICക്ക് ഇത്തരം
ഉപകരണങ്ങള്ക്കുള്ള സ്ഥിരനാമങ്ങള് സൃഷ്ടിക്കുന്നത് അസാധുവാക്കാന് ഈ symlink
നീക്കം ചെയ്യണം.
[5] liloയുടെ ബൂട്ടിങ്ങ് പിശക് കോടുകളുടെ വിശദ വിവരങ്ങള്ക്ക് ദയവായി The Linux Bootdisk HOWTO കാണുക.
[6] അല്ലെങ്കില് ആ കാലഘട്ടത്തില് വേറൊരു പ്രകാശനം നടക്കാത്തിടത്തോളം. കൃത്യമായി പറഞ്ഞാല്, സുസ്ഥിരമായ രണ്ടു പതിപ്പുകള്ക്ക് മാത്രമേ ഒരേസമയം പിന്തുണയുണ്ടാകൂ.