[ROZWIĄZANY] Awaria systemu po przekopiowaniu plików passwd, shadow, group

[Pawel1995]

Cześć, z starego serwera skopiowałem poleceniem scp pliki  passwd, shadow, group(pliku gshadow nie było).
Tą sama metodą wkleiłem pliki na nowy serwer:

Kod [Zaznacz] Rozwiń

scp "C:\Users\pawel\Desktop\konfiguracja\*" root@192.168.11.161:/etc/
W w/w folderze "konfiguracja" mam tylko te trzy pliki i nic wiecej.

Zanim zresetowałem komputer hasło root'a juz działało takie jak na starym serwerze.

Niestety po "sudo reboot" system sie nie uruchamia...

Pytanie czego zapomniałem albo co zrobiłem źle?
Juz kilkanaście razy instaluje openSUSE... a to dalej nie wchodzi.
Bo po każdej próbie robie format, gdyż nie umiem naprawić systemu. Po uruchomieniu jest migająca kartka na ekranie i nic sie nie dzieje.

[microsofter]

Skopiowanie plików nie jest powodem awarii systemu. Świadczy o tym fakt pomyślnego logowania na nowe-stare hasło. Szukaj przyczyny gdzie indziej.

pliku gshadow nie było

ma nie być

[Pawel1995]

Nie wiem co sie stało, ale rozwiązaniem problemu było:

Przy starcie systemu wybrałem "Start bootloader from a read-only snapshot" i tam dopiero openSUSE.

Nie wiem co to naprawia, ale zadziałało.

[Pawel1995]

Generalnie jest nadal problem że jak nie daję "Start bootloader from a read-only snapshot" tylko normalnie to dalej mi sie nie uruchamia.

Czy problemem moze być że system był instalowany z użytkownikiem admin do którego sie system logował automatycznie.
A w "nowym" passwd juz tego uzytkownika nie ma?

[microsofter]

Kij wie. Jeśli distro jest porządnie zrobione, to nie powinno. Nie eksperymentuj, tylko wyłącz automatyczne logowanie. Niech system pyta o login, sam się przekonasz czy brak konta admin coś przeszkadza czy nie.

[Pawel1995]

Niestety cos się pokrzaczyło i teraz juz nawet przez "Start bootloader from a read-only snapshot" nie działa...
Na szczęście mozna sie łaczyć przez ssh do komputera.

zmieniłem za pomocą yast2 ten autologin, o dziwo dalej w "/etc/sysconfig/displaymanager" było DISPLAYMANAGER_AUTOLOGIN="admin", ale zmieniłem ręcznie.

Znalazłem w "journalctl -b0 -p3" takie coś:

Kod [Zaznacz] Rozwiń

Jan 04 12:51:46 localhost systemd-udevd[696]: /usr/lib/udev/rules.d/50-udev-default.rules:39 Unknown group 'render', ignoring
Jan 04 12:51:46 localhost systemd-udevd[696]: /usr/lib/udev/rules.d/50-udev-default.rules:40 Unknown group 'render', ignoring
Jan 04 12:51:46 localhost auditd[737]: Group ID is non-numeric and unknown (audit) - line 8
Jan 04 12:51:46 localhost systemd[1]: Failed to start Security Auditing Service.
Jan 04 12:51:47 localhost systemd-udevd[798]: could not read from '/sys/module/pcc_cpufreq/initstate': No such device
Jan 04 12:51:48 localhost kernel: kvm: disabled by bios
Jan 04 12:51:48 localhost kernel: kvm: disabled by bios
Jan 04 12:51:48 localhost kernel: kvm: disabled by bios
Jan 04 12:51:48 localhost kernel: kvm: disabled by bios
Jan 04 12:51:48 localhost kernel: kvm: disabled by bios
Jan 04 12:51:48 localhost kernel: kvm: disabled by bios
Jan 04 12:51:49 localhost kernel: kvm: disabled by bios
Jan 04 12:51:49 localhost kernel: kvm: disabled by bios
Jan 04 12:53:07 localhost postfix/postmap[1722]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 12:53:08 localhost postfix/postmap[1725]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 12:53:09 localhost postfix/postmap[1727]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 12:53:10 localhost postfix/postmap[1729]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 12:53:11 localhost postfix/postmap[1731]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 12:53:12 localhost postfix/postmap[1733]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 12:53:13 localhost postfix/postmap[1735]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 12:53:14 localhost postfix/postmap[1738]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 12:53:15 localhost postfix/postmap[1740]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 12:53:16 localhost postfix/postmap[1747]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 12:53:18 localhost postfix/postalias[1749]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 12:53:20 localhost postfix[1754]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 12:53:22 localhost systemd[1]: Failed to start Postfix Mail Transport Agent.

CO mogło sie zepsuć jak to naprawić?


Edit:
po zmianie w BIOS -> Intel (R) Virtualization Technology -> na enable to zastałem:

Kod [Zaznacz] Rozwiń

Jan 04 13:07:01 localhost systemd-udevd[695]: /usr/lib/udev/rules.d/50-udev-default.rules:39 Unknown group 'render', ignoring
Jan 04 13:07:01 localhost systemd-udevd[695]: /usr/lib/udev/rules.d/50-udev-default.rules:40 Unknown group 'render', ignoring
Jan 04 13:07:02 localhost auditd[731]: Group ID is non-numeric and unknown (audit) - line 8
Jan 04 13:07:02 localhost systemd[1]: Failed to start Security Auditing Service.
Jan 04 13:07:08 localhost kernel: snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x0143a000
Jan 04 13:08:18 localhost postfix/postmap[1467]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 13:08:19 localhost postfix/postmap[1566]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 13:08:20 localhost postfix/postmap[1568]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 13:08:21 localhost postfix/postmap[1594]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 13:08:22 localhost postfix/postmap[1728]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 13:08:23 localhost postfix/postmap[1732]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 13:08:24 localhost postfix/postmap[1777]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 13:08:25 localhost postfix/postmap[1793]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 13:08:26 localhost postfix/postmap[1795]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 13:08:27 localhost postfix/postmap[1797]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 13:08:28 localhost postfix/postalias[1799]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 13:08:30 localhost postfix[1801]: fatal: parameter inet_interfaces: no local interface found for ::1
Jan 04 13:08:32 localhost systemd[1]: Failed to start Postfix Mail Transport Agent.

[microsofter]

Pas. Pierwszy raz widzę coś takiego. Tu potrzeba kogoś znającego to distro.
Na twoim miejscu, zainstalowałbym system od nowa, a następnie powtarzał te same kroki co wcześniej, ale pojedynczo. Tak można wyizolować przyczynę problemu. Jeśli faktycznie importowanie kont rozwala system, rozważ odtworzenie ich ręcznie, od podstaw. O ile nie ma dużo użytkowników, zajmie to mniej czasu, niż kolejna reinstalka. Powodzenia.

[pavbaranov]

Wiem, że nic nie wiem, ale się wypowiem :)
Próbujesz zgwałcić system. Stawiasz od nowa, ale przenosisz jakieś cząstki rzeczy z poprzedniego. To się zwykle nie udaje. Na początek widać, że nie masz jakiejś grupy "render". Nadto mnóstwo różnych błędów i w dodatku to jest chyba maszyna wirtualna postawiona na - chyba - Windows. Pytanie proste: szukamy rozwiązania, czy stawiasz system od nowa. W pierwszym przypadku - maksymalnie dużo informacji od Ciebie. Jakich? Wszystkie! :D

[Pawel1995]

Generalnie duzo już zrobiłem, zanim odpowiem na pytanie to podsumuje co juz mam:

Pogrzebałem jak w/w pisałem w ustawieniach BIOSu z tego poradnika:

Kod [Zaznacz] Rozwiń

https://askubuntu.com/questions/303164/what-does-the-kvm-disabled-by-bios-message-during-the-boot-process-mean

Udało mi sie zmienić tego usera z tego poradnika:

Kod [Zaznacz] Rozwiń

https://www.simplified.guide/suse/disable-auto-login-yast

A teraz(nowy sukces) zmieniłem ustawienia postfixa z tego poradnika:

Kod [Zaznacz] Rozwiń

https://nixhive.com/fatal-parameter-inet_interfaces-no-local-interface-found-for-1/
tyle że net_interfaces zmieniłem właśnie na "all", bo wcześniej było "localhost" i nie działało.

Teraz już osiągnąłem taki stan rzeczy:

Kod [Zaznacz] Rozwiń

Jan 04 15:36:22 localhost auditd[716]: Group ID is non-numeric and unknown (audit) - line 8
Jan 04 15:36:22 localhost systemd[1]: Failed to start Security Auditing Service.
Jan 04 15:36:22 localhost systemd-udevd[696]: /usr/lib/udev/rules.d/50-udev-default.rules:39 Unknown group 'render', ignoring
Jan 04 15:36:22 localhost systemd-udevd[696]: /usr/lib/udev/rules.d/50-udev-default.rules:40 Unknown group 'render', ignoring
Jan 04 15:36:24 localhost systemd-udevd[820]: could not read from '/sys/module/acpi_cpufreq/initstate': No such device

Odpowiadając na pytanie: Zastanawiam sie na stabilnością tej dystrybucji, bo ma złe chwila zawiasy, ale o tym mysle dam osoby wątek czy zainstalować tu coś innego.

Moim zadaniem jest postawić ten serwer z sambą, gitea i www. Poprzednio był postawiony openSUSE Leap 15.0 ja postawiłem openSUSE Leap 15.3, myślałem że migracja będzie bez "gwałtu" to to w końcu to samo distro tylko wyższa wersja(czy czegos nie rozumiem z słowem "distro"?).

Ten sam "gwałt" będę musiał zrobić kopiując sambe i jej konfiguracje i pliki właściwe. Myślałem że tak będzie dużo szybciej, zwłaszcza że tych użytkowników jest ponad 30 + 50 jakiś użytkowników systemowych, oraz niecałe 10 grup + 60 systemowych, gdzie jakiego użytkownika do jakie grupy to nie jest oczywiste.


Odpowiadając: jeszcze mam siły żeby go jeszcze raz sformatować i jeszcze raz zgwałcić, tylko na chwilę obecna nie wiem na ile to będzie miało sens, bo najpewniej wyskoczy ten sam błąd(wykonałem na tym systemie tylko kilka kroków, tam nie miało sie co zepsuć!).

Jakimi informacjami moge cie obdarować? journalctl -b0 -p3 juz dałem. 

[pavbaranov]

Żurnal, to żurnal. Ot, dziennik. Stąd pytanie o... wszystko. Na czym stoi, jak instalowane itp. itd.
Wg mnie - to co robisz, czy chcesz zrobić - jest kompletnie postawione na głowie. Próbujesz od nowa postawić system (tu Leap 15.3) i "wkopiować" weń wersje jakichś plików konfiguracyjnych z dotychczasowego 15.0. Nie jestem serwerowcem. Daleko mi do tego. Niemniej jednak przeżyłem kilkadziesiąt chyba dystrybucji i ich aktualizacji oraz przenoszenia. Według mnie - na nowym komputerze należy przenieść 1:1 stary serwer, a następnie dokonać aktualizacji z 15.0 do 15.3. Nie wiem, czy jest możliwa "skokowa", czy też musisz to wykonać w trzech krokach. Zwykle jednak, jedynie taka aktualizacja systemu daje jakąkolwiek gwarancję prawidłowej pracy.

[Pawel1995]

Za twoją radą zainstalowałem jeszcze raz system, tyle ze openSUSE Leap 15.0

System stoi na:
- i7-6700
- MAXIMUS VIII RANGER
- 32GB RAM
Został wykonany na tej płycie RAID 1 [mirror].

Kroki instalacji:
1. Instalacja systemu
2. Instalacja LXTerminala(dla wygody) -> [sudo zypper install lxterminal]
3. Instalacja ifconfig -> [sudo zypper install net-tools-deprecated]

ssh już nie musiałem odblokowywać bo zrobiłem to podczas instalacji punktu 1.

I wykonałem :
scp "C:\Users\pawel\Desktop\konfiguracja\*" root@192.168.11.161:/etc/
gdzie w katalogu "konfiguracja" były passwd, shadow, group uprzednio skopiowane z starego serwera.

Trochę sytuacja sie zmieniła, bo teraz "journalctl -b0 -p3" pokazuje:

Kod [Zaznacz] Rozwiń

Jan 05 12:13:39 linux-6zf2 systemd-udevd[357]: inotify_add_watch(8, /dev/sda2, 10) failed: No such file or directory
Jan 05 12:13:39 linux-6zf2 systemd-udevd[326]: inotify_add_watch(8, /dev/sda1, 10) failed: No such file or directory
Jan 05 12:13:39 linux-6zf2 systemd-udevd[322]: inotify_add_watch(8, /dev/sda4, 10) failed: No such file or directory
Jan 05 12:13:39 linux-6zf2 systemd-udevd[363]: inotify_add_watch(8, /dev/sda3, 10) failed: No such file or directory
Jan 05 12:13:40 linux-6zf2 systemd-udevd[322]: inotify_add_watch(8, /dev/sdb4, 10) failed: No such file or directory
Jan 05 12:13:40 linux-6zf2 systemd-udevd[326]: inotify_add_watch(8, /dev/sdb1, 10) failed: No such file or directory
Jan 05 12:13:40 linux-6zf2 systemd-udevd[363]: inotify_add_watch(8, /dev/sdb3, 10) failed: No such file or directory
Jan 05 12:13:40 linux-6zf2 systemd-udevd[357]: inotify_add_watch(8, /dev/sdb2, 10) failed: No such file or directory


Dalej mamy ten sam problem, miga karetka, brak pulpitu, ale jest dostęp przez ssh.
Tyle że po zainstalowaniu openSUSE Leap 15.0, juz mam inne błędy.

[pavbaranov]

Dalej z moim zastrzeżeniem: nie jestem serwerowcem.
To:

scp "C:\Users\pawel\Desktop\konfiguracja\*" root@192.168.11.161:/etc/

wygląda jakbyś próbował przekopiować coś z windowsowego katalogu na serwer linuksowy.
Mniejsza o to - błędy. Masz w systemie wykonywaną usługę systemd o nazwie systemd-udevd, która najwyraźniej odwołuje się do dwu urządzeń blokowych (/dev/sda i /dev/sdb), na których są po 4 partycje. Tych dysków w systemie systemd-udevd nie może znaleźć. Po prostu ich nie widzi.
Nie wiem, czy w "C:\Users\pawel\Desktop\konfiguracja\" masz wyłącznie pliki, o których wspominasz, ale coś mi tu nie pasuje. Pliki passwd, shadow, group w ogóle nie dotyczą podpięcia urządzeń blokowych (/dev/sda i /dev/sdb). Problem musi zatem gdzieś istnieć przy samej instalacji. Dyskiem jest jakiś RAID, ale co to - nie wiemy. Czy sprawdzałeś, czy ten rodzaj ma wsparcie w tym kernelu, który jest w Leap 15.0/15.3? Jeśli dobrze widzę (distrowatch), to w 15.0 kernel jest w dość starej już wersji 4.12.14, a w 15.3 w wersji 5.3.18. Obie dość dawno temu straciły już wsparcie ze strony deweloperów kernela. Jeśli zatem masz niewspierane przez kernel urządzenie blokowe, a zespół od SUSE nie przejął tych kerneli i nie wprowadził do nich obsługi nowszych urządzeń we własnym zakresie, to może to być prawdopodobną przyczyną problemów. Skoro ten komputer jest niemal jeszcze dziewiczy, to może czas się pobawić i spróbować, czy np. pozostając przy Otwartej Zuśce, wersja Tumbleweed (tak, wiem, że rolling release na serwer jest średnio polecane, ale nie o to chodzi) spowoduje, że urządzenia sda i sdb będą widoczne. Tu masz aktualną wersję kernela, czyli 5.15.12.
Z drugiej strony może to być ślepa uliczka, albowiem zerknij co spece od serwerów (Oracle) twierdzą o pojawiającym się u Ciebie błędzie: https://docs.oracle.com/cd/E52668_01/E66514/html/ceph-issues-24716988.html

[Pawel1995]

The error is harmless and can be ignored, as the OSD operation completes correctly.

Błąd można zignorować? Czyli mogę się tym nie przejmować, chociaż szkoda żeby na "dziewiczym" serwerze ten błąd wisiał od poczęcia.

To co mówisz o RAID to raczej jest prawda, bo jak przekopiowałem stare pliki passwd, shadow i group to pulpit wystartował normalnie, a ten błąd w journalctl pozostał.

scp użyłem najpierw do skopiowania plików passwd, shadow i group z starego serwera, na windowsa, dlatego tak to wygląda.

Więc jeżeli nie chcę tych błędów to muszę zrezygnować z openSUSE Leap 15.0?
Na Leap 15.3 przynajmniej tego błędu nie było, za to były inne, które być może wynikały z złej instalacji.

Jeżeli chodzi o same pliki passwd, shadow i group to pulpit startuje na starych, a nie startuje na nowych, trochę tego nie rozumiem...
Czy ich wyłącznym zadaniem nie jest trzymanie loginów haseł i grup użytkowników?

Przebadałem sobie wszystkie różnice dla użytkowników systemowych w passwd i znalazłem takie:

Kod [Zaznacz] Rozwiń

lightdm:x:466:469:LightDM daemon:/var/lib/lightdm:/bin/false
lightdm:x:457:461:LightDM daemon:/var/lib/lightdm:/bin/false
nscd:x:473:475:User for nscd:/run/nscd:/sbin/nologin
nscd:x:471:473:User for nscd:/run/nscd:/sbin/nologin
polkitd:x:470:473:User for polkitd:/var/lib/polkit:/sbin/nologin
polkitd:x:466:470:User for polkitd:/var/lib/polkit:/sbin/nologin
sshd:x:469:472:SSH daemon:/var/lib/sshd:/bin/false
sshd:x:464:468:SSH daemon:/var/lib/sshd:/bin/false
statd:x:471:65533:NFS statd daemon:/var/lib/nfs:/sbin/nologin
statd:x:468:65533:NFS statd daemon:/var/lib/nfs:/sbin/nologin
systemd-coredump:x:479:479:systemd Core Dumper:/:/sbin/nologin
systemd-coredump:x:477:477:systemd Core Dumper:/:/sbin/nologin
systemd-network:x:477:477:systemd Network Management:/:/sbin/nologin
systemd-network:x:478:478:systemd Network Management:/:/sbin/nologin
systemd-timesync:x:478:478:systemd Time Synchronization:/:/sbin/nologin
systemd-timesync:x:479:479:systemd Time Synchronization:/:/sbin/nologin
tftp:x:472:474:TFTP account:/srv/tftpboot:/bin/false
tftp:x:469:471:TFTP account:/srv/tftpboot:/bin/false
usbmux:x:468:65533:usbmuxd daemon:/var/lib/usbmuxd:/sbin/nologin
usbmux:x:462:65533:usbmuxd daemon:/var/lib/usbmuxd:/sbin/nologin
vnc:x:467:470:user for VNC:/var/lib/empty:/sbin/nologin
vnc:x:458:462:user for VNC:/var/lib/empty:/sbin/nologin
Powyżej jedna linijka z starego serwera, druga linijka z nowego.

Jedynie czym się różnią to tymi cyferkami ":x:472:474:" czym one są? Podejrzewam że to jest przyczyna awarii.
Czy mogę bezpiecznie w pliku z starego serwera podmienić te cyferki, na cyferki z nowego?

[microsofter]

Wszystko jasne. System ci się wykłada, bo nie mogą wystartować usługi, gdyż usunąłeś ich konta. Weź pliki ze starego serwera i wytnij z nich konta twoich uzytkowników. Następnie doklej je do tego, co nowy serwer ma z pudełka. Musi działać.
Oczywiście instaluj 15.3.

[Pawel1995]

Mamy to!

O dziwo jak po prostu wkleiłem grupy które mnie interesują do group i użytkowników do passwd to jeszcze nie działało. Cos musiało nie pasowac bo nawet hasło nie "chytało" i trzeba było formata robić. Ale jak jak po prostu w passwd od starego serwera zmieniłem te "cyferki" na odpowiadające jemu z passwd z nowej instalacji to już chyciło! ;D

Bardzo dziękuję za wszelką pomoc!