Fedora 34

Ahogy tőlem ez megszokott, a hivatalos megjelenés, sőt, most a béta megjelenés előtt frissítettem a Fedora operációs rendszert. Eddig két gépen tettem meg. Az egyiken minden nehézség nélkül lezajlott a frissítés, a másikon saját hibámból nem, de ezt is megoldottam.

Történt ugyanis, hogy az rpm adatbázisom az ssd-men lévő önálló filerendszeren van, de telepítés közben betelt a filerendszer, így az rpm sqlite adatbázis olyan szinten hullott szét, hogy alig néhány ezer hiba lett benne. Mielőtt ezzel foglalkozhattam volna, egy nagyobb ssd-re kellett költöztetnem az egész oprendszert, tehát pendrive-ról boot-olva a régi ssd-ről az új nagyobb filerendszereire másoltam file-osan az rsync -avxHASX bűvszóval. Utána némi mount --bind és chroot parancs argumentumában kiadott grub telepítés következett, majd a régi ssd kiszerelése, új beszerelése jött. Persze előbb az fstab-ban és a grub.cfg-ben, valamint a loaderben az uuid-eket átírtam, ezek jellemzően a rootfs és a /boot filerendszerekre vonatkoznak.

A gép boot-olt a nagyobb ssd-ről probléma nélkül, de széthullott az rpm adatbázis, ahogy fentebb írtam. Ugyan a system-release szerint Fedora 34 volt, a dnf parancs Fedora 33-nak gondolta magát, szóval innen szép nyerni, hiszen nem futottak le a postinstall scriptek sem.

A dnf --releasever=34 kapcsolóval azért kényszeríthető, ideiglenesen tehát jó volt így. Jött egy rpm --rebuilddb, de ez is csak annyira teszi jóvá az egészet, hogy most már látjuk, hogy van néhány ezer hiba, duplikált csomag. Nem részletezem, néhány órányi szögeléssel helyrehoztam. Sikerült olykor manuálisan, olykor nem dnf-fel, hanem rpm-mel, olykor egy grep, cut, xargs, echo kombóval kigyűjtött csomaglista alapján rpm -e --justdb paranccsal törölni, hogy a file-ok azért maradjanak, és így tovább. A végefelé már annyira rendbeszedtem, hogy le tudtam futtatni upgrade-et, majd utána ráeresztettem megint a dnf system-upgrade download --releasever=34 --allowerasing parancsot, majd a sync; dnf system-upgrade reboot jött. Itt már csak alig néhány MB-ot telepített, eltávolított még néhány Fedora 33 maradványt, és ami a lényeg, végre Fedora 34-nek konfigurálta magát, így a dnf parancsot már nem kell forszírozni. Most a dnf check szerint végre jó. És nem mellesleg működik.

Ilyen mélyről, ennyire szétesett állapotból eddig még sohasem hoztam vissza operációs rendszert, de sikerült, működik. :)

Ami hiányzott, de már azóta lett:
xfce4-notes-plugin

Ami hiányzik:
xfce4-kbdleds-plugin

Néhány ikonnak más lett a neve, ezeket manuálisan ki kell javítani. Az órán és az időjárás jelzőn megváltozott a fontméret, át kellett állítani. Csináltam az egész filerendszerre selinux autorelabel-t, de van néhány selinuxos hibaüzenet, ezzel foglalkoznom kell. Egyelőre a notification-t kapcsoltam ki.

Amúgy tetszik, jó lesz, levelezés, böngésző működik, virtualizáció, fejlesztői környezet, céges vpn, svn szintén megy. Szóval elégedett vagyok vele.

( Carter | 2021. 03. 14., v – 19:08 )

mennyit számláztál volna egy ilyen munkáért, ha másnak, pénzért csinálod?

Nem vállaltam volna el, mert ha ennyire széthullik az rpm adatbázis, akkor vagy összejön, vagy nem. Ez saját gépem, van mentésem, s ha nincs más kiút, újra telepítettem volna. A személyes beállítások akkor is megmaradtak volna, a /home-ot nem érintette a történet. Inkább a kihívást láttam benne, 20 év hobby Linux használat után meg tudom-e csinálni. Sikerült, örülök neki. :)

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

( viraghj v | 2021. 03. 14., v – 19:24 )

Csak kíváncsiságból kérdezem:

sync; dnf system-upgrade reboot

Kell az a sync a dnf előtt? Magától nem csinál meg a dnf ilyeneket a reboot előtt?

Persze meg lehetne nézni a kódot - ennyi látszik elsőre a system_upgrade.py-ban:

def reboot():
   if os.getenv("DNF_SYSTEM_UPGRADE_NO_REBOOT", default=False):
       logger.info(_("Reboot turned off, not rebooting."))
   else:
       Popen(["systemctl", "reboot"])

Csak azért kérdezem, mert a  halt, poweroff, reboot (amik symlinkek a systemctl-re)  közös manuál oldalán direkt szerepel egy opció:

-n, --no-sync
          Don't sync hard disks/storage media before halt, power-off, reboot.

Nyilván ezen opció nélkül mindegyik csak szinkronizálás után állítja le a gépet.

Amúgy az óvatosság sose árt ;-) A régi szép Unixos/linuxos időkből még ott az ujjaimban a

sync; sync; reboot

 

Úgy vagyok vele, sokkal hamarabb beírom, hogy sync, mint visszabogarászom doksiból vagy forráskódból. Frissítés után is kiadom a sync parancsot, pedig gondolom, ő is megcsinálja, de véletlenül se legyen az új csomagok fele a disk cache-ben, amikor meglep egy áramszünet.

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

( end | 2021. 03. 15., h – 12:05 )

Frissítesz, és nincs előtte egy klónod a rendszerről,..? - (Még Windows-nál sem merem ráengedni e nélkül a funkció-frissítéseket. - 100-ból 99-szer baj nélkül zajlik, utólag feleslegesnek tűnik.., - de egyetlen egyszer nem csinálod meg, jön a "fekete leves" és mindjárt nagy szükség lenne egy mentésre. :)  Legalább egy CloneZilla-t megérdemelne a dolog, - persze a backup-eszközt a fájl-rendszer függvényében.)

( locsemege v | 2021. 03. 15., h – 22:39 )

Selinuxos problémát elhárítottam. Nem ment az incrond, viszont néhány scriptem használja, így engedélyeztem és elindítottam. Fogalmam sincs, mitől került tiltott állapotba. Az autostart scriptemben figyelek arra, hogy csak akkor indítsam az audio alkalmazásokat, ha már megy a pipewire. Nem, mintha erre feltétlen szükség volna. Ebben a scriptemben volt egy bug, javítottam, így már elindul automatikusan az audacious. Ez a bug nem azért került bele, mert elnéztem valamit, hanem a pipewire annyira változékony még, hogy a scriptem nem követte le a változásokat.

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

( viraghj v | 2021. 03. 17., sze – 12:14 )

 

Itt https://blogs.gnome.org/uraeus/2021/03/15/what-to-look-for-fedora-works…

azt írják a PipeWire újdonságairól:

... PipeWire as most of you know is the engine we use to deal with handling video streams in a secure and shareable away in Fedora Workstation, so when you interact with your web camera(s) or do screen casting or make screenshots it is all routed and handled by PipeWire. But in Fedora Workstation 34 we are aiming to also switch to using PipeWire for audio, to replace both PulseAudio and Jack. ...

Mi látszik mindebből az F34-ben?

Nekem a pipewire nem újdonság, mert Fedora 33 alatt is használtam. Írtam is blogot róla itt. Kép átvitelére nem használom, például azért, mert nincs webkamerám, illetve a kis notebook-on van, de nem igazán érintett meg a manapság már-már kötelező exhibicionizmus. :)

Hang esetében azért kellett nekem, mert a pulseaudio zabálja az erőforrásokat, s VoIP klienssel használhatatlanul töredezett a pulseaudio hangja, gyakori volt a buffer underrun.

Nagyon szeretem a pipewire-t, kevés CPU időt eszik, valóban van pulse, alsa, jack interface-e, s ez nyilván egyszerre használható a különböző kliensek részéről. Ugyanakkor a fejlesztés gyakran regresszióba torkollik. Például volt olyan, hogy jól működött minden, majd egy adott build-től kezdve az alsa kliensek amikor lezárták a stream-et, az utolsó buffer ciklikusan play állapotban maradt. Tehát kb. az utolsó 20 ms ismétlődött, így lényegében berregett. Ennek a debugolásában segítettem Wim Taymansnak, kijavította a bugot, meg is köszönte a segítséget.

A másik szörnyűség a bluetooth, mert nem egy egyszetű műfaj. Különféle audio profilok vannak, a csatlakozás egy állapotautomata állapotain való végiglépkedés. Ez is volt, amikor kevesebbet tudott, de működött. Részben az én nyafogásomra konfigurálhatóvá tették, hogy mely kodekeket használhasson. Ez workaround, mert a mikro hifim tud AAC-t és SBC-t, viszont ha AAC-vel próbálkozik, eltéved az állapotautomata és nem csatlakozik. Ami rosszabb, bezavarja egy olyan állapotba a mikro hifit, hogy ott is másik üzemmódra kell kapcsolni, majd vissza bluetooth-ra, azaz kell reinit, hogy menjen SBC-vel.

Ha tiltom az AAC codec használatát, akkor korábban jó volt, most SBC-vel is határeset. Az történik, hogy megpróbálja felépíteni a linket, aztán eldobja, újra próbálja, és így tovább, végtelen ciklusban. Ha csatlakozni akarok, akkor kellően ügyesen, jó ütemérzékkel a blueman kliensen nyomok egy disconnect-et, majd kisvártatva egy connect-et. Ha túl gyors vagyok, még busy, ha túl lassú, akkor megint bekerül végtelen ciklusba. Ettől eltekintve sikerül csatlakozni. :)

Ugyanakkor azt is látni kell, a bluetooth egy bonyolult állat - épp, mint a tehén :) -, így a fejlesztők sokszor észre sem veszik, hogy baj van, mert azokkal a bluetooth-os eszközökkel, amelyekkel ők próbálnak, nem jön elő a hiba. Szóval ez nagyban függ attól, hogy az a bluetooth eszköz, amelyhez csatlakozik a fedorás gép, hogyan lett implementálva.

Ha lesz időm, erről is csinálok részletes logot és bugreportot. De most épp magam is C-ben programozok, igaz, nem pipewire-t. :) Dolgozom.

Ami még hiányzik, az az echo cancel, de lehet, hogy az megfeleően konfigurált gstreamer kliens pipeline-nal megoldható. Ennek utána kellene olvasni. De az is lehet, hogy lesz hozzá natív implementáció vagy modul.

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

Köszönöm!

Nekem a pipewire nem újdonság, mert Fedora 33 alatt is használtam. Írtam is blogot róla itt.

Nézegettem, csak azt szerettem volna tudni, hogy mi az, ami a Fedora 34-ben az emlegetettekből már "alapból, gyárilag" többé-kevésbé stabilan működik.

Akkor a bluetooth-os fejhallgatót laptoppal még nem erőltetem egy darabig ;-)

Azért nem eszik olyan forrón a kását, akár működhet is. Ma került be bluetooth-os commit több is, illetve Taymans kiadta a 0.3.24-es verziót. Kipróbáltam a notebook-omon, és végre újra egyből csatlakozik a mikro hifimhez. :) Persze nem próbáltam még ki, mi van, ha engedélyezem megint az AAC codec-et, vagy akár az összeset.

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

( locsemege v | 2021. 04. 03., szo – 11:26 )

Szerkesztve: 2021. 04. 03., szo – 11:26

Időközben lefordították: xfce4-notes-plugin-1.9.0-1.fc34

Azért ez az rpm adatbázis széthullás - ami tehát nem a Fedora telepítő hibája, hanem nálam telt be az a filerendszer, amelyen az rpm adatbázis volt - apróbb könnyen megoldható problémákat hagyott maga után.

Az egyik, hogy nem ment az automatikus frissítés. A dnf-automatic csomag valahogy elveszett a nagy kavarodásban, fel kellett telepítenem, illetve engedélyeznem kellett a dnf-automatic-install.timer időzítőt, amely triggereli majd a hasonló nevű *.service-t.

A másik, hogy kiszúrtam, a gép órája késik kb. 20 másodpercet. Ránéztem, tényleg nem volt időszinkron. Erre egy

timedatectl set-ntp 1

parancs volt a megoldás. Érdeklődni így lehet:

timedatectl status

               Local time: Sat 2021-04-03 11:24:58 CEST
           Universal time: Sat 2021-04-03 09:24:58 UTC
                 RTC time: n/a
                Time zone: Europe/Budapest (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

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

( szkaresz v | 2021. 06. 02., sze – 23:19 )

Szerkesztve: 2021. 06. 02., sze – 23:20

Szia!

Nálam vannak hálózati mappák becsatolva  a felhasználói felületbe. Rendszertöltéskor felmountolja az adott helyre. Ha nincs szerverkapcsolat, akkor betonra fagy  a fájlkezelő. mindegy melyik felület (KDE  XFCE...stb) 

Kitaláltam, hogy az fstab fájlban  bind mounttal oldom meg a problémát Fedora 33-nál bejött,  talán egyszer fordult elő még az elején, hogy give root: -tal leállt a rendszertöltés. Érdekes módon  reboot után már nem volt baja. 

Az fstab ezen része így néz ki:

 

#cifs

//192.168.1.x/Volume_1                  /mnt/NAS1              cifs        username=dell,password=xxxx,iocharset=utf8,noperm,vers=1.0         0 0
//192.168.1.x/Volume_2                  /mnt/NAS2              cifs        username=dell,password=xxxx,iocharset=utf8,noperm,vers=1.0         0 0
#ssh mount
apa@192.168.1.x:/homenext /mnt/homenextmount fuse.sshfs x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/user/.ssh/id_rsa,allow_other,default_permissions,uid=1000,gid=100 0 0
#
apa@192.168.1.x:/homeone /mnt/homeonemount fuse.sshfs x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/user/.ssh/id_rsa,allow_other,default_permissions,uid=1000,gid=100 0 0
#
apa@192.168.1.x:/home /mnt/homemount fuse.sshfs x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/user/.ssh/id_rsa,allow_other,default_permissions,uid=1000,gid=100 0 0
#
UUID=352dcb10-16f0-4d12-8a98-94fdc7019502  /home/user/.hdd     btrfs    defaults                    0       0
#bind
#
/mnt/NAS1                               /home/user/NAS1                                      none    bind                        0       0
/mnt/NAS2                               /home/user/NAS2                                      none    bind                        0       0
/mnt/homeonemount/Fényképészet          /home/user/homeone                                   none    bind                        0       0
/mnt/homenextmount/Pictures             /home/user/Pictures                                  none    bind                        0       0
/mnt/homenextmount/balinthazisuli       /home/user/Bálint_Házi_Suli                          none    bind                        0       0
/mnt/homemount/ftp/canon_scan           /home/user/ScanTMP                                   none    bind                        0       0
/home/user/.hdd                          /home/user/1T                                        none    bind                        0       0
/home/user/.hdd/Dokumentumok             /home/user/Dokumentumok                              none    bind                        0       0
/home/user/.hdd/LETOLTESEK               /home/user/LETÖLTÉSEK                                none    bind                        0       0
/home/user/.hdd/Képek                    /home/user/Képek                                     none    bind                        0       0
/home/user/.hdd/Videók                   /home/user/Videók                                    none    bind                        0       0
/home/user/.hdd/Letöltések               /home/user/Letöltések                                none    bind                        0       0
#

 

Frissítettem Fedora 34-re azóta  ezeket a mappákat hébe-hóba felmountolja. 

Amennyiben kiadoma a mount -a parancsot utólag mindet hibátlanul felcsatolja az adott mappába

Azért oldottam meg így pl. a hálózati mappák mountolását, mert így nem fagy bele a fájlkezelő,ha kiesik alóla a hálózat.

A rendszer ssd-n fut és a nagyobb helyet igénylő mappák egy HDD-ről vannak bind mounttal becsatolva.

 

Mi lehet a nyűgje ?

 

Üdv:Karesz

 

 

 

 

 

 

Karesz

Letölthető háttérképek  |  Portréfotók

Bind mount-ot lokális drive-okon én is használok, nálam működik. Másfelől viszont hálózaton nem csinálom. Azt én is tapasztaltam, hogy a thunar megdöglik, ha a céges szerver megosztását felcsatolom, majd elfelejtek umont-olni, de közben bontom a vpn kapcsolatot.

Egyébként az a gyanúm, képezni kellene magunkat:

man systemd.mount

:)

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