Az Ubuntu tud valamit...

Bedőlt két Ubuntu szerverem, frissítettem, és onnantól elszáll valami boot-kor, és nincs diszk (Virtuális, Hyper-V alatt). Nem gond, ezt a kettőt nem nagyon használják, (a másik hármat nem bántom).
Letöltöttem a 18.04 szerver beta2-t, nézzük meg azt.
Megkérdezi, milyen nyelven szeretnék kommunikálni. Kiválasztom a Magyart. Következő oldal: cirill betűk, és (gondolom) orosz nyelvű szöveg.

( asch v | 2018. 04. 23., h – 16:53 )

Paks2 titkos záradéka volt, hogy a magyar nyelvű Ubuntu 18.04 cirill betűkkel szólaljon meg!!!444!!

( zeller | 2018. 04. 23., h – 22:20 )

A virtuális diszkhez a modult belerámolta az initrd-be? Bootolj a régi kernel+initrd-vel, aztán nézd össze a régi meg az új initrd tartalmát.

Nem modul hiányának tűnik. Elszáll betöltéskor, egy "Oops" után kiírja a CPU regisztereket.
Anno valami hasonló miatt álltam át Redhat-ról Ubuntura. Frissített a Redhat, és az új verzióhoz új támogató sw. kellet, de mivel nem volt rendszer diszk csak kb. 1 percig, nem lehetett installálni az Ms. frissítést. Az Ubuntuval jó pár évig nem volt semmi baj.

Hogyan? 25 soros képernyőmentésenként nem szeretném. Volt egy olyan ötletem, hogy a dmesg kimenetét kiküldöm a COM1/ttyS0 -ra, amit a Hyper-V át tud irányítani egy named pipe-ba (másba nem, mert minek, az túl egyszerű lenne). Igen ám, de mit kezdhetek egy named pipe-pal? Semmit nem találok arra, hogy hogyan tudnám egy fájlba írni. Annyira nem izgat fel a dolog, hogy programot írjak, meg akármit nem installálnék a más által adminisztrált Hyper-V fürtre sem.

OK. Bár szánalmasan szar módszernek tartom, 25x80-as képernyők fotózását, ám legyen. Különösen úgy ciki (szerintem) az egész, hogy ha a pipe a windows-ban kompatibilis lenne a fájl-lal (mint néhány a Windowsnál kezdetlegesebb rendszerben, ahol más fel sem merül) akkor ennek a kimenetnek a mentése két mozdulat lenne, akkor pedig ha fájlba is mehetne a COMx akkor egy mozdulat, de én valószínűleg nem érek fel a Microsoft magaslataiig.
Két screent- mentettem le a http://svn.kkfk.bgf.hu/html/ mappába (scr1.png és scr2.png).
Csak hogy kiegyenlített legyen a pampogásom:
A 18.04-ben újra, a hagyományokhoz híven nem azon dolgoztak, hogy a meglévő módszereket finomítsák, javítsák, hanem inkább amit lehet lecserélnek. Csak hogy a kedves rendszergazdák el ne tunyuljanak, és a programozóknak is legyen egy kis kihívás.
Bár az IPV6-ot szolgáltatói szinten gyakorlatilag szabotálják, azért Ubuntuéknál nyomják rendesen. Az új verzióban az összes eddigi lehetőséget sikerült hatástalanítani, ami arra szolgált, hogy letiltsuk az IPV6-ot. Edéig 4 módon tiltottam le, de csak azért is van IPV6, és van olyan szolgáltatás ami IPV4-en nem hallgatózik, mert minek, ha van IPV6.

A sysctl.conf -ban hiába tiltottam le, igaz csak a default és all -t, konkrétan az eth0 és eth1 -et nem. De akkor mi a fene az all, meg a default?
Valahol írták, hogy az ipv6 modult is tehetem feketelistára, na az sem használ.
A kernel paraméter (ipv6.disable=1) pedig azért nem használt, mert a GRUB_CMDLINE_LINUX_DEFAULT változót én a /etc/default/grub -ban írtam át, de az csak csali volt az amatőröknek, az igazi érték a /etc/default/grub.d/50-curtin-settings.cfg -ben lehet (hacsak nem az is csali :), mindjárt kipróbálom.

Nem tudom olvastad-e amire válaszoltál.
A DEFAULT -osat írtam át, csak két helyen szerepelt az értékadás, én az elsőben írtam át, a második meg felülvágta a módosítás nélküli értékkel. Az első értékadás felesleges, érdektelen, ezt neveztem csalinak. Nálam volt /etc/default/grub.d/ könyvtár, bizonyára (nem túl sikeres) újítás.
Tehát most nem a DEFAULT nélküli sor van módosítva, és működik.
Persze ettől még lehet neked is (részben) igazad, és ha a DEFAULT nélkülit írom át akkor is jó lesz, de annyira nem izgat a téma, hogy ki is próbáljam.

Mondom: nálam nincs grub.* könyvtár, ami lehet az upgrade következménye vagy azé, hogy ez szerver változatként települt anno.

Egyébként igazad lehet: rosszul emlékeztem a két paraméter (default/nem default) közti különbségre, nálam valószínűleg működne a *_default-ra is.

Csak egy gyors tipp. Nem tudom, hogy a /boot partició mekkora méretű (ha default akkor 500MB), és nekem már csinált olyat, hogy a folyamatos kernel update-ek megemésztettték a tárhelyet és a legutolsó kernel már csak töredék kernel lett és hasonló hibával szállt el boot-oláskor. Elindítottam a régi kernellel, leszedtem a felesleget, csináltam helyet és utána upgradeltem és bootoltam a legfrissebb kernelre.

Igen, ha van külön boot kötet, akkor rendszeresen elfogy a hely a kötetben, ha nem figyelünk oda. Már rutinom van ennek elhárításában, köszi.
Az egyik bedőlt gépen volt ilyen hiba, elhárítottam, a másikon nem volt ilyen probléma. Mindkettő ugyanúgy dőlt össze a végén.
Arra gondolok, hogy a 32 bites támogatásnál lehetett valami bibi, azok kezdenek kihalni, csak 512M memóriához az tűnt jó választásnak.

( GerzSonka | 2018. 04. 24., k – 17:41 )

Barcelonában nyaraltunk, a kijelentkezésnél a recepciós látta, hogy Budapestre megyünk vissza, így közölte, hogy спасибо. :)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

( csfeco | 2018. 04. 25., sze – 11:31 )

Még egy kis pampogás az Ubuntu-ra (a nyelvi témától már úgyis eltértünk).
Beállítottam rajta az SNMP daemon-t, Hogy a nyilvántartó programba egyszerűbb legyen beállítani a node-ot.
És újra csak csesszék meg az SNMP-t akiknek köze van ahhoz, hogy olyan amilyen!!!!!!!!
A lekérdezés riportjának egy darabja:
Port #2 "Microsoft Corporation Device 0003" (ethernet) 00:15:5D:00:04:2B 172.20.0.4
Port #3 "Microsoft Corporation Device 0003" (ethernet) 00:15:5D:00:04:2C 172.20.48.1
Mint jól látható a két port név azonos, ami érthetően nem tetszik az adatbázisnak (nekem se), nem is hagyja menteni.
Linuxék háza táján rádöbbentek, hogy az ifDescr az nem is igazán a port neve, a név az ugyanis az ifName. Mondhatnánk, hogy igazuk van, csakhogy szinte mindenki interfész névnek használja az ifDescr-et, és a bónusz, hogy ifName nem minden eszközön van.
Ergo a nyilvántartó rendszeremen írhatom át az SNMP lekérdezést, hogyha táblázatot kérek, akkor nyugodjon bele abba ha egy oszlop hiányzik. Vagy kérdezzem le az ifName-t külön. Aztán döntsem el mi is valójában a név. Végül is nem gond, az összes SNMP lekérdezés tele van kivételekkel a gyártók egyedi hülyeségei miatt, eggyel több vagy kevesebb... Hol van ez még az LLDP lekérdezés totális káoszához képest.
Vegyük tudomásul, az SNMP a profik eszköze, amatőrök inkább ne használják! Valamiből a profiknak is meg kell élnie.

( csfeco | 2018. 04. 25., sze – 12:12 )

És még egy kis pampogás (csak a jobbakból):
Kicserélném a jelenlegi Ubuntu 16-04 -es isc-dhcp-server-rel működő DHCP szervert, 18.04 -re és isc-kea -ra.
A friss ropogós Ubuntu 18.04 az 1.0.1 -es isc-kea csomagot tartalmazza, gondolom évek múlva is, amíg a 18.04 támogatott.
Az isc-kea aktuális verziója 1.0.3, az 1.0.2 támogatott verzió, az 1.0.1 pedig idézem: "Deprecated as of December 2017".
A kea csak forrásban tölthető le (vagy rosszul kerestem), egy éles DHCP/DNS szerveren mindig jól mutat egy fejlesztő rendszer, ja és így jól frissíthető, karbantartható, vagy éppen nem.

Attól mert valaki tartózkodna a (régóta) nem támogatott verzióktól, még nem hiszem, hogy verzió fétises lenne.
És akkor még nem beszéltünk arról mennyire tekinthető modernnek az isc-dhcp-server, és ha nem az, akkor mire vártak a kea-val (legyünk pozitívak, és a kea-t tekintsük modernnek).

Ha tényleg az 1.0.1-et(?) tartalmazza, az valóban gáz - szerintem 1.1.0-ra gondolsz, ahogy a legfrissebbnél is 1.3.0-ról van szó :-)
A kea-ból CentOS7-ben is 1.1.0 van (epel repó), de úgy állok hozzá, hogy a verziószám csak n darab szám vagy épp betű - a kérdés az, hogy a bugfixeket visszaportolják-e, illetve ha az eredeti fejlesztő "elengedi" az adott verzió támogatását, a disztribúcióban lévő csomag karbantartója viszi-e tovább, vagy azt mondja, hogy verziót vált, és az újra cseréli a disztribben lévő csomagot.
Erre eklatáns példa a RHEL6 és az rsyslog esete: ott emlékeim szerint az 5-ös rsyslog volt a default, (rsyslog nevű csomag), és "nőtt" mellé egy rsyslog6 meg később egy rsyslog7 csomag is, amikre némileg trükkösen, de lehetett frissíteni yum shell használatával.