A rendszer leállítás helyett újraindul

kimarite képe

Előfordulhat, hogy találkozol azzal a jelenséggel, hogy leállítás helyett a rendszer újraindul. Ennek más magyarázatai is lehetnek (--> tesztelés, log fájlok vizsgálata), de érdemes lehet az

apm=power-off

kernel kapcsoló használatával megkísérelni a javítást.
A kapcsoló használatával kényszeríted a kernelt, hogy APM/ACPI-t (Advanced Power Management/Advanced Configuration and Power Interface) használja a kikapcsolás végrehajtására, és ez esetek többségében beválik.
A kivitelezés:
https://linuxmint.hu/blog/2018/03/kernel-kapcsolok-alkalmazasa-a-grub-fajl-szerkesztesevel

A történet érzésem szerint jobban megérthető, ha elolvasod az alábbi -bizonyos részleteiben elavult- párbeszédet, amely a Linuxvilág magazin 2004. áprilisi számában (#39, V. évfolyam, 4. szám), „A hónap szakmai tanácsai” című rovatban jelent meg, és amely forrása a Linux Journal magazin volt (2004. március 119. szám):

Nem működik a leállítás

Két operációs rendszer fut a számítógépemen, egy Microsoft Windows XP és egy Suse 8.2. Amikor az XP-t leállítom, a PC kikapcsol, de amikor a Linux-szot állítom le, a PC újraindul.
-- Andre Bouve

A jelenséget valószínűleg az SMP és az APM között lévő hiba okozza. A két szabvány nem működik együtt, ami a több processzor közötti elkerülhetetlen versenyhelyzetben nyilvánul meg. Linux-szon az SMP rendszermagban az APM szolgáltatás ki van kapcsolva, még akkor is, ha éppen egyprocesszoros gépen fut, Megoldásként megpróbálhatod egyprocesszoros rendszermagra cserélni, vagy olyan kapcsolókkal fordítani a rendszermagot, amely erőlteti az APM-kikapcsolás működését.
-- Jim Dennis

Próbáld meg rendszerindításkor az apm=power-off értéket átadni a rendszermagnak.
-- Usman S. Ansari

Tudás bázis

SMP (Symmetric Multi−Processors)
http://www.tldp.org/HOWTO/pdf/SMP-HOWTO.pdf
(http://www.tldp.org/HOWTO/SMP-HOWTO.html)
Advanced Power Management (APM/ACPI)
http://www.tldp.org/HOWTO/Ecology-HOWTO/ecology-howto-power-management.html
http://tuxmobil.org/apm_linux.html
Kernel
https://help.ubuntu.com/community/Kernel

-----

A Linuxvilág kiadójától a magazinban megjelent írások átvételére, utánközlésére -korábbi megkeresésem által- a forrás feltüntetésével engedélyt kaptam, a honlapon és máshol is.

Hozzászólások

kimarite képe

A rendszer leállítás helyett újraindul

#1 Az a probléma, hogy amennyi többlet információt az idők folyamán összegyűjtöttél, azok sajnos, ma már -többnyire- nem használhatóak, mert ezen beállítások az upstart rendszer vezérlésre (sysvinit) voltak jellemzőek, és nem a systemd-re ..., röviden nem fog működni a modules és a blacklist.conf, legalábbis a Linux Mint 18.x kiadások alatt (systemd). A Linux Mint 17.x kiadások alatt (upstart) még működhetnek, azaz használhatóak, de ott ugyanúgy beválik a grub általam ismertetett szerkesztése. Az (/etc/) rc.local sem használható a systemd alatt, vagyis a scriptelgetésnek itt vége. Így múlik el a világ dicsősége. ;)

De mindenképpen köszönöm a gyűjtésed közzétételét! Sőt további hasonlókat 'kívánok'. :)

Értékelés: 

0
Még nincs értékelve

A rendszer leállítás helyett újraindul

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?

Értékelés: 

0
Még nincs értékelve
kimarite képe

A rendszer leállítás helyett újraindul

#2 A Win10 hibátlanul leáll, de mindkét Linuxnál leáll, és utána azonnal újra is indul a PC.

Valaha az életben volt olyan, hogy a Linux rendszereknél a leállításnál tényelegesen leállt a gép? Vagy, mióta megvan, ezt produkálja mindenféle Linux-ok rendszer leállításánál?
Volt olyan „véletlen” hogy Windows-t nem telepítettél, csak Linux-ot? És ekkor leállt a gép?

Értékelés: 

0
Még nincs értékelve
kimarite képe

Grub Customizer + miegymás

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

Rá kéne nézni, hogy tényleg a Grub Customizer alkalmazásé.
https://bugs.launchpad.net/grub-customizer/+bug/1754690
Használod?

Az apt-file segítségével tudjuk megnézni, amit telepíts terminálban, majd a végén látod a csomag adatbázis frissítés parancssorát, az is futtasd (admin: sudo). Végül nézzük ennek a parancssornak a kimenetét (csak ezé kell ide):

apt-file search grub.ucf-dist

Lehet, nem találjuk meg (hasznos az apt-file máskor is), mert az UCF csomag teszik oda ezt a fájlt (is):
https://packages.debian.org/bullseye/ucf
https://manpages.debian.org/jessie/ucf/ucf.1.en.html

Tehát, a csomagfrissítések hozhatnak beállítási változtatásokat a conf fájlokban, és ebben az esetben a csomagkezelő megkérdezi a rendszergazdát -aki például egy felhasználó- maradjon a régi beállítás, megváltoztassa-e az újra, mutassa a változásokat, stb.. A grub.ucf-dist a csomagkezelő által nem módosítható formátum, értelmezésem szerint, a felhasználói változtatásokat menti (egy-egy csomagnál), azaz, egyféle biztonsági mentés. Valamiért nem frissült a fájl: a sudo update-grub futtatás után újra lett indítva a rendszer?

Érdekesség, hogy a rendszeremen nincs telepítve az UCF csomag, a fájl mégis jelen van, így a GRUB sajátja lehet. Múlt év novemberi dátummal, a grub fájl decemberi, tartalmuk ugyanaz. Szerintem frissülnie kellett volna, azt mondom, a kézikönyvek elolvasása után.

Szerkeszteni kizárólag a mentése után érdemes. Íme a mentés:

sudo cp /etc/default/grub.ucf-dist /etc/default/grub.ucf-dist.ORIG

Telepítve nálad az UCF?

apt-cache policy ucf

Megpróbálhatod szerkeszteni a grub.ucf-dist fájlt. Ugye, arra lehet gondolni -biztosan nem tudom- az ucf csomag alapján, hogy a fájl megőrzi a változtatásaid:

preserve user changes to config files / megőrzi a felhasználói módosításokat a konfigurációs fájlokban

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás

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.
 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Grub Customizer + miegymás

#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.

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás

#5.1

https://paste.ee/p/l99Id

 

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás

@#5.2

Sziasztok!
Sikerült megoldanom a problémát. Most már nem indul magától újra a PC a Linux leállítása után.
Nem tudom, mi javította meg pontosan a hibát, de leírom miket csináltam időrendben egymás után.
1. Az MX linuxnak van egy "MX bootjavító" programja a Beállításkezelő / MX Eszközök csoportban.
   Ezt elindítva kiválasztottam a "GRUB rendszerbetöltő újratelepítéseaz ESP, MBR vagy PBR(root) helyre" funkciót.
   Itt megváltoztattam a GRUB telepítési helyét MBR helyett root-ra. A program felajánlotta az MX Linux root partícióját.
   Klikk az alkalmazás gombra.
2. A PC leállítása, de ekkor még mindig újraindult.
3. A MBR partíciót felűlírtam annak egy korábbi mentésével.
4. Restart, de a GRUB el sem indult, ha jól emlékszem valami Rescue> prompt jelent meg és megállt a betöltés.
5. Power off, majd a Win10 partíciót is felűlírtam annak egy korábbi mentésével.
6. ....
7. Restart, Win10 elindult, fel a netre további hozzászólásokat kerestem ebben a témában.
   Ezt találtam.
   https://askubuntu.com/questions/886222/how-to-turn-off-the-computer-from...
   Javasolt megoldás: In the GRUB menu, press C and then enter halt.
   Ez működött, nem tökéletes, de legalább nem kellett elindítani a Win10-et, hogy leállítsam a PC-t.
   
8. Ugyanezen a linken volt egy másik ötlet, kiegészíteni a GRUB menüt a Shutdown és Reboot menüponttal.
   Ezzel a "press C and then enter halt." is egyszerűsödne.
   https://daulton.ca/2018/08/reboot-and-shutdown-options-grub/
   Az MX Linux-ban módosítottam a leírás szerint a /etc/grub.d/40_custom fájlt,
   a terminálban update-grub.
9. Restart.

Meglepődtem, mert megjavult a rendszer! Innentől fogva már jól működik a PC, Linuxból is simán megy a leállítás.
Plusz a GRUB menü is jobb lett, mert működik a két új Shutdown és Reboot menüpont is.
 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Grub Customizer + miegymás

#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"

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás

#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.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Grub Customizer + miegymás

#6.1.1 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.

Tehát,

  • ha egyetlen alkalommal használod a reboot-ot,
    • ezután mindig újraindul a rendszer a a leállítás menüt használva,
  • de visszaáll a rend, ha a halt utasítással állítod le a rendszert, emez meg javít.

Hm, ez érdekes. De majd csak kifundálunk erre is valamit.

A halt csak ennyi?

sudo halt

De a probléma kizárólag az MX Linux-ra érvényes?
Mert ugye, van más rendszered is. Azokra nem?
Melyik rendszeren van telepítve a GRUB Customizer?

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás

#6.1.1.1

ha egyetlen alkalommal használod a reboot-ot, ezután mindig újraindul a rendszer a a leállítás menüt használva,

Igen, ez történik.

de visszaáll a rend, ha a halt utasítással állítod le a rendszert, emez meg javít.

Igen, a halt utasítás meggyógyítja a rendszert. Ezután mindig normálisan leáll. Az első reboot-ig :-)

A halt csak ennyi?
sudo halt

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

Tegnap még csak az MX Linux volt felrakva, GRUB Customizer nélkül.
A szükséges GRUB módosításokat (várakozási idő és melyik legyen az alapértelmezetten indított op.rendszer) a GRUB Customizer nélkül is be tudom már állítani.
A GRUB az sda1-re, az MBR-be lett telepítve.

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

A Win10 (sda2) mindig normálisan leáll, Akár volt reboot, akár nem.
A Linuxok érzékenyek a rebootra. Kell nekik egy halt, hogy normálisan leálljanak.

A Dell Optiplex 9020-hoz ezt a leírást említettem tegnap.
https://www.dell.com/support/kbdoc/hu-hu/000146625/supported-platforms-b...
Lehet, hogy ebből Nektek valami beugrik.

Older platforms than what is listed in the table below, should use an earlier version of Dell Command | Configure.

Most akkor legyen egy downgrade a Dell Command | Configure programra?
Ha több is van, melyikre? Nem egyértelmű ez nekem.

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

Köszönöm a segítségeteket, és hogy ilyen kitartóak vagytok.

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Grub Customizer + miegymás

#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.

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás

#6.1.1.1.1.1

Szerintem is a Dell PC lehet az oka. Nekem sem volt soha ilyen problémám a régi “noname” gépemen. 
Szerencsére a jelenség szabályos, tehát nem fizikai meghibásodás (elhasználódás) lehet az oka.
Gondolom valamelyik Dell szoftver vagy firmware a ludas. 

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás

#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. 

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás

#6.1.1.1.1.1

Nálam sem, pedig a korábbi gépem egy "noname" PC volt.
Szerintem is a Dell a ludas a dologban.
Szerencsére ez a viselkedés határozottan szabályos, tehát nem valami "gyengélkedő" hardverkomponens okozhatja.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Grub Customizer + miegymás

#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

Értékelés: 

0
Még nincs értékelve
kimarite képe

Grub Customizer + miegymás

#6.1.1.1.1.2 Ui.: inkább admin joggal. És például az utolsó 100 bejegyzés,

sudo journalctl -n 100

vagy tegnaptól máig.

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

További lehetőségek:
https://linuxhandbook.com/journalctl-command/

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás

#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.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Grub Customizer + miegymás

#6.1.1.1.1.2.2 Én írok mindenkinek..., persze, ahogy ráérek (megfogalmazni „ér”,sssőt!). :)
Britney Spears-nek még nem írtam ;) ... https://www.youtube.com/watch?v=SZXjblv1mn8 (kicsit csúnyán beszélnek az elején)

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás Grub Customizer + miegymás

#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.

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Grub Customizer + miegymás + halt

#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.

Értékelés: 

0
Még nincs értékelve

GPT vagy MBR

#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)

 

Értékelés: 

0
Még nincs értékelve

GPT vagy MBR

#6.1.1.1.1.2.3.1.1

Rájöttem, hogy egy korábbi válaszomban hibásan azonosnak vettem a Leggacy-t és az MBR-t.
Utánaolvastam.

BIOS        Partíció-
mód            rendszer
------------------------
Legacy        MBR
UEFI        GPT

Korábban egyébként egy partícionáló programmal alakítottam át a C partíciót MBR-ről GPT-re.
Az átalakítás hiba nélkül lefutott.
Azután a BIOS-ban átkapcsoltam a Legacy-ról az UEFI-re.
Valami miatt nem ment rendesen az UEFI, meg a HDD is bőven 2T alatti, szóval visszatértem az MBR-hez.
Ehhez akkor újra le kellett futtatnom a C partíció átalakítását GPT-ről MBR-re.

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás

#6.1.1.1.1.2.3.1

#6.1.1.1.1.2.3.1

Helyzetjelentés 2023-02-04 22:15

###

sudo systemctl halt

https://www.linode.com/docs/guides/introduction-to-systemctl/(külső hivatkozás)

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

 

Kipróbáltam ezeket is.

$ sudo systemctl halt
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: A gép nem működik
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: A gép nem működik

$ sudo systemctl start halt.target --job-mode=replace-irreversibly --no-block
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: A gép nem működik

###

Sikerül olyan indítóikont készíteni, ami a terminálból hívja meg a halt parancsot
Ezek a beállításai:

[Desktop Entry]
Type=Application
Name=Shut Down
Exec=sudo /sbin/halt
Terminal=true
Icon=system-shutdown
Comment=
Path=
StartupNotify=false

Ez az indítóikon megvan az asztalon és leraktam a panelra is.

Kipróbáltam ezeket, vajon le tudják-e állítani normálisan a gépet egy korábbi reboot után.
A leállítás módja                        Leállítja-e a PC-t normálisan
----------------------------------------------------------------------------------------------
a) A Whisker menü shut down gombja        nem állítja le, újraindul
b) Terminálból sudo halt                nem állítja le, újraindul
c) Indítóikon az asztalról                nem állítja le, újraindul
d) Indítóikon a panelről                nem állítja le, újraindul
e) A GRUB-ból indított halt parancs        igen leállítja, és "meggyógyítja"

A "meggyógyítja" alatt azt értem, hogy azután már a többi a), b), c) és d)
leállítási módok is normálisan működnek (addig, amíg nincs egy újabb reboot).

A GRUB-ból indított "halt"-nál a Linux még nincs betöltve, és így lesz leállítva a PC.
A "hibás" esetekben (a,b,c,d) a Linux már fut, amikor le akarjuk állítani a gépet.

Ezek szerint a reboot hatására valahol módosul egy adat, ami majd kiváltja az újraindulást.
A már futó Linux leállításakor a Linux ezt az adatot nem módosítja, de a GRUB-ból kezdeményezett leállítás igen.

Még egy dolog. Megnéztem, mi van, ha a GRUB-ba beírt reboot menüsort választom ki.
Na ez ugyanúgy elrontja a leállítási folyamatot, mint a Linux-ból indított reboot.
Kell utána egy GRUB-ból kiadott halt, hogy megjavuljon a rendszer.
 
###

Egy korábbi kérdésed volt:

El van indítva?
systemctl status systemd-journald.service --no-pager --all

Beírtam a terminálba, ez a válasz jött:
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: A gép nem működik

Egy oldalon ezt írta valaki.
# check if your system is using `systemd` or `sysvinit`
ps -p 1 -o comm=

Beírtam, ez a válasz:
init

Olvastam leírásokat, de ez már mélyvíz nekem. Annyi azért lejött, hogy a systemd-journald.service
adatokat gyüjt a háttérben (!), hogy könnyebb legyen a hibákat elemezni.
De ehhez valamivel el kell indítani ezt a szolgáltatást.
Ez a szolgáltatás feltételezem a Linux telepítésekor nincs bekapcsolva alapból.

 

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás

#6 Szerintem is, amiket leírtál azok szép dolgok, de nem attól "javult meg".

Nem volt BIOS mókolás, más egyéb?

Nekem  hasonló tapasztalásom dzsuvás billentyűzetekkel szokott lenni, amikor egy -egy gomb beragadása, vagy éppen nem működése befolyásolja az input-ot.

Táp rendben van amúgy?

Értékelés: 

0
Még nincs értékelve

Grub Customizer + miegymás

#6.2

Nem volt BIOS mókolás. A Power managementben találtam olyat, hogy mit csináljon, ha áramkimaradás után újra van áram. Az alapértelmezett van beállítva, hogy maradjon kikapcsolva.

A táp rendben van szerintem. Olvastam én is olyan bejegyzést aki erre gyanakodott hasonló hibánál.

Értékelés: 

0
Még nincs értékelve

Hardver titok

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)

Értékelés: 

5
Átlag: 5 (1 szavazat)

Hardver titok

#7

Köszi, így már világos a folyamat. Megnézem újra a BIOS setup beállításokat. De ha jól emlékszem, sajnos ennél a típusnál csak a 2016-tól gyártott daraboknál vannak ACPI beállítások a BIOS- ban. 

Nekem az A25 BIOS van felrakva. Ez a legfrissebb ehhez a géphez. Dell Optiplex 9020
https://www.youtube.com/watch?v=zQMegkn6HSM(külső hivatkozás)

Azt azért nem értem, ha ez a probléma BIOS függő, akkor miért van az, hogy csak a Linuxot érinti? A Win10 mindig normálisan leáll.

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

journalctl vagy más naló a shutdown állapotról

Ugye, azért kéne valami hibaüzenet, akár más naplóból, mint például egy ilyen,
https://bbs.archlinux.org/viewtopic.php?id=261390
https://bbs.archlinux.org/viewtopic.php?id=261530 )

systemd-shutdown[1]: Waiting for process: dbus-daemon, systmed, rngd, gpg-agent

hogy megtudjuk, melyik unit vagy target kavar be a leálíltásnál.

Ha tudjuk, az ki lehet kapcsolni a megfelelő service fájlban.

Kiemelem dőlt karakterrel, hol:

systemctl cat systemd-user-sessions.service
# /lib/systemd/system/systemd-user-sessions.service
#  SPDX-License-Identifier: LGPL-2.1-or-later
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Permit User Sessions
Documentation=man:systemd-user-sessions.service(8)
After=remote-fs.target nss-user-lookup.target network.target home.mount

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/systemd/systemd-user-sessions start
ExecStop=/lib/systemd/systemd-user-sessions stop

Értékelés: 

0
Még nincs értékelve
kimarite képe

journalctl vagy más napló a shutdown állapotról

#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.

Értékelés: 

0
Még nincs értékelve

journalctl vagy más napló a shutdown állapotról

#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?

Értékelés: 

0
Még nincs értékelve
kimarite képe

journalctl vagy más napló a shutdown állapotról

#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

Értékelés: 

5
Átlag: 5 (1 szavazat)

journalctl vagy más napló a shutdown állapotról

#8.1.1.1

Köszönöm.

Értékelés: 

0
Még nincs értékelve

A rendszer leállítás helyett újraindul

#8.1.1.1.1.1

#8.1.1.1.1.1

Sziasztok!

Megtaláltam a megoldást. A magyarázatot nem tudom, de működik.
A BIOS-ban kellett módosítani a beállításokat, hogy sem az USB-ről sem a hálózatról ne lehessen felébreszteni a gépet.
A Power Management csoportban van két beállítás:
 Enable USB Wake Support ---> a checkbox-ból a pipát kivettem
 Wake on LAN disabled     ---> ez lett kiválasztva a három rádiógomb közül.

Ugyanis az ezzel kapcsolatos hozzászólásokban sokan emlegették a "WOL" funkciót.
Gyorsan meg is néztem. Nekem mindkettő engedélyezve volt.
Lehet, hogy az egyiket is elég lett volna tiltani, de jobb az, ha mindkettő ki van kapcsolva.

Ezen a linken olvasható hozzászólások voltak a nyomravezetők:
https://www.dell.com/community/Optiplex-Desktops/Optiplex-5050-turns-bac...

Az A25-ös BIOS beállítási lehetőségei itt nézhetők meg:
https://www.youtube.com/watch?v=zQMegkn6HSM
Ezen a videón nem az én beállításaim vannak, de az ominózus kettő ebben is pont úgy van beállítva, amire én is módosítottam.
 

Értékelés: 

0
Még nincs értékelve