Dotaz: problém s aktualizací ubuntu a diskovým oddílem boot

[TomasABC32]

Příloha:

• aktualizace.txt (1982 bytů)

Zdravím, chtěl jsem zaktualizovat ubuntu 14.04, ale napsalo mi to že v diskovém oddíle boot není dostatek místa ? Ostatní jsem zkopíroval do souboru v příloze...

---

---

Odpovědi

[Petr Šobáň]

No a problém je jaký?

Když místo není tak není HDD není nafukovací tak ho musíš udělat.

Takže odinstaluj staré balíčky které mají v názvu kernel - nech si pouze poslední verzi, případně předposlední.

[Jendа]

Technická, na Ubuntu se to jmenuje linux-image, ne kernel.

[Petr Šobáň]

Jasně ale když v Synaptics zadáš hledat kernel tak je to najde taky

[Hynek Bee]

Ahoj, kdysi jsem to řešil a popsal. Mrkni na tohle . Není to tak složité.

[Trubicoid2]

Ty kernely a initrd jen přibývají. Pomůže sudo apt-get --purge autoremove

[Jendа]

Bohužel u mě nejsou označené jako instalované automaticky, takže nepomůže. (mělo by to být výchozí nastavení, ale co já vím…)

[trubicoid2]

instalujes rucne primo ruzne verze? pak se to bohuzel musi i rucne cistit

kdyz bys nainstaloval treba linux-generic-lts-vivid, tak ten se bude sam udrzovat aktualni a stary verze jdou automaticky tim autoremove pryc

[Jendа]

Hm, fakt to funguje. Nevím, proč mi to předtím nešlo.

[nobody]

neni pravda, chova se to opravdu divne, mam metabalik linux-generic-lts-vivid, tomu se meni zavislost na nove vydane verzi baliku a pri aktualiaci se pak automaticky nainstaluji nove verze, aktualne je to linux-image-3.19.0-43-generic, nicmene i presto, kdyz dam autoremove tak mi to vzdy zobrazilo moznost odstranit jen nektere stare a nektere to nechavalo...(tu -43 verzi mam ted nastavenou jako manual i kdyz byla urcite instalavana auto pred ten metabalik v ramci upgrade)
dalsi vec je ze pro BFU by urcite bylo vhodne aby byla moznost (nejspis i default) aby to mazalo automaticky starsi jadra nez X poslednich v ramci "upgrade", nikoli po rucnim volani "autoremove"...

[trubicoid2]

mi se to chovalo divne, ale jednou sem to rucne procistil a ted to vypada, ze to fachci

s temi bfu mas pravdu, na prd je jim stopadesat poslednich jader

[Peter Golis]

Divne sa to chová každému, čo si inštaluje napríklad doplnkové ovládače cez "shell autobuild package". Virtual box, možno NVIDIA bin a AMD bin. Tie občas uzamknú aktuálnu verziu kernelu aby ju to nezmazalo aj s buildnutým ovládačom.

[Trubicoid2]

Nvidia bin mám, v pohodě

[nobody]

chova se mi to divne i na T42, neni VirtualBox, neni binarni nvidia ani fglrx(jede to na opensource radeon), neni ani nainstalovan dkms, presto mam takto:

linux-image-3.19.0-28-generic
linux-image-3.19.0-30-generic
linux-image-3.19.0-31-generic
linux-image-3.19.0-32-generic
linux-image-3.19.0-33-generic
linux-image-3.19.0-39-generic
linux-image-3.19.0-41-generic
linux-image-3.19.0-42-generic
linux-image-3.19.0-43-generic

tucne maji tag "auto", ostatni maji tag "manual", apt-get autoremove logicky ma snahu odebrat pouze s tagem auto, nicmene vsechny uvedene verze byli instalovany automaticky diky metabaliku linux-image-generic-lts-vivid pri beznem upgrade, zadny z nic sem neinstaloval rucne...
mohlo by se rict ze to muze byt rucnim aplikovanimLTS Enabled Stack (automaticky ani nejde, krome preinstalovani z 14.04.3 iso), nicmene situace s 3.13 ktere bylo automaticky instalovane z prvotniho 14.04 iso je takova:

linux-image-3.13.0-65-generic
linux-image-3.13.0-67-generic
linux-image-3.13.0-68-generic
linux-image-3.13.0-71-generic
linux-image-3.13.0-73-generic
linux-image-3.13.0-74-generic

opet tucne je s tag auto, ktere by se odinstalovalo automaticky pri autoremove...

[TomasABC32]

Díky Hynku, tvoje řešení mi pomohlo. Je to malinko nedotažené ze strany Ubuntu...

[nobody]

tve reseni je jen castecne, krome balicku linux-image jsou jeste dalsi linux-image-extra, linux-headers, linux-tools... takze:

# dohledani vsech s vynechanim balicku pro aktualne bezici jadro:
KERNEL=$(uname -r) dpkg-query -W -f='${binary:Package} \n' *${KERNEL/-*}* | grep -v  ${KERNEL/-generic}

# pripadne rovnou nabidka k jejich odinstalovani:
sudo apt-get purge $(KERNEL=$(uname -r) dpkg-query -W -f='${binary:Package} \n' *${KERNEL/-*}* | grep -v  ${KERNEL/-generic})

pokud by bylo nainstalovane jiz novejsi jadro nez je bezici, bude se to snazit odebrat hlavni jaderne metabalicky(bez verzi v nazvu) ktere jsou zavisle na poslednim instalovanem jadru, coz by odebralo vsechna jadra, takze pred potvrzenim odinstalovani NUTNO zkontrolovat ocima ze se budou odinstalovat POUZE balicky ktere v nazvu maji nejakou verzi jadra...
(aby se tomu predeslo automaticky, bylo by treba vzit kazdej nalezenej balicek a porovnat jestli je cislo verze vetsi nez bezici jadro a pokud ano tak vyloucit z odinstalovani...)

[Alkel U3]

Tímhle jsem taky chvíli trpěl. Pak mě napadlo zjistit, jestli má /boot na samostatném oddíle skutečně nějaký benefit - původně jsem to oddělil jen proto, že "mi to prostě přišlo jako dobrý nápad" . Podle toho, co jsem našel se to hodí u prehistorických systémů, které nedokázaly nabootovat z velkého harddisku a zašifrovaném / . Problém jsem jednou provždy vyřešil přesunutím /boot do rootovského oddílu.

http://unix.stackexchange.com/questions/256/is-it-good-to-make-a-separate-partition-for-boot

[Jooky (inactive)]

Stale to ma vyznam. Ja preferujem /boot namontovany RO a na sepratnom LV (lvm), alebo particii. Ked sa z nejakeho dovodu rozhodi / (root), tak mas stale moznost nabotovat rescue initrd a skusit s tym nieco spravit. Druha moznost je sifrovanie. Kernel a tooly na desifrovanie nemozes mat zasifrovane so vsetkym ostatnym :o)

Ubuntu ma toto dost zle poriesene. Ked si das zasifrovat disk instalatorom, tak ti spravi /boot + sifrovana particia. Pocas updatov tam nepochopitelne len stale prihadzuje kernely a skorsie ci neskorsie to dojde do stavu, ze nie je volne miesto. Zatial som to na takych systemoch riesil len odstranenim starsich kernel balickov, ale v vzdy to vydrzi len nejaku dobu ... uz dlhsie sa to riesi (bugreport)

[Alkel U3]

LV jsem zapomněl, pravda. Spíš jsem to myslel (ale blbě napsal) tak, že když k tomu není takovýhle konkrétní důvod, mít oddělený boot přináší akorát opruz při nutnosti častějšího čištění starých kernelů. Ale ano, má to svoje use-cases, které nejsou zrovna exotické.

[Jendа]

LV jsem zapomněl, pravda.

Jestli tím myslíš LVM, tak s tím problém není, GRUB z toho bez problému nabootuje taky.

Ale šifrované / je snad dneska standard.