Fedora upgrade 20 -> 21 otthoni szerveren

Már rég lecsengtek ezek a bejegyzések, de ha valaki úgy áll a dologhoz, mint én (tesztelje ki más, én majd csak a jóba esek bele), akkor annak érdekes lehet ez a bejegyzés.

Téma: Hogy nézett ki a Fedora 20 -> 21 upgrade az otthoni szerveren?

Az upgrade-et még január végén megléptem laptop-on, de ugye egy szerveren (még ha csak "otthoni" is) kicsit máshogy csinálja az ember. Amit tudni kell a szerverről röviden: Intel Atom 330-as gép, két merevlemezzel, amin RAID1-ben van a rendszer és egy adatpartíció, valamint LVM-ben egy afajta letöltő-ideiglenes hely, ezenkívül gateway szerepet is játszik, tehát egy hálózati lába az ADSL modem felé néz, míg a másik a belső hálózat fele.

Kezdjünk is neki!

  1. Előkészület: boot-oltam egy sysrescuecd-t CD-ről, és lementettem egy külső vinyóra a rendszert, egész egyszerűen .tar.gz-be.
  2. Upgrade: fedup --network 21 --product=nonproduct. Itt volt egy kis megakadás: Valami olyasmivel fejeződött be a transaction check, hogy: elfutils-libs-0.161-2.fc21.i686 requires elfutils-libelf(x86-32) = 0.161-2.fc21, meg hogy folytassam a saját felelőségemre. Ezt úgy sikerült orvosolnom, hogy felrakni az említett csomagot, legalábbis a fedup újrafuttatásakor már nem írta ki ezt a problémát. Reboot!
  3. A Grub-ból a System upgrade-et választottam, és a következő reboot-ig nem is volt dolgom.
  4. A második reboot után már a Fedora 21 futott. És ennyi! Semmi error, semmi szívás, semmi izgalom. Komolyan elgondolkodtam, hogy rakok egy Gentoo-t, mert így semmi izgalom nincs (tudom, tudom, az rolling-release, de akkor is).
  5. Upgrade után néhány szokásos command a wiki alapján:
    1. rpm --rebuilddb
    2. yum distro-sync --setopt=deltarpm=0
    3. rpmconf -a : itt nyilván volt pár dolog, amin vakarózni kellett (ugye ez a parancs mutatja meg a konfigfájlváltozásokat, etc-update Gentoo-ul).

Ennyi! A rendszer egyelőre jól működik, remélem így is marad. Köszönöm a figyelmet!

( locsemege v | 2015. 03. 15., v – 22:06 )

Nekem a fedup-pal gondom volt akkor, ha a /var önálló filerendszer, így aztán az utóbbi időben yum --releasever=21 distro-sync módon upgrade-elek. Egyébként azt hittem elsőre, hogy 21 --> 22 a frissítés, úgy még érdekesek is lettek volna a tapasztalataid. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A gond abból adódott, hogy a /var/lib alá pakolta az rpm adatbázist a rootfs-re, majd reboot után rácsatolta a régi /var-t tartalmazó fs-t a /var csatolási pontra, amelynek következtében kitakarta a korábban odatett file-okat, alkönyvtárakat. Ezen némileg megszeppent a fedup - de az is lehet, a sima telepítő, nem emlékszem már -, amitől aztán szépen elhasalt. Azóta nem kísérletezem, nem érdekel, megjavították-e, jó nekem úgy, ahogy írtam.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( uid_4263 v | 2015. 03. 16., h – 09:06 )

"Fedora" [...] "tesztelje ki más"
Kérem kapcsolja ki :)

--
arch,debian,openelec,android

Hat peldaul a sokat emlegetettt stabilitas. Volt, hogy az X-nek meg az elindulas se akart osszejonni.

Aztan a kompatibilitas. Az a videokartya, ami rohogve ment meg openSUSE alatt is, az Fedora alatt csak szenvedessel - adott ki kepet egyaltalan. A binaris nVidia drivert meg sehogy nem birtam tamogatott modon feleroszakolni - az nVidiatol letoltott cuccal meg nem akartam szenvedni (ugye olyankor nincs dkms).

Lehet, hogy turelmesebbnek kellett volna lennem, az is lehet, hogy tovabb kellett volna keresni a megoldasokat, mivel azonban nekem mar volt egy jol bejaratott oprendszerem, amivel meg legelso alkalommal se szivtam egy oranal tobbet a hardver eletre lehelesevel, nem volt belso kesztetesem hajtani a latszolag doglott lovat. Ket estet raaldoztam, tobbet nem akartam raszanni, mert nem valtotta be a hozza fuzott remenyeket.
--
Blog | @hron84
Üzemeltető macik

Stabilitással nekem is volt gondom... aztán elvittem a gépemből 4 GiB RAM-ot garanciális cserére. ;)

Nekem is nVidia kártyám van, nouveau driverrel működik. Egy ismerősöm notebook-jának gondja volt vele, neki viszont az rpmfusion.org repóból megy az nvidia driver.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem ezek hardver függő problémák. Valóban korábban volt VGA driver probléma nálam is. De meg lehetett oldani.
De pl. a Wifi driver talán a fedora-ban a legjobb.

Én a Linux megismerése óta (kb. 1998) csak redhat/fedora-t használok és nem volt komoly problémám (kipp-kopp lekopogom). Én már annyira megszoktam a redhat/fedora vonalat, hogy nem is tudnék váltani. A többi disztrib is nagyon jó, de már megszoktam ezt a vonalat. :)

Hozzád hasonlóan én is elfogult vagyok, de meglepődtem, hogy manapság is lehet szívni. Nekem az alábbival sikerült:

- wifi: b43
- vga: i915

Kb. kitéptem az összes hajam, működik akár órákig is, majd a b43 driver képes elrántani úgy a kernelt, hogy megáll, mint a szög. Egyedül a power kapcsoló hosszan nyomása a megoldás, már amennyiben ezt megoldásnak lehet nevezni. A HP Compaq notebook stabil, memtest nem mond hibát. Az i915 meg képes renderelési ámokfutásokra.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Dacr (nem ellenőrzött) | 2015. 03. 16., h – 15:12 )

A "saját felelősségre" általában akkor jön elő, ha van külső RPM a gépen, ami nem tárolóból jött. Ezt nyilván nem fogja tudni frissíteni és ezért szól, hogy lehet, hogy upgrade után az nem fog elindulni (mert mondjuk olyan függősége van).