[UBK dev] isóteszt

[Kiss Attila]

2019-10-09 13:21 keltezéssel, Kiss Attila írta:
>
>
> 2019-10-09 09:44 keltezéssel, Kiss Attila írta:
>> Nem a shadow, hanem a getty lehet csak a hibás, ő nem működik 
>> megfelelőn. Ő lenne e beléptető mindenhol. 
>
> Tévedés, meglesz az ok!
>
> A getty (fbgetty, agetty)  a man lap szerint a shadow /bin/login -t 
> hívná meg, de most a /bin likvidálása után UBK3 esetén csak 
> /usr/bin/login van.
> Ez a /bin/login biztosan bele van drótozva a getty forrásába.
> A fbgetty már oly régi, hogy akkor még systemd sem volt!
>
Sajna egy shadow visszafejlesztés az ubk2 verzióra sem hozta meg a 
belépési lehetőséget.
Nem lehet belépni az amúgy működő rendszerbe, így logokat sem lehet 
nyerni. Minden a RAM-ban zajlik...

Valós felhasználót begépelve azonnal visszajön az usernév váró prompt, 
nem létezőt megadva ellenben jelszóbekérés is van, ami persze 
eredménytelen és visszajön az usernév bekérő prompt.
Ha a systemd getty at .service fájlban visszaírom az eredeti agetty -re a 
fbgetty -t, ugyanez van, csak rondább a konzolon a beléptető.

Az isón lecserélve generáláskor a valós /bin és /sbin mappákat linkekre, 
melyek a /usr/bin, illetve a /usr/sbin alá mutatnak, éppúgy elindul az 
isó, javulás, romlás nincs.
Failed service nincs, csak a dracut részben az iscsi banda piroslik, de 
a root fájlrendszerre történt átváltás után már az is szépen indítható.
Nem single módban indítva egyetlen failed service sincs, minden zöld, 
majd megjelenik az sddm grafikus beléptető, de persze UHU beléptetése 
nem sikerül.
Ctrl+Alt+Fx billentyűkre megjelenik a megfelelő virtuális konzol, ahol 
szintén lehetetlen a belépés.
A Ctrl+Alt+Del -re szépen sorjáznak a zöld systemd rendszer leállítási 
üzenetek, majd újraindul.

Nagyon sötét ez az ügy, igen nehezen és időigényesen lehet kideríteni az 
okot, szinte csak találgatni lehet.

Lehet hogy PAM nyűg?