Sziasztok! Sajnos nálam is fennáll ez a probléma.
A Win10 hibátlanul leáll, de mindkét Linuxnál leáll, és utána azonnal újra is indul a PC.

Linux Mint 21      (/dev/sda6)
Linux MX 21.3 Wildflower (/dev/sda5)
Windows 10         (/dev/sda1)

Az apm=power-off kapcsolót beírtam a Grub config fájlba.
GRUB_DEFAULT="0"
GRUB_TIMEOUT_STYLE="hidden"
GRUB_TIMEOUT="30"
GRUB_DISTRIBUTOR="`lsb_release -i -s 2> /dev/null || echo Debian`"
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash apm=power-off"
GRUB_CMDLINE_LINUX=""

A default könyvtárban találtam egy ilyen nevű fájlt is:   grub.ucf-dist

Ebbe nem másoltam be a kapcsolót.
Ebbe is bemásoljam?
GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Mit kellene még megadnom, hogy pontosabban be lehessen határolni a hiba okát?
Sysinfók a Linux telepítésekről?

Szia!
Na már van DropBoxom,
Hogyan tudom megosztani az oda feltöltött fájlt?
A fájlhoz tartozó linket már le tudom kérni.
 

#5.1

https://paste.ee/p/l99Id

#5 Hogyan tudom megosztani az oda feltöltött fájlt?

Milyen fájlt? Fájl nem szokás megosztani, a tartalmát igen (itt: paste.ee).

^{Nyomd meg a Válasz elemet, mert ha nem így teszel, nem tudjuk mire válaszolsz, ebből következően előfordulhat, sohasem válaszolunk.}

#6.1

A BIOS-ban nem találtam az ACPI-re vonatkozó beállítási lehetőséget.
PC gyártó és típus: Dell Optiplex 9020
Gyártás éve: 2015-04-11
BIOS verzió: A25
Valahol olvastam is hogy ezeknél a PC-nél az ACPI 2016 után jelent meg a BIOS-ban.

Hasonlóképpen ErP/EuP sincs a BIOS-ban.

Végigpróbáltam a shutdown, reboot, halt parancsokat. Mindegyik jól működik.

Visszaraktam a # jelet a GRUB_GFXMODE="1024x768" sor elejére, ez sem segített.

Szóval partíciótörlés után újraraktam az MX Linuxot.
Egy érdekes jelenséget vettem észre, ami azóta is szabályosan működik, következetesen ezt csinálja a PC, nem véletlenszerűen.

Ha a Linuxot reboot-tal indítom újra, akkor mindaddig újraindul a normális leállítás parancs után
is, amig a terminálból halt paranccsal vagy a GRUB-ból c -> halt paranccsal le nem állítom a gépet. A halt parancs be van építve önálló sorként a GRUB menübe.
Ammeddig nincs reboot, addig normálisan leállítva marad a kikapcsolás után.
Tehát mindig reboot lesz végrehajtva a normális leállításnál is, amig nem jön egy halt utasítás.
Érdekes.

#6 Szerintem, nem a GRUB újratelepítése kellett.

Az ACPI van beállítva a BIOS-ban  az energiakezelésnél?
Netán van olyan, hogy ErP/EuP (erről: * , **), és ott mi szerepel?

Meg lehet nézni, melyik parancssor működik, és melyik nem.
https://www.binarytides.com/linux-command-shutdown-reboot-restart-system/

___

Az MX Linux beállításban ki van véve megjegyzésből ez a felbontás..., akár ok is lehet.

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="1024x768"

#6.1.1.1.1.1

Nálam sem volt ilyen hiba a korábbi “noname” gépemen. Valamit a Dell nem kezel rendesen, ha Linux fut éppen rajta. 

#6.1.1.1.1 A Linuxok érzékenyek a rebootra. Kell nekik egy halt, hogy normálisan leálljanak.

Nálam nem volt még ilyen jelenség soha. Egy rendszeren sem. :) ... hardverfüggő lehet.

A többit, ami még írtál, átnézem délután.

#6.1.1.1.1.2

Szia!
Nagyon köszönöm a részletes leírásokat, válaszokat.
Ez nekem így minimum egy hétre való érdekes feladat.
Igyekszem megválaszolni minél hamarabb a kérdéseidet.
Igazad van, érdemes lenne írnom a Dell-nek.

#6.1.1.1.1 Ahogy ígértem, válaszolok a „többire” is. :)

Ma délután felraktam a Linux Mintet is.
GRUB nélkül az ubiquiti -b paranccsal a telepítés előtt.

Mostanában nem az Ubiguity (*) az alapértelmezett Linux Mint telepítő. Nemrég próbáltam -azaz, kíváncsiságból kipróbáltam volna- egy virtuális rendszeren a telepítéshez, de őszintén szólva, elsőre nem ment, talán, mert virtuális környezet volt, és nem mentem utána, miért nem. De például létezik az Anaconda is. Esetleg írhatnál erről egy blogot, ami nyilván lehet rövid is, mert vélhetően nem hosszú a beállítás folyamata.

###

A halt csak ennyi?
sudo halt
Igen, sudo halt. Akár terminálból, akár a Grub menübe illesztett menüsorral.

Köszi. Gondolkodom, mi lehet a probléma..

Amit linkelsz (*), beválik. Nekem más ugrott be: hogy a GRUB Hibajavítás mód (Recovery mode) után néha a rendszer csak olvasható módban fűződik be, így -főleg, ha furcsaságot tapasztalsz- akkor a Hibajavítás módból kilépés után elinduló rendszert célszerű a bejelentkezés előtt újraindítani. Avagy a BIOS-nak is lehetnek sajátossága. Én sokat vesződtem egy AMD alaplappal, a BIOS gyorsindítás beállítása nélkül nehezen indult a Linux vagy sok hibával.

###

A Dell Optiplex 9020-hoz ezt a leírást említettem tegnap.
https://www.dell.com/support/kbdoc/hu-hu/000146625/supported-platforms-bios-reference-list-for-dell-command-configure-dell-command-monitor-and-dell-command-powershell-provider
Lehet, hogy ebből Nektek valami beugrik.

Azt írod: Dell Optiplex 9020, gyártás éve: 2015-04-11, BIOS verzió A25

Közben itt más szerepel:

OptiPlex 9020M	A07
OptiPlex 9020 AIO	A12
OptiPlex 9020	A14

Ha írnál a Dell-nek, hogy mi a magyarázat, mit célszerű csinálnod?
Aham, tényleg A25 (*).
A BIOS verziót a fwupd alkalmazás hozta (nem látom), vagy máshogyan lett telepítve, letöltve?
2015: most ez egy UEFI képes gép vagy nem? (Updating the BIOS on supported UEFI systems (2015 onwards) / Update the BIOS on Dell systems before 2015)
Mert mire van állítva a BIOS most?
http://www.rodsbooks.com/efi-bootloaders/csm-good-bad-ugly.html
https://askubuntu.com/questions/642795/installing-ubuntu-14-04-on-dell-optiplex-9020
https://forums.linuxmint.com/viewtopic.php?t=159231

Ezek fontos dolgok:

Valahol olvastam is hogy ezeknél a PC-nél az ACPI 2016 után jelent meg a BIOS-ban.
Hasonlóképpen ErP/EuP sincs a BIOS-ban.

NVME van? (nvme_load=YES | kernel kapcsoló)
https://www.dell.com/support/kbdoc/hu-hu/000131901/loading-ubuntu-on-systems-using-pcie-m2-drives

Érdekesség (SHIMx64.EFI | BOOTx64.EFI), hátha hasznos lesz másvalakinek:
https://www.dell.com/support/kbdoc/hu-hu/000141125/xps-13-9343-how-to-install-ubuntu-developer-edition-14-04-on-a-dell-pc-configured-for-the-unified-extensible-firmware-interface-uefi-bios

###

Tegnap még csak az MX Linux volt felrakva, GRUB Customizer nélkül.
A GRUB az sda1-re, az MBR-be lett telepítve.

Ma délután felraktam a Linux Mintet is.
Természetesen most már a Mint is GRUB Customizer nélkül fut.

Így, most már két Linux van fent, és továbbra is úgy működik minden, mint tegnap egy Linux-szal.

Szerintem meg kell oldani a GRUB Customizer nélkül a GRUB menü szerkesztését, hiszen olykor elég komolyan összekuszál mindent. Mivel most nincs telepítve, és maradt a hiba, tehát nem ő tehet erről. Lehet a tárhelyre (sda, sdb, sdc..., stb.) vagy partícióra is tenni a GRUB-ot. Ha partícióra teszed, akkor érdemes a gyökér partícióra: adott rendszer / adott gyökér partíciójára (te is írtad: „megváltoztattam a GRUB telepítési helyét MBR helyett root-ra”).

Ilyet is berakhatsz: Dell DOS Diagnostics

Még valami: SupportAssist Pre-Boot System Performance Check

... az első gépem egy Dell OptiPlex volt. Meg nem mondom hirtelen melyik -a háza lehet, valahol megvan- egy P I-es, 200 Mhz-s CPU-val. :)

###

Egyébként a "halt parancsos módszer" élhető megoldás nekem, mert a reboot módot szinte soha nem használom.

Esetleg készíts rá egy Panel elemet.

###

Ha futtatod,

journalctl

mit mutat egy olyan időpontban, amikor leállítottad, de újraindult? Tesztelheted a rossz állapotba állítva.
___
https://askubuntu.com/questions/1171430/ubuntu-18-04-restarting-by-itself-after-shutdown

#6.1.1.1.1.2

#6.1.1.1.1.2

Nos, ezeket tudtam eddig megnézni.

###

Linux telepítés: ubiquiti -b
Esetleg írhatnál erről egy blogot, ami nyilván lehet rövid is, mert vélhetően nem hosszú a beállítás folyamata.

Megtaláltam a linket, ahol megvan a részlees leírás.
https://averagelinuxuser.com/install-linux-mint-without-a-bootloader/
E szerint csináltam és elsőre működött. Hozzá kell tenni, hogy az ubiquiti -b parancs kiadása után percekbe telt, amíg elindult a telepítés, de lefutott hibátlanul.

###

Mert mire van állítva a BIOS most?

Legacy (Gondolom ez jelenti az MBR módot.)
Igen, UEFI képes. Részletes leírást nem, de egy rövid videót találtam, amiben végigmennek az A25 BIOS képernyőin.
https://www.youtube.com/watch?v=zQMegkn6HSM

###

NVME van? (nvme_load=YES | kernel kapcsoló)

Nincs.

###

Szerintem meg kell oldani a GRUB Customizer nélkül a GRUB menü szerkesztését,

Igen, már tudom szerkeszteni a GRUB menüt. Nincs telepítve a GRUB Customizer.

###

Esetleg készíts rá egy Panel elemet.

Nem tudok olyan parancsikont készíteni, ami a terminálból indítja a halt parancsot.
Az indítóikon parancs mezőjébe beírtam: halt
Kijelöltem, hogy terminálban fusson, de ez a hibaüzenet jött:
A gyermek végrehajtása meghiúsult. (Na erre a keresők nem éppen Linux megoldásokat hoznak fel.)

###

Ha futtatod, journalctl
mit mutat egy olyan időpontban, amikor leállítottad, de újraindult? Tesztelheted a rossz állapotba állítva.

No journal files were found.
-- No entries --
Nem talált bejegyzéseket.

sudo journalctl -n 100
sudo journalctl --since=yesterday --until=now

A többi journal módnál is ugyanaz a helyzet: -- No entries --

###

https://askubuntu.com/questions/1171430/ubuntu-18-04-restarting-by-itsel...

Nagyon jó, hogy megtaláltad ezt a linket. Ebből nagyon úgy tűnik nekem, hogy ez az anomália "Dell specialitás" lehet. A hibaleírás 100%-ban stimmel azzal, amit én tapasztaltam.

Az egyik válaszadó írta:
I stopped the rebooting on my system (a Dell Optiplex 9020 SFF running Ubuntu 18.04 like yours) by disabling the USB 3.0 ports in BIOS > System configuration > USB Configuration > [untick] enable USB 3.0 ports.
Ez nekem is működött, de így nincsenek USB3.0 portok. Szóval ez nem lesz jó.
Visszakapcsoltam a BIOS-ban az USB3.0 portokat.

^ my system was running in legacy mode to start with, but I had to reinstall Ubuntu 18.04 on it in order to get the graphics drivers to work, UEFI mode had to be enabled in this case, that is when the issue started for me.
Érdekes, korábban én is próbáltam az UEFI módot, de valami nem működött rendesen, ezért visszaraktam a 'Legacy' módba. Lehet, hogy ez a visszaállítás nem sikerült helyesen, és azért indul újra?

###

Most az tűnik a legegyszerűbb megoldásnak, ha tudnék olyan parancsikont kirakni a panelre, ami terninálból kiadja a halt parancsot. ezzel minden leálláskor törölni tudnám a "reboot maradékát", ami megzavarja a Linuxot.

#6.1.1.1.1 Ahogy ígértem, válaszolok a „többire” is. :)

Ma délután felraktam a Linux Mintet is.
GRUB nélkül az ubiquiti -b paranccsal a telepítés előtt.

Mostanában nem az Ubiguity (*) az alapértelmezett Linux Mint telepítő. Nemrég próbáltam -azaz, kíváncsiságból kipróbáltam volna- egy virtuális rendszeren a telepítéshez, de őszintén szólva, elsőre nem ment, talán, mert virtuális környezet volt, és nem mentem utána, miért nem. De például létezik az Anaconda is. Esetleg írhatnál erről egy blogot, ami nyilván lehet rövid is, mert vélhetően nem hosszú a beállítás folyamata.

###

A halt csak ennyi?
sudo halt
Igen, sudo halt. Akár terminálból, akár a Grub menübe illesztett menüsorral.

Köszi. Gondolkodom, mi lehet a probléma..

Amit linkelsz (*), beválik. Nekem más ugrott be: hogy a GRUB Hibajavítás mód (Recovery mode) után néha a rendszer csak olvasható módban fűződik be, így -főleg, ha furcsaságot tapasztalsz- akkor a Hibajavítás módból kilépés után elinduló rendszert célszerű a bejelentkezés előtt újraindítani. Avagy a BIOS-nak is lehetnek sajátossága. Én sokat vesződtem egy AMD alaplappal, a BIOS gyorsindítás beállítása nélkül nehezen indult a Linux vagy sok hibával.

###

A Dell Optiplex 9020-hoz ezt a leírást említettem tegnap.
https://www.dell.com/support/kbdoc/hu-hu/000146625/supported-platforms-bios-reference-list-for-dell-command-configure-dell-command-monitor-and-dell-command-powershell-provider
Lehet, hogy ebből Nektek valami beugrik.

Azt írod: Dell Optiplex 9020, gyártás éve: 2015-04-11, BIOS verzió A25

Közben itt más szerepel:

OptiPlex 9020M	A07
OptiPlex 9020 AIO	A12
OptiPlex 9020	A14

Ha írnál a Dell-nek, hogy mi a magyarázat, mit célszerű csinálnod?
Aham, tényleg A25 (*).
A BIOS verziót a fwupd alkalmazás hozta (nem látom), vagy máshogyan lett telepítve, letöltve?
2015: most ez egy UEFI képes gép vagy nem? (Updating the BIOS on supported UEFI systems (2015 onwards) / Update the BIOS on Dell systems before 2015)
Mert mire van állítva a BIOS most?
http://www.rodsbooks.com/efi-bootloaders/csm-good-bad-ugly.html
https://askubuntu.com/questions/642795/installing-ubuntu-14-04-on-dell-optiplex-9020
https://forums.linuxmint.com/viewtopic.php?t=159231

Ezek fontos dolgok:

Valahol olvastam is hogy ezeknél a PC-nél az ACPI 2016 után jelent meg a BIOS-ban.
Hasonlóképpen ErP/EuP sincs a BIOS-ban.

NVME van? (nvme_load=YES | kernel kapcsoló)
https://www.dell.com/support/kbdoc/hu-hu/000131901/loading-ubuntu-on-systems-using-pcie-m2-drives

Érdekesség (SHIMx64.EFI | BOOTx64.EFI), hátha hasznos lesz másvalakinek:
https://www.dell.com/support/kbdoc/hu-hu/000141125/xps-13-9343-how-to-install-ubuntu-developer-edition-14-04-on-a-dell-pc-configured-for-the-unified-extensible-firmware-interface-uefi-bios

###

Tegnap még csak az MX Linux volt felrakva, GRUB Customizer nélkül.
A GRUB az sda1-re, az MBR-be lett telepítve.

Ma délután felraktam a Linux Mintet is.
Természetesen most már a Mint is GRUB Customizer nélkül fut.

Így, most már két Linux van fent, és továbbra is úgy működik minden, mint tegnap egy Linux-szal.

Szerintem meg kell oldani a GRUB Customizer nélkül a GRUB menü szerkesztését, hiszen olykor elég komolyan összekuszál mindent. Mivel most nincs telepítve, és maradt a hiba, tehát nem ő tehet erről. Lehet a tárhelyre (sda, sdb, sdc..., stb.) vagy partícióra is tenni a GRUB-ot. Ha partícióra teszed, akkor érdemes a gyökér partícióra: adott rendszer / adott gyökér partíciójára (te is írtad: „megváltoztattam a GRUB telepítési helyét MBR helyett root-ra”).

Ilyet is berakhatsz: Dell DOS Diagnostics

Még valami: SupportAssist Pre-Boot System Performance Check

... az első gépem egy Dell OptiPlex volt. Meg nem mondom hirtelen melyik -a háza lehet, valahol megvan- egy P I-es, 200 Mhz-s CPU-val. :)

###

Egyébként a "halt parancsos módszer" élhető megoldás nekem, mert a reboot módot szinte soha nem használom.

Esetleg készíts rá egy Panel elemet.

###

Ha futtatod,

journalctl

mit mutat egy olyan időpontban, amikor leállítottad, de újraindult? Tesztelheted a rossz állapotba állítva.
___
https://askubuntu.com/questions/1171430/ubuntu-18-04-restarting-by-itself-after-shutdown

#6.1.1.1.1.2.3.1 OFF:

A BIOS beállítás megváltoztatása a már telepített rendszerek elindulását akadályozza (Windows, Linux). A telepítés előtt szokás beállítani valamilyen elvárásnak megfelelően. Ha megváltoztatod, majd a visszaállítod az eredeti beállítást a telepített rendszernél, szerintem, nem okoz gondot (próbáltam én is).
Itt az a kérdés, hogy a telepítés utáni BIOS beállítás eredeti állapotában, vagyis, a változtatás előtt működött-e minden.

Úgy van! Tehát meglévő MBR lemezről nem lehet bootolni UEFI rendszerben, meg fordítva, leszámítva azokat az eseteket, amikor a BIOS támogatja (CSM), de ezzel kapcsolatban is vannak korlátok.

Ugyanakkor mind Windows, mind Linux esetében vannak eszközök amivel át lehet alakítani az MBR lemezt GPT struktúrára. Jó kis cikket lehetne írni erről, csak a Linux verziót még nem tudtam kipróbálni. Windows esetén min. W10 kell, abban van eszköz a konvertáláshoz, de ezt át lehet másolni régebbi Windowsra is, és működik. (én W7-el csináltam ilyent)

Linuxra több eszköz van (ezek között több keresztkompatilis is ráadásul), egy példa:

https://slavisa-jovanovic.com/linux/2015/02/19/mbr-to-gpt.html

(Csak úgy eszembe jutott)

#6.1.1.1.1.2.3 Esetleg készíts rá egy Panel elemet.
Nem tudok olyan parancsikont készíteni, ami a terminálból indítja a halt parancsot.
Az indítóikon parancs mezőjébe beírtam: halt
Kijelöltem, hogy terminálban fusson, de ez a hibaüzenet jött:
A gyermek végrehajtása meghiúsult. (Na erre a keresők nem éppen Linux megoldásokat hoznak fel.)

Manapság már nem binárisként kell futtatni, de azt is inkább teljes elérési úttal kéne, viszont látod, nincs,

which halt

hanem a systemctl által vezérelten (Systemd-s rendszereken),

apt-file search halt | egrep -e 'bin|sbin'
grub-coreboot-bin: /usr/lib/grub/i386-coreboot/halt.mod
grub-efi-amd64-bin: /usr/lib/grub/x86_64-efi/halt.mod
grub-efi-ia32-bin: /usr/lib/grub/i386-efi/halt.mod
grub-ieee1275-bin: /usr/lib/grub/i386-ieee1275/halt.mod
grub-pc-bin: /usr/lib/grub/i386-pc/halt.mod
grub-xen-bin: /usr/lib/grub/i386-xen/halt.mod
grub-xen-bin: /usr/lib/grub/i386-xen_pvh/halt.mod
grub-xen-bin: /usr/lib/grub/x86_64-xen/halt.mod
klibc-utils: /usr/lib/klibc/bin/halt
lam-runtime: /usr/bin/lamhalt
libmpj-java: /usr/bin/mpjhalt
molly-guard: /sbin/halt
progress-linux-container: /sbin/halt
runit-init: /sbin/halt
scilab-data: /usr/share/scilab/modules/core/macros/halt.bin
systemd-sysv: /sbin/halt
sysvinit-core: /sbin/halt

így:

sudo systemctl halt

https://www.linode.com/docs/guides/introduction-to-systemctl/

vagy (látod is, mi a gond, de „kill” van, azaz nem törődik ezzel a rendszer - erőszakos kikapcsolás)

sudo systemctl start halt.target --job-mode=replace-irreversibly --no-block

https://www.man7.org/linux/man-pages/man1/systemctl.1.html

Ezeket érdemes terminálban kipróbálni, mielőtt parancsikonba teszed...

Most az tűnik a legegyszerűbb megoldásnak, ha tudnék olyan parancsikont kirakni a panelre, ami terninálból kiadja a halt parancsot. ezzel minden leálláskor törölni tudnám a "reboot maradékát", ami megzavarja a Linuxot.

De! Én is butaságot írtam (külön parancsikon), hiszen a leállítás parancssorát főmenüben megváltoztattad szöveg szerkesztéssel, ott is érvényes. Vagy nem?

Érdekes, korábban én is próbáltam az UEFI módot, de valami nem működött rendesen, ezért visszaraktam a 'Legacy' módba. Lehet, hogy ez a visszaállítás nem sikerült helyesen, és azért indul újra?

A BIOS beállítás megváltoztatása a már telepített rendszerek elindulását akadályozza (Windows, Linux). A telepítés előtt szokás beállítani valamilyen elvárásnak megfelelően. Ha megváltoztatod, majd a visszaállítod az eredeti beállítást a telepített rendszernél, szerintem, nem okoz gondot (próbáltam én is).
Itt az a kérdés, hogy a telepítés utáni BIOS beállítás eredeti állapotában, vagyis, a változtatás előtt működött-e minden.
Tehát...

• telepítetted a Windows-t bizonyos BIOS UEFI beállítással (a Legacy-t a célszerű beállítani, ha Linux telepítést tervezel)
• aztán telepítetted a Linux-o(kat)
  • mindnek ugyanaz a beállítás kell (máshogyan: az kell, ami az elsőként telepített rendszernek)

Ha futtatod, journalctl
mit mutat egy olyan időpontban, amikor leállítottad, de újraindult? Tesztelheted a rossz állapotba állítva.
No journal files were found.
-- No entries --
Nem talált bejegyzéseket.

El van indítva?

systemctl status systemd-journald.service --no-pager --all

NVME van? (nvme_load=YES | kernel kapcsoló)
Nincs.

Rendben.

Nagyon jó, hogy megtaláltad ezt a linket. Ebből nagyon úgy tűnik nekem, hogy ez az anomália "Dell specialitás" lehet. A hibaleírás 100%-ban stimmel azzal, amit én tapasztaltam.

Nem kizárt. Esetleg lehet javítani. Még nem tudjuk, mit.

Szóval a gép, ha le kell állni, akkor a rendszer küld egy halt parancsot az ACPI részére, hogy álljon le.

Ha újra kell indulni, ugyanez a folyamat, csak akkor egy BIOS regiszterbe bejelölésre kerül, hogy induljon újra.

Ezt a regisztert induláskor a BIOS-nak alaphelyzetre kell állítani.

Ez úgy néz ki, nálad elmarad.

Lehet más ACPI beállítások segítenek ezen, arra fele kellene próbálkozni, bár nem fűzök hozzá sok reményt. (BIOS setup felületen)

#8.1

Mivel az MX Linuxon nem indul el alapból a naplózás, megnéztem a Linux Mint-nél.
Szerencsére ott van ilyen!!! A journalctl parancs működik.
A terminálban egy nagyon-nagyon hosszú listát mutat.
Lehet-e ezt valahogy szűrni, hogy csak az indítás / újraindítás / leállítás-hoz tartozó bejegyzéseket mutassa, Illetve milyen szűrés lenne jó a hibakereséshez?

A Linux Mintben egy kicsit más a helyzet. Itt a terminálból indított
sudo halt
és
sudo systemctl halt
parancsoknál lefagy a rendszer, a power gomb nyomva tartásával kellett leállítanom. Érdekes hogy ez a leállítási mód után is már normálisan működik a leállítás.

###
Más.

A Linux Mint nálam most "szöveges módban" indul, azaz kiír minden lépést a képernyőre, amit végrehajtott egészen a bejelentkezési ablakig. Egy csomó [OK] ... -val kezdődő sort.

Hol lehet átkapcsolni azt, hogy a szöveg helyett a Mint logót mutassa addig, amíg le nem fut a bejelentkezési folyamat?

#8 Ha nem jelentkezik hiba közvetlen, akkor másik Systemd szolgáltatást készíteni...

Csak példa, nem követendő úgy egészében:
https://github.com/systemd/systemd/issues/4927#issuecomment-412356900
De csak jelentkezik valamilyen jelzés a Shutdown/Leállítás elem megnyomása után a naplókban.

#8.1.1.1

Köszönöm.

#8.1.1 Mivel az MX Linuxon nem indul el alapból a naplózás, megnéztem a Linux Mint-nél.
Szerencsére ott van ilyen!!! A journalctl parancs működik.
A terminálban egy nagyon-nagyon hosszú listát mutat.
Lehet-e ezt valahogy szűrni, hogy csak az indítás / újraindítás / leállítás-hoz tartozó bejegyzéseket mutassa, Illetve milyen szűrés lenne jó a hibakereséshez?

Egy-egy nap átmenetét nézd át (4-ről 5-re).
Szűrni lehet a grep-pel. Példa:

lsmod | grep uas

Ha a kis- és nagybetű fontos:

dmesg | egrep -i USB

A Linux Mintben egy kicsit más a helyzet. Itt a terminálból indított
sudo halt
és
sudo systemctl halt
parancsoknál lefagy a rendszer, a power gomb nyomva tartásával kellett leállítanom. Érdekes hogy ez a leállítási mód után is már normálisan működik a leállítás.

Nyilván lehet vizsgálni..., azonban az MX Linux Debian-alapú, a Linux Mint -kivétel az LMDE- Ubuntu-alapú. Mások.

A Linux Mint nálam most "szöveges módban" indul, azaz kiír minden lépést a képernyőre, amit végrehajtott egészen a bejelentkezési ablakig. Egy csomó [OK] ... -val kezdődő sort.

Hol lehet átkapcsolni azt, hogy a szöveg helyett a Mint logót mutassa addig, amíg le nem fut a bejelentkezési folyamat?

Kernel kapcsolók alkalmazásával. Időnként változik a hatásuk. :)

A kapcsolók

splash

vagy

quiet