Red Hat 7 pont pont pont

Ugy alakult, hogy meg mindig "szeretem" a Linuxot ... mert nincs eleg mas dolog ami gondot okozna...

Mivel a Red Hat nagylelkuen implementalta az XFS V5 FS formatumot tartalmazo Kernelt es XFS progs csomagot ezert ugy dontottunk, hogy updateljuk az egyik szerverunk a teszt kornyezetben aminek neha fel kell dolgoznia XFS V5 FS-t tartalmazo diszkeket...

Gondoltam vegre egy esemenytelen frissites jon ...

yum clean/update utan hiba nelkul lement a frissites. Reboot...

1. Nem indult, grub gond volt:
symbol 'grub_strchrnul' not found

Sebaj ujraindit 7.3 DVD bebootol, grub2-install megoldotta

2. Megint atnevezte a NIC-eket ... ez volt a masodik amikor megtette
Az elso akkor volt amikor ens192/ens224-rol nevezte at eno16780032/eno33559296-re egy Vmware virtual hardware 8->10 frissites utan.
Most pedig csak a 7.3 frissites tortent es visszanevezte ens nevekre.
Mivel relative meguntam az allando varialast megkapta a net.ifnames=0 opciot. Sosem zavart az eth* ellenben a 11-12 karakter hosszu eno annal inkabb ...

3. Egyetlen debug csomag sincs telepitve. Ennek ellenere a 7.3 frissites utan ugy dontott a grub2-mkconfig, hogy jo otlet midnen egyes kernelhez a "with debug" opciot legeneralni es a default boot kernel-t is ilyenne tenni ...

A megoldas:
/etc/sysconfig/kernel
MAKEDEBUG=no
grub2-mkconfig

4. Eltuntek a particio delimiterek (p):
lrwxrwxrwx 1 root root 7 Mar 23 11:31 mpatha -> ../dm-0
lrwxrwxrwx 1 root root 7 Mar 23 11:31 mpatha1 -> ../dm-1
lrwxrwxrwx 1 root root 7 Mar 23 11:31 mpatha2 -> ../dm-2
lrwxrwxrwx 1 root root 7 Mar 23 11:31 mpathac -> ../dm-9
lrwxrwxrwx 1 root root 8 Mar 23 11:31 mpathac1 -> ../dm-12
lrwxrwxrwx 1 root root 8 Mar 23 11:31 mpathac2 -> ../dm-13

Szerencsere ez csak a /boot particio mountolasaban es mas service-ek mukodeseben okozott gondot amik mpathacp1-kent hivatkoznak a particiora...

Egy gyors modositas a "/lib/udev/rules.d/62-multipath.rules" fajlban es reboot utan ez is megoldva...

5. Meg varom, hogy mi mast kell visszaallitanom a frissites elotti allapotra ...

Hozzászólások

A 2esben az a szép, hogy épp az volt az indoklás ezekhez a hányadék nevekhez, hogy ez majd jól stabilan úgy marad, bármit mahinálsz is.

A mahinálást bírja is, csak az a fránya frissítés ugye. Merhogy az nehezen tesztelhető a sok hülye felhasználó sok hülye környezete miatt. bezzeg a rencergarázdáknak mind egyre jár az agya. (Pizza, sör, dudák)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Az elso alkalommal amikor atnevezte a NIC-eket csak VM update volt ... ami azert nem kene ilyet okozzon szvsz... De hat VMware meg virtualizacio meg Linux ...

Majd kivancsisagbol megnezem pontosan mi valtozik a vmx-ben (es OS oldalon) ha a hardware-t updatelem ... most mar kivancsi lettem :)

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInt…

Come again, what good does this do?

With this new scheme you now get:

Stable interface names across reboots
Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place (to the level the firmware permits this)
Stable interface names when kernels or drivers are updated/changed
Stable interface names even if you have to replace broken ethernet cards by new ones
The names are automatically determined without user configuration, they just work
The interface names are fully predictable, i.e. just by looking at lspci you can figure out what the interface is going to be called
Fully stateless operation, changing the hardware configuration will not result in changes in /etc
Compatibility with read-only root
The network interface naming now follows more closely the scheme used for aliasing block device nodes and other device nodes in /dev via symlinks
Applicability to both x86 and non-x86 machines
The same on all distributions that adopted systemd/udev
It's easy to opt out of the scheme (see below)

szóval ja, az ígéret az volt, hogy nem nagyon. Nyilván, ha a vm update valamit nagyon alátúrt, akkor fog változni, de igazából az derül ki, hogy előrébb in practice nem lettünk, de legalább rondák a nevek :)

Idézet ugyanonnan:


The following different naming schemes for network interfaces are now supported by udev natively:


1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
4. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
5. Classic, unpredictable kernel-native ethX naming (example: eth0)

Szerintem annyi történt, hogy a virt. hardver frissítése után az elnevezés valamiért a negyedik séma alapján generálódott.

A lenyeg, hogy semmivel sem konnyitette meg az eletet az uj sema ...
Szamomra az eno/ens/enp/enx nevek inkabb unpredictable mint az ethX ami megjosolhatoan eth es egy szam.

Remelem egy nap eljut oda a Linux is, hogy vegre a developerek megertik ha minden egy verzioval feltalaljak a spanyolviaszt azzal nem jutnak elorebb. Vasokol kene es teljesen szabalyozott keretek a fejlesztoknel. Legalabb a a magukat enterprise-nak mondott OS eseten... Bar a Linuxnak annyi koze van az enterprise-hoz mint rokanak a repuleshez ...

>Megint atnevezte a NIC-eket

2.4 megint not affected