GRUB menü személyre szabása: az alapértelmezett menüpont beállítása

kimarite képe

Bizonyára túl vagy már azon, hogy láthatóvá tetted a GRUB menüt.
Erről itt írtam: https://linuxmint.hu/blog/2017/10/a-grub-menu-lathatosaga
Így a GRUB menüben ki tudod választani a Hibajavítás elemet is (Recovery), és bizonyos javításokat végezhetsz a segítségével. Elárulom, ezeket a javításokat a már elindított rendszer alatt is meg tudod tenni, viszont olykor hasznos lehet a GRUB-ból történő indítás.

Ha egynél több kernel van telepítve, akkor felmerülhet az igény arra, hogy
-- csak egy bizonyos, általad kiválasztott kernellel induljon a rendszer, vagy
-- netán mindig az a kernel induljon, amelyik a legutoljára volt használva.

Az igények és a megoldások különbözőek.

A megoldás mindkét esetben a grub fájl szerkesztése.
A grub fájl egyszerű szöveges fájl, a kedvenc szövegszerkesztőddel szerkesztheted.

A grub fájl itt található a fájlrendszerben:

/etc/default/grub

A grub fájl bármilyen szerkesztése után a rendszert frissíteni kell az új beállításokra.
A beállítások frissítése Debian-alapű rendszereken kizárólag ezzel a paranccssorral történhet:

sudo update-grub

Debian-alapú rendszer például a Linux Mint, az LMDE3, az Ubuntu, az MX Linux.
A grub fájl beállításai a rendszerre telepített összes kernelre hatással vannak.
Kernel frissítés, telepítés és eltávolítás alkalmával a most tárgyalt beállítások nem változnak meg, viszont az update-grub és az update-initramfs parancsokat a rendszer minden esetben lefuttatja, így saját, felhasználó beavatkozásra nincs szükség. Egyes alkalmazások, például a Virtualbox, erősen kötődnek a már telepített kernel(ek)hez. Esetenként a kernel frissítés vagy telepítés a Virtualbox elhanyagolható nehézségű beállítását hozhatja.

GRUB menü

A GRUB menüben a telepített kernelek menüpontokként jelennek meg.

A rendszer indítása után megjelenik a GRUB menüje. A GRUB a beállításoktól függően, 5-10 másodperc ideig felhasználói beavatkozásra vár. Ha nem történik semmi, nem avatkozol be a folyamatba, akkor az alapértelmezett beállítással indul el a rendszer. A legfelső menüpont a rendszer alapértelmezett indítása, ezt indítja a GRUB. Az alatta látható menüpont neve:

Speciális beállítások ehhez vagy Advanced options for Debian GNU/Linux

Ebben, a részletező menüpontban találhatóak a rendszerre telepített kernelek indítási lehetőségei. A Speciális / Advanced menüpont kiválasztása a kurzor nyíllal (billentyű), a menüpontba lépés az Enter (billentyű) leütésével történik. A részletező menü használata a már jól ismert módon, a menüpont kijelölése a kurzor nyilakkal, a kiválasztás és érvényesítés Enter leütésével történik. Az Enter leütése után a rendszer a kiválasztott menüpont beállításaival, a menüpontban szereplő kernellel indul el. A Hibajavítás / Recovery menüpont mindegyik kernelhez elérhető, de nem a rendszert indítja, hanem a hibajavító scriptet, amelyről korábban említést tettem.

Nézzük a lehetőségeket ...

Alapértelmezett menüpont beállítása

Ha valamilyen okból mindig ugyanazzal a kernellel használnád a rendszert ...

Itt kicsit részletesebben írok néhány általános tudnivalóról.

Nézd meg a lehetőségeket (a létező menüpontok listázása):

grep menuentry /boot/grub/grub.cfg

Példa következik, hiszen a te rendszered vélhetően egészen más. A parancssor kimenete nálad más lesz, figyelj erre!

Az előbbi parancssor kimenete (a lehetőségek):

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
  menuentry_id_option=""
export menuentry_id_option
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {
submenu 'Speciális beállítások ehhez: Debian GNU/Linux' $menuentry_id_option 'gnulinux-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {
    menuentry 'Debian GNU/Linux, Linux 5.0.0-19.1-liquorix-amd64 verzióval' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.0.0-19.1-liquorix-amd64-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {
    menuentry 'Debian GNU/Linux, with Linux 5.0.0-19.1-liquorix-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.0.0-19.1-liquorix-amd64-recovery-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {
    menuentry 'Debian GNU/Linux, Linux 5.0.0-18.1-liquorix-amd64 verzióval' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.0.0-18.1-liquorix-amd64-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {
    menuentry 'Debian GNU/Linux, with Linux 5.0.0-18.1-liquorix-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.0.0-18.1-liquorix-amd64-recovery-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {
    menuentry 'Debian GNU/Linux, Linux 4.19.0-0.bpo.5-rt-amd64 verzióval' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.19.0-0.bpo.5-rt-amd64-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {
    menuentry 'Debian GNU/Linux, with Linux 4.19.0-0.bpo.5-rt-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.19.0-0.bpo.5-rt-amd64-recovery-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {
    menuentry 'Debian GNU/Linux, Linux 4.9.0-9-rt-amd64 verzióval' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.9.0-9-rt-amd64-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {
    menuentry 'Debian GNU/Linux, with Linux 4.9.0-9-rt-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.9.0-9-rt-amd64-recovery-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {
    menuentry 'Debian GNU/Linux, Linux 4.9.0-9-amd64 verzióval' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.9.0-9-amd64-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {
    menuentry 'Debian GNU/Linux, with Linux 4.9.0-9-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.9.0-9-amd64-recovery-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {

Tegyük fel, én azt szeretném, hogy ezzel a menüponttal (kernellel) induljon el a rendszer. Minden egyes indításkor.

    menuentry 'Debian GNU/Linux, Linux 4.9.0-9-amd64 verzióval' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.9.0-9-amd64-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {

Ez a menüpont

    menuentry 'Debian GNU/Linux, with Linux 4.9.0-9-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.9.0-9-amd64-recovery-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {

a Hibajavítás menüje, indítása (recovery mode / recovery). Ezt alkalmanként használom. Ha egyáltalán. Érthető módon nem szeretném, hogy ez induljon el.

Látható, hogy a menüpontokat a { karakter választja el, a kezdés, és a lezárás is ezzel a karakterrel történik.
A menüpontok tulajdonságai tartalmaznak egy könnyebben érthető menüpont nevet, és egy személyazonosságot is, azaz ID-t ($menuentry_id_option).

A grub.cfg fájlt Debian-alapú rendszeren ne szerkeszd! A grub.cfg fájlt az update-grub parancs állítja elő ... és írja felül, úgyhogy a szerkesztése értelmetlen. A fájl fejlécében szerepel a tájékoztatás,

# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

amely magyarra fordítva ezt jelenti: ne szerkeszd a fájlt.
Ennél egyértelműbb megfogalmazás nincs is. Kiabál kicsit, hátha így jobban észreveszed a lényeget.

Fogjunk hozzá a szerkesztéshez ...

Ha eddig nem készítettél biztonsági másolatot a grub fájlról, tedd meg most:

sudo cp /etc/default/grub /etc/default/grub.ORIG

Nyisd meg szerkesztésre az eredeti grub fájlt:

sudo nano /etc/default/grub

... mindezt megteheted úgy is, ha a fájlkezelőben rákeresel a fájlra,

Fájlrendszer > etc > default > grub

majd a megnyitás admin joggal lehetőséget választod (az egér jobb gombos menüben). Ekkor az asztali környezeted alapértelmezetten használt, szöveges fájlokhoz rendelt grafikus szövegszerkesztője nyitja meg a szövegfájlt. A felhasználói jelszavadra mindkét esetben szükséged lesz, hiszen rendszerfájlt felhasználóként csak olvashatsz, de most írásra (szerkesztés) van szükség.

A nano szövegszerkesztőben a kurzor nyilakkal navigálsz. Gondolom, már összebarátkoztatok.

Keresd meg ezt a szövegtömböt:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

Kettő új sor kerül a szövegtömbbe, és egy sor megjegyzésbe kerül ...

Változtasd meg a kiemelt sorokat erre a tartalomra:

#GRUB_DEFAULT=0
GRUB_DEFAULT="Speciális beállítások ehhez: Debian GNU/Linux>Debian GNU/Linux, Linux 4.9.0-9-amd64 verzióval"
GRUB_SAVEDEFAULT=true
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

Magyarázat:

A GRUB_DEFAULT sor eredeti beállítása 0. Ha ez a beállítás érvényben van, akkor az alapértelmezetten beállított kernellel indul a rendszer. A könnyebb érthetőség kedvéért: alapértelmezett kernel a telepített legújabb, vagy másképp fogalmazva, a legmagasabb verziószámú kernel. Logikus megoldás, hiszen a rendszer induljon csak a legújabb, legfrissebb kernellel. A menüpontok listájában is az első. Sorszáma a GRUB beállításban a 0. Erre a beállításra most azonban éppen, hogy nincs szükség, mert egészen mást szeretnénk. Megjegyzésbe (komment: #) tesszük, azaz kikapcsoljuk. A # a sor elején ezt jelenti.

Mit használunk helyette? Az új beállítást a

grep menuentry /boot/grub/grub.cfg

parancs kimenete súgja meg.

Már említettem, nekem ez kell (kiemeltem a lényeget),

    menuentry 'Debian GNU/Linux, Linux 4.9.0-9-amd64 verzióval' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.9.0-9-amd64-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {

... a menuentry.

Azonban ez a menüpont egy másik menüpont alatt található (kiemeltem a lényeget), úgyhogy ez is kell nekünk a kimenetből,

submenu 'Speciális beállítások ehhez: Debian GNU/Linux' $menuentry_id_option 'gnulinux-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {

... a submenu.

Mindez példa, tehát azt a két lehetőséget, menüpontot nézd, ami a te rendszered alatt létezik.

A kettőből áll össze az új beállítás. Íme:

GRUB_DEFAULT="Speciális beállítások ehhez: Debian GNU/Linux>Debian GNU/Linux, Linux 4.9.0-9-amd64 verzióval"

A beillesztett szöveg szóközöket tartalmaz, ezért a UNIX szabályai szerint a " karakterek határolják. A " a Shift és a 2 billentyűk megközelítőleg egyszerre történő lenyomásával gépelhető be.
A bemásolt két sor között jobbra kacsacsőr karaktert kell alkalmazni. A > (jobbra kacsacsőr) a jobb Alt és az Y karakterek megközelítőleg egyszerre történő lenyomásával gépelhető be.

A GRUB_SAVEDEFAULT beállítás lehet true (igaz / használva) vagy false (hamis / kikapcsolva). Ez egy új sor, ha igazra állítod (true) akkor mindig az utolsó kikapcsolás vagy újraindítás előtt használt kernellel indul el a rendszer. A másik (lentebb részletezett) beállításhoz szükséges, itt automatikusan bemásoltam és alkalmaztam. Hátrányát nem látom, és nem ütközik az elvárással.

Az itt látható sorokat ne szerkeszd,

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

... egyáltalán nem biztos, hogy ugyanez a rendszered saját beállítása. A Linux terjesztések GRUB beállításai különbözőek.

Ott tartottunk, hogy van ez az új beállítás, változtatás (példa),

#GRUB_DEFAULT=0
GRUB_DEFAULT="Speciális beállítások ehhez: Debian GNU/Linux>Debian GNU/Linux, Linux 4.9.0-9-amd64 verzióval" GRUB_SAVEDEFAULT=true
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

... menteni kéne.

A grafikus szövegszerkesztővel a mentés művelete nem nehéz.
A nano szövegszerkesztő használatakor:

Ctrl + O, és Enter, majd
Ctrl + X

Érvényesítsd kell az új beállítást (terminál):

sudo update-grub

Indítsd újra a rendszert:

sudo systemctl reboot

A változtatás a rendszer újraindítása után lép érvénybe.

Azt hiszem, egy billentyűt meg kell nyomnod a rendszer indulása előtt. Erre egy üzenet figyelmeztet majd.

Megjegyzés: kicsit később kiderült, hogy ez egy hiba következménye. Részletek a blog végén. [*]

Ellenőrzés:

uname -r

Minden rendben:

4.9.0-9-amd64

Legutóbb használt menüpont beállítása

Ha valamilyen okból mindig az utolsóként használt kernellel használnád a rendszert ...

Ha eddig nem készítettél biztonsági másolatot a grub fájlról, tedd meg most:

sudo cp /etc/default/grub /etc/default/grub.ORIG

Nyisd meg szerkesztésre az eredeti grub fájlt:

sudo nano /etc/default/grub

... mindezt megteheted úgy is, ha a fájlkezelőben rákeresel a fájlra,

Fájlrendszer > etc > default > grub

majd a megnyitás admin joggal lehetőséget választod (az egér jobb gombos menüben). Ekkor az asztali környezeted alapértelmezetten használt, szöveges fájlokhoz rendelt grafikus szövegszerkesztője nyitja meg a szövegfájlt. A felhasználói jelszavadra mindkét esetben szükséged lesz, hiszen rendszerfájlt felhasználóként csak olvashatsz, de most írásra (szerkesztés) van szükség.

A nano szövegszerkesztőben a kurzor nyilakkal navigálsz. Gondolom, már összebarátkoztatok.

Keresd meg ezt a szövegtömböt:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

Változtasd meg a kiemelt sorokat erre a tartalomra:

#GRUB_DEFAULT=0
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

Csak a kiemelt szöveget szerkeszd. A többi beállítás a te rendszered alatt egész más is lehet, ne változtasd meg azokat. A Linux terjesztések GRUB beállításai különbözőek,

Magyarázat:

A GRUB_DEFAULT sor eredeti beállítása 0. Ha ez a beállítás érvényben van, akkor az alapértelmezetten beállított kernellel indul a rendszer. A könnyebb érthetőség kedvéért: alapértelmezett kernel a telepített legújabb, legmagasabb verziószámú kernel. Logikus beállítás, hiszen a rendszer induljon csak a legújabb, legfrissebb kernellel. Erre a beállításra most azonban éppen hogy nincs szükség, mert egészen mást szeretnénk. Megjegyzésbe (komment: #) tesszük, azaz kikapcsoljuk. A # a sor elején ezt jelenti.

Kettő új sor kerül a szövegtömbbe ...

Az GRUB_DEFAULT új beállítása a saved (mentett),

GRUB_DEFAULT=saved

és arról, hogy ez biztosan működjön, a GRUB_SAVEDEFAULT sor

GRUB_SAVEDEFAULT=true

true (igaz / bekapcsolva) beállítása gondoskodik, azaz a mentés be lesz kapcsolva.

Ott tartottunk, hogy van ez az új beállítás, változtatás (példa),

#GRUB_DEFAULT=0
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

... menteni kéne.

A grafikus szövegszerkesztővel a mentés művelete nem nehéz.
A nano szövegszerkesztő használatakor:

Ctrl + O, és Enter, majd
Ctrl + X

Érvényesítsd kell az új beállítást (terminál):

sudo update-grub

Indítsd újra a rendszert:

sudo systemctl reboot

A változtatás a rendszer újraindítása után lép érvénybe ...
De itt még nincs vége a teendőknek.
Hiszen a rendszer újraindításakor itt

Speciális beállítások ehhez vagy Advanced options for Debian GNU/Linux

egyszer ki kell választanod azt a menüpontot, kernelt, amelyiket hosszú távon használnál. Innentől kezdve az utolsóként kiválasztott kernelt használja a rendszer. Ez a beállítás elvész, ha egy másik menüpontot, kernelt választasz ki. Innentől kezdve ismét (talán mondanom sem kell, hogy nem meglepő) az utolsóként kiválasztott kernelt használja a rendszer. Egészen az új változtatásig.

Ellenőrzés:

uname -r

A leírásban segítséget nyújtott: https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html

Enjoy :-)

Remélem, így már inkább szebb lesz a napod, mint nem:  https://www.youtube.com/watch?v=O4irXQhgMqg

A grubenv fájl hibája

[*] Talán a szerkesztés következménye, talán nem, de a következő rendszer indításkor aprónak tűnő hibát kaptam. Írtam korábban, hogy meg kell nyomni egy billentyűt és így indul el a rendszer. Nem feltétlen kell nyomkodni semmit, mert amikor az időzítés (5-10 másodperc) letelik, a rendszer automatikusan elindul. Csupán nagyon siettem. Ettől függetlenül egy hibáról van szó. A pontos hibaüzenet:

hiba: a környezetblokk túl kicsi
[...]
Nyomd meg valamelyik billentyűt a folytatáshoz...

Angolul:

error: environment block is too small.
[...]
Press any key to continue...

Megoldás:

Új grubenv fájl kell készíteni ...

Nevezd át a létező, eredeti grubenv fájl,

sudo mv /boot/grub/grubenv /boot/grub/grubenv.ORIG

a törlés helyett. A törölt fájl menthetetlen, ha volt baja, ha nem.

Készíts egy új grubenv fájlt, amely lehet „üres” (én is így tettem, hátrányát nem tapasztaltam):

sudo grub-editenv /boot/grub/grubenv create

... természetesen a fájl nem üres, csak nincs benne a beállításra vonatkozó sor. Úgy egyáltalán.

A másik megoldás a set kapcsoló lenne ... (lásd lentebb a kézikönyv ide vonatkozó részét)

De utóbbira nem volt szükség, mert a GRUB beállításainak frissítése,

sudo update-grup

és egy rendszer újraindítás

sudo systemctl reboot

után visszakerül a fájlba a környezeti változó (environment variables).
Amely nem a régi, azaz korábbi „főmenüs”, hanem az újonnan, általam beállított.

Lefuttattam a

sudo dpkg-reconfigure grub-pc

parancsot is. Nemcsak a grub-pc lehet azonban a telepített GRUB alkalmazás. Vélhetően nem ez segített (grubenv), de másoknak (úgy 7-8 éve) igen. Itt hagyom jegyzetnek. A parancs futtatásakor csupán néhány kérdésre kell válaszolni (nem nehezek), és ezzel a művelettel a grub-pc alkalmazást akár az új beállításokkal használhatod. Kernel paramétereket is meg lehet adni vele.

Olvasom a fájlt,

less /boot/grub/grubenv

íme (ha is nincs benne az első sor, vagyis a vezérlés, azért van benne más tartalom):

# GRUB Environment Block
saved_entry=gnulinux-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f>gnulinux-4.9.0-9-amd64-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f
###############################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################
/boot/grub/grubenv (END)

A less-féle olvasásból a kilépés a Q billentyűvel történik.

Lehet így is listázni (talán ez a célszerűbb):

sudo grub-editenv list

A kimenet (megegyezik a less által olvasottal):

saved_entry=gnulinux-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f>gnulinux-4.9.0-9-amd64-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f

A grub-editenv kézikönyve:

man grub-editenv

Részlet belőle:

grub-editenv - edit GRUB environment block

SYNOPSIS
       grub-editenv [OPTION...] FILENAME COMMAND

DESCRIPTION
       Tool to edit environment block.

              Commands:

       create Create a blank environment block file.

       list   List the current variables.

       set [NAME=VALUE ...]
              Set variables.

       unset [NAME ...]
              Delete variables.

       -?, --help
              give this help list

       --usage
              give a short usage message

Térjünk vissza az eredeti történethez ...

A végleges megoldásra rátalálásban sokat segített, azaz igen elgondolkoztatott egy GRUB frissítés

sudo update-grub

üzenete. Íme:

GRUB beállítófájl előállítása…
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Megtalált linux lemezkép: /boot/vmlinuz-5.0.0-19.1-liquorix-amd64
Megtalált initrd lemezkép: /boot/initrd.img-5.0.0-19.1-liquorix-amd64
Megtalált linux lemezkép: /boot/vmlinuz-5.0.0-18.1-liquorix-amd64
Megtalált initrd lemezkép: /boot/initrd.img-5.0.0-18.1-liquorix-amd64
Megtalált linux lemezkép: /boot/vmlinuz-4.19.0-0.bpo.5-rt-amd64
Megtalált initrd lemezkép: /boot/initrd.img-4.19.0-0.bpo.5-rt-amd64
Megtalált linux lemezkép: /boot/vmlinuz-4.9.0-9-rt-amd64
Megtalált initrd lemezkép: /boot/initrd.img-4.9.0-9-rt-amd64
Megtalált linux lemezkép: /boot/vmlinuz-4.9.0-9-amd64
Megtalált initrd lemezkép: /boot/initrd.img-4.9.0-9-amd64
Figyelem: Ne használja a régi „Debian GNU/Linux, Linux 4.9.0-9-amd64 verzióval” címet a GRUB_DEFAULT értékénél, használja ezeket: „Advanced options for Debian GNU/Linux>Debian GNU/Linux, Linux 4.9.0-9-amd64 verzióval” (a 2.00 előtti verzióknál) vagy „gnulinux-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f>gnulinux-4.9.0-9-amd64-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f” (2.00 vagy későbbi verzióknál)
kész

Gondolkodtam még a grubenv fájl szerkesztésén. Erre kitérek még, lapozz vissza!

A grubenv fájl itt található a fájlrendszerben:

/boot/grub/grubenv

Nem a várt eredményt hozta, illetve, a további próbálkozás helyett megoldottam máshogyan. A leírás erről szól.
Forrás, ötlet: https://www.gnu.org/software/grub/manual/grub/html_node/Environment-block.html#Environment-block

A leírásomban is említett ID-s megoldással próbálkoztam. Kizárt a rendszer, bár igen egyszerű volt megoldani. Kikapcsoltam a gépet, és az indításkor kiválasztottam a legfelső menüpontot a GRUB-ban. A környezeti változó (a grubenv fájl tartalma) visszaállt a korábbi beállításra. Itt egyszer másoltam be az ID-t egyébként.

Amúgy mindkét ID ugyanaz:

    menuentry 'Debian GNU/Linux, Linux 4.9.0-9-amd64 verzióval' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.9.0-9-amd64-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {
submenu 'Speciális beállítások ehhez: Debian GNU/Linux' $menuentry_id_option 'gnulinux-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f' {

Vélelmezem, a grub fájlban használva az ID-k használata is működhet:

Figyelem: Ne használja a régi „Debian GNU/Linux, Linux 4.9.0-9-amd64 verzióval” címet a GRUB_DEFAULT értékénél, használja ezeket: „Advanced options for Debian GNU/Linux>Debian GNU/Linux, Linux 4.9.0-9-amd64 verzióval” (a 2.00 előtti verzióknál) vagy „gnulinux-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f>gnulinux-4.9.0-9-amd64-advanced-75b066d4-ffa5-4e5c-a77b-cee151ac284f” (2.00 vagy későbbi verzióknál)

Ebben a bejegyzésben
https://linuxmint.hu/forum/kernel-frissites-rendszerinditasi-problema
szó esett még a menüpont sorszámmal történő beállításáról. Például így:

#GRUB_DEFAULT=0
GRUB_DEFAULT=10

Azt hiszem, ezen az úton jelenleg nem lehetséges a beállítás. Ebben megerősít, hogy egyes fórumokon ugyanerről olvastam.

Továbbá, nálam a grub-set-default parancs beállítás sem működött. Példa:

sudo grub-set-default 10

Vajon miért nem működik egyik sorszámozós megoldás sem?
Vélhetően azért, mert a grub.cfg fájl manapság már alapvetően nem tartalmaz sorszámozást a menüpontok felsorolásában.
Ellenőrizd:

cat /boot/grub/grub.cfg

Hozzászólások

kimarite képe

Grub Customizer

@#1.1.1.2.1 #2 Azt kéne megnézni, hogy hol a GRUB Customizer mentési fájl és mi van benne. Én nem merem. :-D

... igazából elég régebben próbáltam a BURG-ot. Nagyon nem jött be. :-)

Értékelés: 

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

Grub Customizer

#2.1 Egy régebbi leírás: https://ubuntuforums.org/showthread.php?t=1664134&s=43071a1b251c8eb7958f...
Kettő: https://www.dedoimedo.com/computers/grub-customizer.html

Értékelés: 

0
Még nincs értékelve

Grub Customizer

#2.1 Azt hiszem, hogy nincs ilyen fájl, script alapján léttrehoz egy leirást (gondolom temp-ben) és esetleg onnan lehet a grub-ba menteni.  De majd az okosabbak úgyis kijavitanak, ha rosszul gondolom.

Értékelés: 

0
Még nincs értékelve

Grub Customizer

#2.1.2 Az /etc/grub.d/backup könyvtárban találhatóak a scriptek, a mentett grub.cfg fájlok stb.

Értékelés: 

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

Grub Customizer

#2.1.2.1 Valahova át kéne másolni ezeket a fájlokat, majd amikor elromlott (nem kívánom), a diff paranccsal megnézni a különségeket. És gondolkodni. Ha jól emlékszem egy fájlkezelő plugint használsz a diff helyett, a célnak az is megfelel.

Értékelés: 

0
Még nincs értékelve

Grub Customizer

#2.1.2.1.1 Jó a diff, de azért használom a Meld-et, mert a fájlon belül található különbözőségeket egyenként is át tudom másolni a célfájlba. Mindezt grafikus felületeten, könytárakat is össze tud hasonlitani, terminálból is indithatő. Érdemes kipróbálni.

Értékelés: 

0
Még nincs értékelve

Grub Customizer

#2.1.2.1.1 Voltaképp azért készítettem két képet, mert az első képen az inditható, jó grub van, a másikon pedig ajavított, a sok hülyeséget összehordozott, törlésre kijelölt menüelemek. de hogy ezt honnan szedte?! Viszonylag strapás, mert sok elem, az alfa verzióknál sok a kernel.

Értékelés: 

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

Grub Customizer

#2.1.2.1.1.1 #2.1.2.1.1.2 Jók a képek,
https://www.dropbox.com/s/7c82lfyorebtyxp/grub_customizer_2019-05-27_17-...
https://www.dropbox.com/s/8cbvlodxbj38gsi/grub_customizer_2019-05-27_17-...
de a második képet te látod egészében.

Én azt látom, hogy csak az új Ubuntuval van gondja a Grub Customizer alkalmazásnak. És a nagyon új Ubuntu kernelekkel is talán? Az Ukuu tette fel azokat vagy a rendszer? Azon kernelekkel van gond, amit az Ukuu tett fel? Az új Ubuntu mennyiben más, mint a többi rendszer? Más a megvalósítás a GRUB elhelyezésében (sdxy)? Másik lemezen van? Objektívan kéne elemezni a miérteket.
Persze, te látod, milyen rendszerekkel van gondja, természetesen, ha kijelenthető valamilyen osztályozás ezen tekintetben.

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

Linux Mint 20.1 xfce a paciens, és a kernelfrissítés a gyanúsított.
(Meg kellene néznem, hogy ha az előző kernellel indítok, akkor láthatóvá válik-e ismét az sdb2 OS, ami egy Win 10 példány.)

Elindítottam a grub-customizert. Ő sem vette észre ezt az OS-t.
Hova menti az előző grub bejegyzéseit a Linux? Már ha menti.  Hogyan állíthatom vissza? (Nem akarózik egy Timeshift pillanatképre visszalépni.)
Jobban ki kellene tanulnom ezt a grub-ot. Itt van előttem pedig. Fentebb is olyan jó kis leckék vannak. Namajdegyszer.

De hogy az magamtól nem jutott eszembe, hogy gyártsak egy grub.ORIG példányt magamnak baj esetére - pedig már ezerszer volt vele baj.
 

Elég, ha szimplán kreálok egy új menüpontot neki?

 

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#3 BIOS felüléteten látszik a második lemez? Én arra gyanakszom, hogy HW gond van. Kábel, táp, akármi.

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#3.1

Nos, a hardverproblémát én élből elvetettem. Azért, mert ominózus eszköz (HDD) felcsatolható, látja az inxi -F, látja a gparted. Csak a grub nem látja.

Hozzászokattál azonban, hogy alaposabban gondoljam át a javaslataidat, mert eddig valahogy átjött valami a hibakereső szemléletedből, és már többször a te útmutatásod segített megoldáshoz.
Úgy tűnik, hogy most is az következik - bár a megoldás még nincs meg.

Mert miért nem látja akkor a grub? Bootoltam egy natív pendrive Mint OS-t. És ő se látja.
No, ez megtorpantott. Miért nem látja? Nézzük ezt meg alaposabban. Ott van egyáltalán?

Hát nincs ott. A Disk2-n (ami ominózus sdb1) hiányzik egy partíció. Eltűnt. Ott is egy 50MB rendszer számára fenntartott partíciónak kellene lennie. Persze, hogy nem látja a grub.
Most aztán fel van adva a lecke, gondolkodhatok rajta, hogyan tűnhetett el? Semmi olyan műveletet nem végeztem, ami ilyen veszélyt rejthet. Csak frissítettem egy Linux Mintet egy másik lemezen, ezután tűnt el. Logikailag semmi köze a frissítéshez.

 

 

És vissza kellett kanyarodnom ide:
" Én arra gyanakszom, hogy HW gond van. "
HDD hiba lenne?

Nem tudom.
Tulajdonképpen nagy baj nincs, mert semmi adatom azon a partíción nincs. Csak egy frissen telepített, szűz Win 10 valamennyire bekonfigurálva, testreszabva. A bajt én azért érzékelem nagyobbnak ennél jóval, mert hogyan tűnt el? Negyven év alatt én még soha nem jártam úgy, hogy egy komplett partíció eltűnjön, pedig volt már ezer dolgom partíciókkal.
Egyébként ha jobban megnézzük, hát nem a rendszer számára denntartott 500 megás partíció tűnt el, hanem mellőle az OS telepítési partíciója - már a felhasznáét adatokból következtetve.Hiszen 3-4 gigabájton még egy puppy Linux se fér el talán, a Win 10 üresen is úgy 40 gigát kóstál. A Disk2 első partíciójának úgy kellene kinéznie, mint a Disk1-nek.

Értékelés: 

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

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#3.1.1 Én akkor gyanakodnék, miután a kimenetek is meglepnének:

sudo fdisk --list
sudo parted --list

Értékelés: 

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

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#3 Linux Mint 20.1 xfce a paciens, és a kernelfrissítés a gyanúsított.
(Meg kellene néznem, hogy ha az előző kernellel indítok, akkor láthatóvá válik-e ismét az sdb2 OS, ami egy Win 10 példány.)
Elindítottam a grub-customizert. Ő sem vette észre ezt az OS-t.

Szóval ..., én ezt sajnos GRUB Customizer kavarásnak érzem. De akármi is lehet, csak kevés az esély rá. Nagyon kevés. Addig rendben, hogy a GRUB Customizer mindenféle Linux terjesztést kezel, de úgy tűnik, bele lehet kavarni.

#3.1.1.1.1 Ja, láthatóan EXT4-re van formázva.

/dev/sdb2 1178224640 1953523711 775299072 369,7G 83 Linux

Windows nem lakhat ilyenen egyelőre.

1) A könyvtárszerkezetet nézted, mi foglal 369.7 GB-ot?
2) Ha Linux van ott, akkor mit szól a chroothoz?

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#3.1.1.1.1.1

Anamnézis:

Vettem fillérekért (16 E pénz) jelen HP vasat valami W10 home telepítéssel. Mivel egy 300 gigás 2 collos HDD volt benne,, vettem hozzá egy 1TB WD HDD-t. (Mindent a hardveraprón.) Munkagépnek szántam.
Ekkor az 1 TB HDD-t elfeleztem. 500 GB-t meghagytam a vindóznak, 500-at ext4-re formáztam.

Így lett sdb1 NTFS
            sdb2 EXT4

sdb1-re feltelepítettem a W10-et. Ő létrehozott magának egy 50 GB rendszer számára fenntartott partíciót, és feltelepült. Én nem kísértem figyelemmel, hogy az sdb2 ekkor módosult-e sdb3-ra, mert nem is volt még Linux a gépen (előbb ugye a redmondit telepítjük).

Feldugtam a vasba egy öregecske harcedzett Samsung 750 SSD-t. Létrehoztam rajta egy 8 GB swap-et, a maradékot elfeleztem a /, és a /home számára, majd rátettem egy Mint 20.1 xfce-t.

Hogy külön meghajtóra kerüljenek a Timeshift pillanatképek, Lecsíptem számára a WD HDD ext4 partíciójából 100 GB-ot, és a Mint belakása után rögtön csináltam is ide egy pillanatképet. A maradék ext4 partíció üres, azt csak a későbbiek számára tartalékoltam, hogy akár adatmentéseket tegyek oda, akár tegyek egy komplett Linuxot is, ha arra éledne szükség.

A grub-customizer-t feltelepítettem ugyan, de emlékeim szerint nem használtam, vagy ha igen, akkor az teljesen jól tette a dolgát. Ennek a megmozdulásomnak annyiból van relevanciája, hogy frissítéskor a grub-customizer is automatikusan frissül. Ráadásul a fejlesztői igen sűrűen módosítják, és nagyon nem bölcsen frissítéskor azt automatikusan le is futtatják, és felíratnak vele egy új grub menüt, ami hitük szerint immár jó, vagy mégjobb. (De ritkán az. Többnyire bugyután kavar, és utána reszelgetni kell rajta újfent.)

Elkövettem azt a hibát, hogy frissítés előtt a grub-customizer-t nem tettem a nem frissítendők közé. (Tanultam ebből a figyelmetlenségemből. Lehet a grub-customizert használni, de csak akkor szabad kiírni az MBR-be, ha csekkoljuk, hogy rendben van-e. Miként egy Windows telepítés során, itt is mazochista attitűd a kényelmes kontrollálatlan next, next, next típusú levezénylés.)

Tehát:

"1) A könyvtárszerkezetet nézted, mi foglal 369.7 GB-ot?
 2) Ha Linux van ott, akkor mit szól a chroothoz?"

1) Üres ext4 partíció.
2) Ergo nincs ott Linux.

Viszont most észrevetetted velem, hogy nem üres az.
cca 23 GB le van foglalva rajta.
Az a gyanúm, hogy ez (a méretéből ítélve) épp két Timeshift pillanatkép lesz. (Mert ugye az eredetileg kijelölt sdb3 a kavarás után ez lett.)
Az imént meg is akartam gyorsan nézni. Segítenél, miként tehetem meg?
Grafikusan próbálkoztam. Ha a fájlkezelőt root-ként nyitom meg, oda se találok biztonsággal, mert nem írja ki az azonosítót végigolvashatóan.

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#3.1.1.1.1

Jól értelmezem én itt a középső sort?
Szám Kezdet Vég Méret Típus Fájlrendszer Jelzők
1 1049kB 498GB 498GB primary ntfs boot
3 498GB 603GB 106GB primary ext4
2 603GB 1000GB 397GB primary ext4

sdb3 volt, sdb3 maradt? (A Timeshift ide ment majd automatikusan.)
Írtam én erről nemrég egy gondolatot, de nem jelent meg a bejegyzésem sehol, amit nem értek. (Magamnak válaszoltam. Olyat nem lehet?)

Értékelés: 

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

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#3.1.1.1.1.2 sdb3 volt, sdb3 maradt

Igen, maradt az sdb3!
Nehéz követni...
Illetve ez volt (idézlek):
-- eltűnt az sdb2-ről a Windows, (itt Linux a formázás tényleg)
-- valamilyen, számilag/névileg nem tisztázott (sdXY?) harmadik partícióra ment a Timeshift.

Utóbbi esetben elindítom a Timeshiftet, és ellenőrzöm ... a partíciót.
Most mennem kell (nem világgá ;)).

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#3.1.1.1.1.2.1

Meg tudom innen nézni, hogy mi vab az sdb2-n?
Ha igen, hogyan?

Értékelés: 

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

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t

#3.1.1.1.1.2.1.1 Tallózás? Biztos meg lehet nézni a mentések helyét. Ott van előtted a program! :)

A legegyszerűbb út, ha megnyitod az sdb2-t a befűzés helye szerint. És az sdb3-at is.
Én most kiszállok egy időre, mert nagyon nem értem, hogy egyszer azt írod az sdb2-n volt a Windows 10, most egész mást. A Timeshift mentések helyének korábban az sdb3-t jelölted meg,most egész mást mondasz. Elég nagy zavart látok, amit csak te tudsz megmagyarázni. Gondolkodj... .
Mindkét partíciót meg lehet nyitni a fájlkezelővel a felesleges körök helyett.
Kérdések most:
-- hova menti a pillanatképeket a Timeshift? Nézd meg az alkalmazásban!
-- fájlkezelő: mi van az sdb2 és az sdb3 partíciókon?

Értékelés: 

0
Még nincs értékelve

Tiszta víz a pohárba

#3.1.1.1.1.2.1.1.1

Tiszta víz a pohárba.

Magam is kiszálltam egy időre, hogy tanácsodat megfogadva higgadtan gondolkozzak.
Igazad van, hogy zavar van a párbeszédekben. Megítélésem szerint ez abból fakadt, hogy nem fogalmaztam félre nem érhetően.

- ennek elébe megyek egy képpel, ami nagyon jól illusztrál
- megfogalmazom pontosan a célt, és ennek érdekében
- konkrét kérdéseket teszek fel

Az alábbi ábrán a halványzöld mezőben azt rajzoltam le, hogy számításaim szerint hogyan nézett ki ominózus sdb meghajtó (Ami egy 1 TB HDD).
A halvány piros területen az látható, hogy mi van most rajta.
A foglalt és szabad területeket egyelőre nem rajzoltam be, hogy ne bonyolítsam egyből ismét. De ezt fogom majd részletezni, mert a zavar itt jelent meg.

Az ábrán jól látszik, hogy a Win 10 az sdb2-n volt. Amikor múlt időben fogalmazok, akkor a zöld mezőbeli ábra legyen a default, amikor jelen időben, akkor a piros.
Így elkerülhető az a félrecsúszás, hogy megjegyezted: Az sdb2-n nem lakhat Windows, hiszen az EXT4 partíció. Így azonban érthető, hogy sdb2-n volt, ami EXT4 lett.
(Nem is tudom, miként lehetett volna ezt ábra nélkül megfogalmazni úgy, hogy ne legyen félreérthető, de ne is legyen fárasztó követni.)

A jelen épp a helyfoglalások miatt igen kaotikus. Az általad megfogalmazott zavart éppen ez okozta.

A célom a helyzet pontos kiderítése. Azért, hogy úgy tudjam levezényelni a rendbetételét, hogy az megnyugtató legyen, és később ne járjak úgy, hogy bízok a Timeshift helyes működésében, mikor pedig nem szabadna.
(Egyáltalán nem kilátástalan ez egyébként - már született is terv a fejemben, de jó lenne egy nálam sokkal hozzáértőbb megerősítése.)

Az alábbi képen éppen az ellentmondások kiabálnak. Én azt hittem, hogy felnőttem már ahhoz, hogy oda navigálok Linux alatt, ahova akarok, és azt ellenőrzök, amit akarok.
Nos, nem nőttem fel. Jelen ellentmondásos helyzetben nem tudom eldönteni, hogy melyik kimenetnek higyjek, és melyiknek nem.

Megfigyelhető, hogy a lefoglalt területek egyáltalán nem egyértelműek.
A rootként megnyitott fájlkezelőben az látszik, hogy 328 GB szabad a 346,5 GB-ból.
Ez jókora lefoglalt terület.
A sötét, rootként megnyitott terminálablak azt mutatja, hogy egyetlen rejtett mappa van az eszközön, amibe belépve az látszik, hogy az meg üres.

Feltettél két kérdést:

'-- hova menti a pillanatképeket a Timeshift? Nézd meg az alkalmazásban!
 -- fájlkezelő: mi van az sdb2 és az sdb3 partíciókon?'

Fent írtak miatt nem tudom a második kérdésedet megválaszolni, legfeljemm így:
Az sdb2-n van egy üres könyvtár, aminek a mérete vagy húsz gigabájt. De ezzel egyikőnk se tud kezdeni semmit.

A második kérdésedre itt egy már valahol betett kép.

Csak kérdés, hogy ez tiszta sor vajon? Hihető, hogy a Timeshift jól fogja lekezelni a jelenlegi sdb3-at a későbbiekben. Jó valószínűséggel igen, ám hiányzik a bizonyosság. (Mert mi történik, ha újra partícionálok, és visszateszem a Windows-t oda, ahol volt?)

Egyszóval ezt a jelen kaotikus helyzetet fel akarom arra használni, hogy elemzem, mert vissza nem térő alkalom, ha most felindulásomban egy huszárvágással rendet csapok törléssel, újra felépítéssel - én pedig okosodni szeretnék butaságomban.

Célom tehát pillanatnyilag első körben minél többet kideríteni a leányzó jelen fekvéséről.
És a káoszt tudom még fokozni további kérdésekkel, de azt most beláthatóan nem bölcs megtennem, így se túl egyszerű, amit eddig felvetettem.
A gyanúm az, hogy megsérült a partíciós tábla. Nem tartom valószínűnek, hogy ez valamiféle grub-customizer kavarás, habár kizárni se merem. A partíciós tábla nem tud megváltozni, ha akarattal nem változtatjuk meg. A Grub-Customizer miért tenne ilyet? Ő oda legfeljebb tájékozódni, olvasgatni jár. Elég, ha egytlen bit átbillen. Például egy olvasás közbeni áramingadozás közben.
Tudom, hogy aki nagyon tud, az ki tudja számolni, melyik az a bit. De én nem tudok nagyon. És talán ha tudnék is, hatalmas munka lenne nyomon követni, felderíteni, és helyreállítani. Ez nem a Pentagon kényesen fontos gépe, csupán egy nemrég belőtt, és már stabilnak érzett szerény munkagép nélkülözhetetlen adatok nélkül.

Most mennem kell egy hosszabb, fontosabb munkára.

(A helyesírási hibákért elnézést, és köszönöm a figyelmet!)

Értékelés: 

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

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t

#3 De hogy az magamtól nem jutott eszembe, hogy gyártsak egy grub.ORIG példányt magamnak baj esetére - pedig már ezerszer volt vele baj.

Inkább a chroottal ildomos megcsinálni, de kipróbálhatod a futó rendszeren is (esetleg).

sudo update-grub

... de mindezt csak, ha „purgáltad” a Grub Customizert, azaz a Synapticban csomagkezelőben például a teljes eltávolítását választottad (ami a beállítások törlésével jét együtt). Amúgy:

A GRUB újratelepítése, beállítása - Live Rendszer alól (LiveCD/DVD/USB Stick)

Szerk.: én megértem a Grub Customizeres „őrületet”, de az eredeti leírás (a blog) nagyon nem az alkalmazás törlése utáni állapotról szól. Hanem egész másról, vagyis arról, ha van egy rendszer, ami „tiszta sor”, és ezen kéne beállítani az alapértelmezett menüpontot. Semmi gond... ;)

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t

#3.2

#3.2 A Grub Customizer eltávolitásával egyetértek, ha nem esetleges hardverhibáról van szó. Nálam Legacy telepitésű rendszeren van telepitve sda-ra Windows, Arco, Ubuntu LTS, Mint Xfce, Bunsenlabs. A Grub az Arcon a lemezre, a többi particióra van telepitve, praktikus megfontolásból, úgyis az Arch frissül a legtöbbször, kevesebbszer kell kézzel az update-grub.

Ezenkivül van még külső lemezen (sdb) egy MXLinux és az aktuális Xubuntu daily (jelenleg Hirsute) fut. Az MX Grubja lett telepitve erre a lemezre, az alfa verzió pedg particióra. Az sda-n lévő grub-ból inditom a rendszert, azt mindent lát.

Más.  A grub.cfg "szerkeszteni tilos" rendszerével megyezném, hogy néha muszáj szerkeszteni, például akkor, ha Manjaro-t telepitesz, ő tökéletesen lekezeli a rendszert az ő kicsit sajátos grubjával, de ha más rendszerről akarod inditani (akár a rokon Arch-ról) bizony kernel panic a vége.

Értékelés: 

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

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t

#3.2.1 A grub.cfg "szerkeszteni tilos" rendszerével megyezném, hogy néha muszáj szerkeszteni, például akkor, ha Manjaro-t telepitesz, ő tökéletesen lekezeli a rendszert az ő kicsit sajátos grubjával, de ha más rendszerről akarod inditani (akár a rokon Arch-ról) bizony kernel panic a vége.

A grub.cfg fájl szerkesztésének tiltása például a Debian-alapú rendszerekre érvényes (Linux Mint, LMDE), egyféle sajátosság, hiszen ezeken a rendszereken az update-grub alkalmazás frissíti a GRUB (grub/grub.cfg fájlok) beállításait.

-- Windows rendszereket keres és fedez fel

sudo os-prober

-- a megtalált vagy létező (ha nincs Windows) információk alapján frissíti a grub fájlt (/etc/default/grub), amely frissítés egyben a grub.cfg fájlba (/boot/grub/grub.cfg) is beleíródik:

sudo update-grub

... a grub fájl paraméterezési lehetőségei (a bejegyzésben leírtak is ilyenek) gondoskodnak arról, hogy a grub.cfg fájlban is minden a helyére kerüljön. Vagyis, a paraméterezés használatával gondoskodik a változtatásokról a felhasználó a grub.cfg fájl neki tetsző tartalmáról (végül frissíti a grub fájlt az új beállításokra az update-grub parancs futtatásával).

Az alkalmazás kézikönyve és tartalma:

man update-grub

UPDATE-GRUB(8)              System Manager's Manual             UPDATE-GRUB(8)

NAME
       update-grub, update-grub2 - stub for grub-mkconfig

SYNOPSIS
       update-grub

DESCRIPTION
       update-grub  is a stub for running grub-mkconfig -o /boot/grub/grub.cfg
       to generate a grub2 config file.

SEE ALSO
       grub-mkconfig(8)

                                  April 2009                    UPDATE-GRUB(8)
 Manual page update-grub(8) line 1/16 (END) (press h for help or q to quit)

Más rendszerek felhasználói közvetlenül szerkeszthetik közvetlenül a grub.cfg fájlt (például Arch-alapú rendszerek). Az update-grub alkalmazást nem, hanem a grub-mkconfig alkalmazást használják.

Értékelés: 

0
Még nincs értékelve

Pár szösszenet

Igen a grub.cfg-t erősen szerkesztgeni kell, pláne ha Manjaro az illető és volt neki egy kernelfrissítése.
Mert akkor máshonnan indítva fakereszt és akkor a fő os grub.cfg-be át kell írni az intel-ucode.img-t a Manjaroban aktuális initramfs-xx.xx.xx-re.És akkor lehet bootoltatni a Manjarot, amíg nem lesz neki újabb kernelverziója.

Az oké hogy eltűnt a windows 50 megás partíciója, de hova, akkor a lemez elején kéne lenni egy ekkora parícionálatlan terplenek. És az meg nincs.
Nézd már meg a diskpart -tal,
list disk
select disk 1

Habár ha a gparted nem látja, akkor a diskpart se fogja.
Szerintem, mivel az used, azaz a foglaltság nulla % és ez eléggé valószínűtlen egy Windows8-tól, vagy  Redmondba csodákra képesek smiley , valami valamikor valamiért hozzácsapta a az 50 megást a w8-hoz, a label megmaradt de érthetően a tartalom törlődött.

Csak kíváncsiságképpen, miért van hajszálra egyforma 2 linuxos partíciód, 51,5GB?
Én direkt néhány GB eltéréssel formázom a partíciókat, mert így egy listánál, ahol nincs label, csak esetleg uuid, ami csak a partíciókat és a méretüket tünteti fel, egy pillantással azonnal tudom a 10-15 partíció méretéből hogy melyik mi, és melyiken milyen OS van, melyik az adatpartíció melyik lemezemen stb.

 

Értékelés: 

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

Pár szösszenet

#4 Igen a grub.cfg-t erősen szerkesztgeni kell, pláne, ha

Debian-alapú rendszeren soha NEM nem kell szerkeszteni.
A Linux Mint és az LMDE 4 Debian-alapú.

Értékelés: 

0
Még nincs értékelve

Pár szösszenet

#4.1  
"

Igen a grub.cfg-t erősen szerkesztgeni kell, pláne, ha

Debian-alapú rendszeren soha NEM nem kell szerkeszteni.
A Linux Mint és az LMDE 4 Debian-alapú."

A Grub működésétő nagyon halván fogalmam van, épp most kezdem beleádni magam, csekély sikerrl...
Régebben ezt a tanácsot kaptam, a Manjaroval kapcsolatban és bevált,
ha Manjaro előbb volt telepítve, vagy nem akarom hogy belekutyuljon a megszokott Ubunti rendszerindítóba:

"A másik telepített linuxról bebootolsz.
Megnézed a manjaro partícióján a /boot könyvtárban mit ír initramfs verziószámnak és megjegyzed. (Pl. initramfs-4.9-x86_64.img)
Megnyitod az utoljára telepített linuxod grub.conf fájlját.
Megkeresed a manjaro bejegyzést és az initrd sorban átírod az intel-ucode.img részt pl. initramfs-4.9-x86_64*.img-re."

Kb. sejtem hogy így mit is csinál, ezt egy Manjaro kernefrissítés vagy egy Ubuntu update-grub természetesen ignorálja de akkor megint megcsinálom a procedúrát és megint bootol a Manjaro.
Azt nem tudom hogy az eljárás tiltott, vagy nem a legkorrektebb de az emberek zömét, így engem is a végeredmény érdekli, az meg jó mert működik.
 

 

Értékelés: 

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

Pár szösszenet

#4.1.1 Azt nem tudom hogy az eljárás tiltott, vagy nem a legkorrektebb de az emberek zömét, így engem is a végeredmény érdekli, az meg jó mert működik.

A végeredmény sem működik! Azonban nem érek rá értelmetlenségekről társalogni, feléd nem érdemes a szavakat koptatnom. Linux Mint/LMDE fórumon vagy, ne hirdess hülyeségeket. Ha előző mondatom nem érted, javaslom, annyiszor olvasd el az korábbi hozzászólásaim, amíg megérted, amit többször leírtam. Amikor megérted, akkor szólalj meg. Mert így felesleges. Továbbá zavaró. Ha nem érted meg, úgy senkit nem zavar, ha magadban tartod.

Értékelés: 

0
Még nincs értékelve

Pár szösszenet Pár szösszenet Pár szösszenet

#4.1.1.1

#4.1.1.1

#4.1.1.1 Nem értem most miért lettem letolva.
Igazad van, ez Mint fórum és nekem Ubuntu van. Ami Debian alapú, ugyanúgy mint a Mint. így megint csak én kérek elnézést..?

A leírt módszer működik és ebben nem tudsz megcáfolni mert egy update-grub után NEM bootol a Manjaro, kernel pánikkal elszáll, grub.cfg szerkesztése után meg elindul.

menuentry 'Manjaro Linux (20.2) (ezen: /dev/sda4)' --class manjarolinux --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-b40534ef-0fb4-424a-9440-ff594b9f3c6d' {
    insmod part_msdos
    insmod ext2
    set root='hd0,msdos4'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos4 --hint-efi=hd0,msdos4 --hint-baremetal=ahci0,msdos4  b40534ef-0fb4-424a-9440-ff594b9f3c6d
    else
      search --no-floppy --fs-uuid --set=root b40534ef-0fb4-424a-9440-ff594b9f3c6d
    fi
    linux /boot/vmlinuz-5.8-x86_64 root=UUID=b40534ef-0fb4-424a-9440-ff594b9f3c6d rw quiet udev.log_priority=3
    initrd /boot/initramfs-5.8-x86_64.img

Akkor most miért, mivel vívtan ki a haragodat, értetlenül állok kimarite.
Légyszíves mondd el, írd le hogy szabályosan, szabatosan, mindennek megfelelően mit kell elkövetnem hogy egy Ubuntu (vagy bármi nem Arch) grub el tudjon indítani egy Manjaro Linuxot kernel pánik nélkül, akkor is ha a Manjaron vagy az Ubuntun bekövetkezik egy kernelfrissítés.

Bár a kérésem eleve hamvába holt hisz Te írtad, 
" Azonban nem érek rá értelmetlenségekről társalogni, feléd nem érdemes a szavakat koptatnom."

Értékelés: 

0
Még nincs értékelve

Pár szösszenet Pár szösszenet Pár szösszenet

#4.1.1.1.1 Nem én lettem megszólitva, de simán előhozható a bármilyen grub-ból a halottnak vélt Manjaro és tényleg nem kell szerkeszteni a grub.cfg-t. (Kicsit kényelmetlenebb mód, ezt elismerem).

Válaszd a Manjaronál a helyreállitási módot és fallback menüpontot (nálam a utolsó, legalsó) és gyönyörűen indul a Manjarod.

Értékelés: 

0
Még nincs értékelve

Pár szösszenet

#4.1.1.1.1.1
Nem lettél megszólítva, ez aranyos,  mivel ez egy nyílt fórum, szerintem azért van hogy ha valakinek van jó tanácsa, akkor elmondja. Néven nevezés és megszólítás nélkül.

Erről sosem hallottam, és ki fogom próbálni, ha beválik akkor előre  is köszönöm a tanácsot.
 

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#3.1.1

Akárhogy számolom, a particiók mérete klappol, kiadják a lemezek mértetét, Ha a vinyóctíz nevű particiónak kettő kisebbnek kellene lennie, hát nem tudom, ilyent nem csinál semmilyen frissítés. Azt mondod, hogy frissen volt telepítve egy W10. Nem ennek során ment félre valami? Inkább erre gondolok, mert egy ilyen művelet nem módosítja a GRUB beállításokat, és tulajdonképpen a legutóbbi kernel frissítés csak helyre igazította az aktuális helyzethez a GRUB-ot. Bővebb tulajdonságokat nem lehet megnézni a particiókról? Pl. hogy mikor voltak létrehozva, talán ez nyomra vezet. 

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#5 +kiegészítés: HW hibát kizárhatjuk, de még valami eszembe jutott: Nem volt szétszedve a gép, és véletlenül felcserélve csatlakoztatva a merevlemezek? Pl. a Disk1 kábele a Disk2-vel? Windows 10 telepítésekor nem oda került, ahová kellet volna?

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#5
Ez egy munkagép. Szóbanforgó Win 10 rajta többször elindult, a gub menüben minden indításkor láttam is. (Immár második hónapja minden nap.) Tehát nem a létrehozáskor ment félre. És persze abban is egyetértünk, hogy ennek a galibának semmi köze egy Linux frissítéshez.

Az emlékeimben halászva semmit nem leltem, ami kiválthat ilyet.

Az egyedüli dolog, ami esetleg megtörténhetett, hogy oda más partícióból más OS-ról írni | olvasni próbálhattam, vagy onnan más OS lemezére. Ne nem emlékszem ilyenre, csak esetleg megtörténhetett is akár. (Olyankor szokott ilyen előfordulni velem, ha szükségem van a users/sajátmagam dokumentumaiból valamire, és lusta vagyok átbootolni, aztán > pendrive > másolás, és visszaboot, ahova az adat kell. Ha Linuxból babrálok egy NTFS partíción, nem szokott baj lenni, ám ha egyik májkroszoft OS-ből nyúlkálok másik májkroszoft OS-be, hát az tud sikamlós lenni tapasztalataim szerint. Meg vannak ott úgy kutyvasztva a jogosultságok, hogy nekem még nem sikerült átlátnom - és innen is egy becsípődésem, hogy isten óvjon rendszergazdát Windows hálózattól. Ha meg is tanulja, és jól is műveli, az nem lesz egy hordozható tudás, habár kétségtelenül hős bravúr.)

Emésztgetem ezt még egy darabig, hátha eszembe jut valami. Aztán ha nem, hát újra rakom az OS-t, és leszűrök egy tanulságot:
Ha egy munkagép hiba nélkül teszi a dolgát, azt bekonfigurálás után már nem bántom. Játszani, kísérletezni, tanulni ott a játszós gép. (Jelen pillanatban épp ennek a vasnak egy klónja az.)

A kiegészítéshez:
Nem volt felnyitva a motorháztető. Kizárható, hogy összekeverődtek a SATA adatkábelek.
(Egyébként hogy sose járjak így, minden gépben szóbanforgó kábelra fel van ragasztva egy maszkolószalag, amire ráírom, hogy melyik háttértáré.)

 

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#5.2 Jó, csak azért gyanús, hogy eltűnik egy vagy két partició, és a helyére kerül egy, aminek a neve vinyóctíz....

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#5.2.1

Egészen pontosan az történt, hogy a vinydóctíz (én címkéztem így fel telepítés előtt) partíció elé tette a telepítő a szokásos 50 megás rendszer számára fenntartott partíciót. Ez tűnt el. De akármennyire eröltetem magam, akkor se jön össze, hogy a lefoglalt terület mérete hgy jött ki három és fél gigára. Mert a rendszer számára fenntartott partíción a lefoglalt területnek 20-30 megának kellene lennie az eredeti ötvenből., míg a Windows rendszer lefoglalt területe minimum 40 giga volt. Ha sérült is a partíciós tábla, logikus lenne, hogy vagy az egyik, vagy a másik partíció végére mutat, de a lefoglalt terület elvileg attól nem változik. (Ennek utána kellene néznem, hogy is épül fel egy partíciós tábla.)

 

Nem gyanakszok arra, hogy betörtek a gépemre, habár semmit se lehet kizárni. A gyanúm inkább a partíciós tábla sérülése.

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#5.2.1.1 Nem ismerem annyira a W10-et erről az oldalról, biztos volt ott egy rendszerpartició? Mivel már van egy az elős lemezen, nem lehet, hogy azt vonta be közös használatra? Habár az új partició üresnek látszik, ez olyan, mintha megszakadt volna a telepítés.

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#5.2.1.1.1

A Windows kötelezően készít ilyen partíciót magának, még nem találkoztam olyannal, hogy ez ne történne meg telepítéskor.
A Linux simán felhasznál egy másik létező swap partíciót, és hozzácsapja ahhoz, amit te készítettél neki. Bizonyára ezen gondolatmenet okán a feltételezésed.
Ám biztonsággal kizárható a következő miatt:

Lehúztam a többi háttértárról telepítés előtt az adatkábeleket. Ennek két oka volt.

1 - Ne tűntesse el nekem a már működő, és nálánál fontosabb OS-em, a Linux grubját. Van rutinom azt ilyen esetben visszahozni, de legegyszerűbb eltüntetni a Linuxot a Win telepítő szeme elől (ha már a Linuxot telepítettük hamarabb, nem elég előrelátóan, ugye), mert az hülye.

2 - Ne készítsen saját indítómenüt a másik Win OS-el. (Ezt ugyanolyan automatikusan megteszi minden Win telepítő, mint szinte bármely Linux, csak azzal a különbséggel, hogy a Linuxot leszedi a listáról, hiszen az neki egyre veszélyesebb konkurencia.) Bajnak nem baj, de amikor egy ilyen vindózos indítómenüre ráengedem a grubot, akkor az belassítja a bootolási folyamatot azzal, hogy ha Windows-t választottam boot előtt, akkor előbb betölti a Win saját indítómenüjét - különben pedig szépen lekezel egy grub egy lépésből bárhány OS-t.

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#5.2.1.1.1.1

Elgondolkodtatott viszont a következő:

Ez a Disk 2 Linux alatt sdb. Eredetileg a harmadik partíció volt a cca 100 GB-os Timeshift címkéjű ext4 partíció. A Timeshift-nek be kellett jegyeznie, hogy a mentés helye az számításaim szerint sdb3. Viszont most ez Linux szemmel nézve sdb2-re változott. Tehát a Timeshift nem fogja találni időzített pillanatkép készítésekor majd a képfájl helyét.
Szerencse a dologban, hogy mellette van egy üres, jókora partíció, ami így most elvileg sdb3 lett. Kérdés, hogy ezzel így mit kezd a Timeshift vajon? Ha ez lenne a játszós gép, már csak kíváncsiságból is kivárnám. De mert ez pillanatnyilag az éles munkás gépem, elébe megyek. Csak jusson eszembe holnap.

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#5.2.1.1.1.1.1 Linux UUID-el azonosítja a lemezket, nem szokott gondot okozni a lemezek csereberéje, én is bővítettem már gépet multi kártyaolvasóval, úgy hogy négy sdx került a lista elejére, minden meglévő lemez hátra sorolódott, és Timeshift tudta, hogy hova mentsen (másik lemezre ment). De persze, a beállításokra érdemes ránézni, lehet nem jól emlékszem.

A címkézés jó ötlet, én igyekszek eltérő színű kábeleket használni, ha lehet, sajnos nincs túl nagy választék, fekete, piros, sárga... Bár ez nem akadályozza meg, hogy a kábel vége másik alaplapi csatlakozóba kerüljön, mint ahol eredetileg volt.

Mivel van windows, szerintem próbáld ki a GetDataBack programot, elég a próbaváltozat is ehhez. Rá kell ereszteni a kérdéses lemezre, remélhetőleg nem történt sok írás rá. Kicsit bonyás a felülete, de meg tudja találni a törölt particiókat is, ki listázza a visszaállítható fájlokat, (nem kell visszaállítani, csak látni, hogy volt-e valami, ami eltűnt).

Olyan van, hogy megsérűl a particiós tábla, ezért "eltűnik". Windows ráadásul hajlamos az ilyeneket megformázni.
De olyan esettel még nem találkoztam, hogy úgy sérül meg, hogy megmarad egy konkrét nevű partició azon a területen, ami még klappol is. Minimum valami krix-krax-nak kellene lennie a partició neve helyén. Ez nagyon olyan ízű, hogy ember csinálta.

 

 

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#5.2.1.1.1.1.1.1

Második napja olvasgatom ezt a bejegyzést.

Igen, jelen pillanatban számomra is úgy tűnik, hogy a Timeshift tudja még ezután a kalamajka után is, hova mentsen. (Kalapot is emeltem, nem kispályás fejlesztők csinálták.) Azonban azt nem tudom, hogy jelen esetben ez csupán szerencsés véletlen, vagy a Timeshift ennyire nagyon tudja a dolgát?

A címkézéshez egy kiegészítés:
Az alaplapi csatlakozókhoz nem babrálok, kizárólag akkor, ha egy létező üres foglalatra dugok fel egy újabb kábelt. Így az ebből fakadó keveredésnek elejét tudtam venni.
Szín szerint van nekem még kék is. Így ki is van a négy csatlakozóhoz a négy különböző szín. Igen ám, csak én az az eset vagyok, akinek amikor szüksége van egy újabb SATA tyúkbélre, örülök, ha találok bármilyen színűt. (Az pedig kizárt, hogy az én világvárosomban bemenjek, és kérjek egy feketét. Olyat adnak, amijük van.) Másik dolog, hogy nálam a kezdődő öregkori demencia jele, hogy ha lehúzok egy bármilyen színű adatkábelt, aztán közben kimegyek pisilni, utána meg nem mondom, hogy melyik színűt honnan húztam le.

A bejegyzésednek ez a GetDataBack okosság számomra a legizgalmasabb szektora. És nagyon jó időben kaptam ezt az információt. Semmiképpen nem szeretném elmúlasztani a kipróbálását. Annak ellenére sem, hogy nekem legtöbbször feláll a szőr a hátamon az efféle programoktól. (Nagyon gyakori az, hogy nincs rendesen megírva, csak az ára van rendesen elkérve (akár a Windows :D).) De most nagyon érdekelni kezdett, hogy vajon mit láthat? Várom, hogy a napokban fel tudjak szabadítani annyi időt, amíg ezt kipróbálom. Ha megtettem, beszámolok róla, biztos téged is érdekel majd.

A Windows nem csak az ilyeneket hajlamos megformázni. Tudod, hányszor csaptam már a kezére, hogy a Pendrive-t, SSD-t, HDD-t nekem nehogy babrálja, mert komplett Linux van rajta? De nem unja meg újból és újból megkísérelni, fene az erkölcsét!

' Ez nagyon olyan ízű, hogy ember csinálta. '

Teljesen érthető számomra, hogy így fogalmaztál. Nekem is megfordult a fejemben, hogy betörtek a hekkerek | bányászok a gépemre, lefoglaltak maguknak egy kis helyt. (És ezt most sem zárom ám ki még! Az egy másik fejezet lesz utánalépni. Most csak kapkodás lenne belőle, haladjunk csak szépen sorban.) Azt viszont nagy mellény nélkül ki merem jelenteni, hogy nem én voltam, ha ez emberi beavatkozás. (Jó, jó, fentebb éppen említést tettem a demenciáról, de azért ennyire neeem! :D)

Most pedig megteszem az első lépést "GetDataBack" ügyben. Rákeresek.

Értékelés: 

0
Még nincs értékelve

Az iménti frissítés eltüntette a grubból az sdb2-n levő OS-t.

#5.2

#5.2
" Olyankor szokott ilyen előfordulni velem, ha szükségem van a users/sajátmagam dokumentumaiból valamire, és lusta vagyok átbootolni, aztán > pendrive > másolás, és visszaboot, ahova az adat kell."

Ennél bonyolultabb módszert 1 gépen belül nem is lehetne kitalálni.
Linuxok simán bemennek és máris másolható/megnyitható ami kell, Win az akkor nyavajog ha a fiók, amibe turkálni kell az jelszóval védett. De megoldható, és a megoldás mivel 1 gépen belül, stabil lemez és partíciószerkezet van, így örök életre szól, a Win, pontosabban a felhasználók tulajdonjogait kell egyszer rendesen beállítani.
Előfeltétele minden Win fast startup és hibernálás kikapcsolása, valamint értelemszerűen nem használható BitLockernél.

Vagy az általam használt módszer.
Kell hozzá 1 darab nagyobb méretű NTF vagy exFat partíció, amin létre kell hozni egy logikus mappaszerkezetet.
Nálam pl. Download, Képek, Képek mentett, Telefon,  Videok mentett, Filmek, Portable, Torrent stb.
Mindegyik os-be ezeket állítom be minden programnak.
Pl. Ubuntu, Manjaro, W10 minden böngészője a Download-ba ment, minden képmanipuláló, screenshot, képszerkesztő az összes os alól a Képek mentett mappába dolgozik,a videovágó-szerkesztő programok, a a TV tunerem felvett filmjei, a Vokoscreen, mindegyik a Video mentett mappába dolgozik,  a Telefon az a telefonom szinkronmappája stb stb.
Ezek a Gyors elérésbe/Helyekbe minden os-en ki vannak szögezve, 1 kattintással elérhetőek.
Nálam  a Home az gyakorlatilag nulla, az Onedrive meg a Megasync van csak benne mert azok durván öszekavarodnak ha egy mappába több os alól szinkronizálnak. De ezek meg mivel felhő alapú szinkronizáló programok, másik os indítása után fél perccel már abban is ugyanaz a tartalom lesz, ugyanez igaz os újratelepítésnél is.

Ha bármilyen gebasz lesz a géppel,ez az 1 partíció gyakorlatilag az adataim 99%-áttartalmazza, erről havonta csinálok mentést a FreeFileSync-kel külső lemezre.
Semmi nem veszik így el, OS-t meg lehet telepíteni bármikor, az csak eszköz, egy használati tárgy.
Vagy végszükség esetén egy Live alá csatolva a DATA partíciót, vagy a külső  save lemezt egy Win alá csatolva usb-n, mehet tovább a meló ha nagyon sürgős.

A témára vissza, 
olyan nincs hogy egy meglévő partíció ELÉ hoz létre bármi is egy partíciót. Egy sda1 elé nem lehet létrehozni sda1/1-et, csak úgy ha a sda1-et töröljük és a felszabaduló helyen létrehozzuk a két partíciót.
Ha ilyenkor van más partíció is hátrébb a lemezen, akkor azok elcsúsznak, ez bizonyos esetekben problémát is okozhat.
Ezokból én sosem így csinálom.

Hogy nálad mi történhetett az továbbra is rejtély.

 

Értékelés: 

0
Még nincs értékelve

Windows csak egy particíó

"A Windows kötelezően készít ilyen partíciót magának, még nem találkoztam olyannal, hogy ez ne történne meg telepítéskor."

Pedig van ilyen: 20H2 Windows: (csak elő kell készíteni a lemezt)

[andrea@andrea-arch ~]$ sudo fdisk -l
[sudo] andrea jelszava:        
Disk /dev/sda: 465,76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: ST500LM012 HN-M5
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x000096ad

Eszköz     Indítható     Start      Vége Szektorok   Size Id Típus
/dev/sda1  *              2048 362373119 362371072 172,8G  7 HPFS/NTFS/exFAT
/dev/sda2            362373120 372613119  10240000   4,9G 82 Linux lapozó / Solar
/dev/sda3            372613120 618373119 245760000 117,2G 83 Linux
/dev/sda4            618375166 976773119 358397954 170,9G  5 Kiterjesztett
/dev/sda5            618375168 739205246 120830079  57,6G 83 Linux
/dev/sda6            739207168 860037246 120830079  57,6G 83 Linux
/dev/sda7            860039168 976773117 116733950  55,7G 83 Linux

Partition 4 does not start on physical sector boundary.
[andrea@andrea-arch ~]$

Értékelés: 

0
Még nincs értékelve

Windows csak egy particíó

#6 Amúgy kezdetben a W7 is így működött, de aztán a későbbi telepítések csak egy particiót telepítettek. Vagy tényleg az van, hogy ha előkészített NTF partició van, akkor már nem csinál kettőt. Mi történik, ha BIOS felülteten be van állítva hogy a Disk2-től butuljon?

Értékelés: 

0
Még nincs értékelve

Windows csak egy particíó

#6.1 Nálam a 2. lemez külső lemez. Ha beállitom, hogy arról boot-oljon, akkor az MX Linux indul. Ő a "svájci bicska" nálam.  Régebben volt rajta Wintogo-val telepitett Windows Insider is, de egy idő után nem frissitett, ment a kukába.

Értékelés: 

0
Még nincs értékelve

Windows csak egy particíó

#6.1.1 Bocsánat, a kérdés thyeby -nak szólt, csak elfelejtettem jelezni.

Értékelés: 

0
Még nincs értékelve

Windows csak egy particíó Windows csak egy particíó

#6.1

#6.1

Ha az MBR-ban be van jegyezve a Disk2 (pontosabban a partíciós táblába), és ez a meghajtó boot-olható bejegyzést is kapott, akkor simán butul róla. Ha nincs, akkor sötétség marad a képernyőn.

 

Igazából akkor van ennek jelentősége, ha BIOS-ból akarod közvetlenül elindítani, függetlenül az indítómenütől, úgy gondolom.

Értékelés: 

0
Még nincs értékelve

Windows csak egy particíó

#6.1.2 Én arra gondoltam, hogy kipróbálod, nem az elméleter kérdeztem rá. Annak eldöntésére, hogy ez most rendszerindítós, vagy sem. (hasznos információ a hová tűnt el a partició kérdéshez).

Értékelés: 

0
Még nincs értékelve

Windows csak egy particíó

#6
Hiszen ha előkészíted, akkor te magad hoztad létre szóbanforgó rendszer számára fenntartott 50 megát.

Igazad van, pontatlanul fogalmaztam. A Win telepítő kötelezően létrehozza ezt, ha még nincs ilyen. Ha van, akkor azt használja.

Azt akartam ezzel eredetileg jelezni, hogy én még nem láttam olyan Windows-t MBR-ben pontosabban Legacy-ban, amelyiken nincs meg ez az 50 GB-os partíció.
(UEFI esetén még egyéb partíciók is automatikusan létrejönnek, ha még nem léteznek. Linux alatt is.)

Értékelés: 

0
Még nincs értékelve

Windows csak egy particíó

#6.2 Nem hozok én léttre semmt, csak a számára engedélyezett 1. (üres) particióra telepitem a Windowst és képtelen új particiót léttrehozni, igy az emlitett 50 MB-set sem. Megoldja ő ezt is.

Értékelés: 

0
Még nincs értékelve

Oldalak