[ Megoldva ] Forráslaptop nem bootol clonezilla másolás után.

Linux-kezdő

Egy windows-t rendszert kellene nagyobb lemezre másolnom, amihez a clonzilla megfelelő eszköznek tűnt.

Teszthez előtte egy kevésbé használt laptop lemezéről akartam lemezképet menteni. Mivel az éles gép még MBR rekordos, ezért az MRB clonzillát töltöttem rá egy USB-re.

A teszt laptop UEFI, ezért a BIOS-ban át kellett kapcsolnom a bootolást legacy-ra. Be is bootolt a clonezilla, le is másolta a lemezképet, le is ellenőrizte, minden ok.

Ezután letöröltem a lemezképet, hisz csak teszt. És a biztonság kedvéért bekapcsoltam a teszthez használt laptopot.

Innen jött a meglepetés. A laptop nem boot-ol. Nincs rajta semmilyen bootolható eszköz. Hibába állítottam vissza a BIOS-ban, hogy UFE boot, se kép, se hang.

Tudtommal a clonezilla csak olvassa a forráslemezt, így igazából nem értem, mi történt. Ha a BIOS-ban módosítok a boot beállításon, akkor felülírja a lemez tartalmát?

Tudtok segíteni, hogy megértsem, mi történt? Szintén csak a biztonság kedvéért: vissza tudom állítani a teszt laptopot működőképessé?

Amíg nem értem, mit rontottam el, nem merem az eredeti Widnows rendszert lemásolni clonezillával. (Marad a dd?)

Megoldás:

A laptopban a Legacy mod bekapcsolása, majd kikapcsolása tesztelhetően elrontja az EFI NVRAM bejegyzését, így nem indul az EFI/debian/ mappában lévő boot. (Az EFI/boot/ mappával így is elindul.)

Az efimbootmgr helyett a grub-install helyreállítja az EFI NVRAM bejegyzését.

A laptop, amivel ez történt, egy Lenovo Ideapad C340

  • 2144 megtekintés

( mauzi v | 2023. 11. 24., p – 15:48 )

Szerkesztve: 2023. 11. 24., p – 15:49

Első olvasatra, szerintem csak az UEFI bootmanager bejegyzést vesztetted el azzal, hogy átkapcsoltad BIOS módba.

(A diszken a partíciók megvannak? A fájlrendszereket fel lehet csatolni? Szinte biztosan igen... Az UEFI boot menüben benne van a Windows?)

Most töltök le épp egy live rendszert, hogy megnézzem, mi van a lemezen, de úgy tudtam, az UEFI a lemezen egy adatblokk. Ezt felülírhatja, módosíthatja a BIOS azáltal, hogy átkapcsolom legacy módba?

Legacy módban kiválaszthatom, melyik legyen az elsődleges: a legacy vagy az UEFI. Azaz legacy alatt is mennie kellene az UEFI-nek, azaz nem látom, miért törölhetné.

azt hogy mi legyen a gép boot menüjében, pram-ba menti az uefi. Ezt be kell regisztrálni hogy oda bekerüljön. 

Amúgy ez valóban bosszantó, hogy egy lemezt nem elég áttenni, hanem még a belső lemezen lévő oprendszereket be is kell regisztárálni, hogy el lehessen indítani.

Lehet azt a bejegyzést vesztetted el, ha a gép saját boot menüjében nincs meg.

Linuxnál például a grub javításával, win-nél a dvd/pendrive revocery console -on lehet fixálni bootot.

A BIOS nem találja a boot partiíciót. A Grubig el sem jut.

Egy SystemRescue rendszerről bebootoltam. A /dev/nvme0n1p1 partíción ott vannak az /EFI/debian/ mappában az EFI boot fájlok - gondolom. Ezt nem kellene a BIOS-nak megtalálni? Vagy nem kellene tudnom a BIOS-ban beállítani, hogy ez az EFI boot?

Vagy a grub fogja a BIOS-ban beállítani, hogy a BIOS EFI-nek lássa?

dd helyett nézd meg ezt: USBImager (ez van Windows-ra is. Ad egy minimális GUI-t ugyan, de lényegében pont annyit tud, mint a dd, semmi extra.)

de úgy tudtam, az UEFI a lemezen egy adatblokk.

Nem, hanem egy speciális partíciós tábla (GPT) és egy egész partíció (ESP, EFI System Partition), valamint pár NVRAM változó (nem a diszken tárolódik).

Ezt felülírhatja, módosíthatja a BIOS azáltal, hogy átkapcsolom legacy módba?

Nem.

Azaz legacy alatt is mennie kellene az UEFI-nek

Nem, a kettő nem kompatíbilis.

A BIOS nem találja a boot partiíciót.

Mert nem is dolga. BIOS alatt nincs olyan, hogy boot partíció (az csak az EFI specifikációban szerepel).

Vagy nem kellene tudnom a BIOS-ban beállítani, hogy ez az EFI boot?

Nem, a kettő nem kompatíbilis. Az EFI boot egyébként sem állítható, azt a GPT-ben egy speciális GUID típus jelzi (partíció típusa C12A7328-F81F-11D2-BA4B-00A0C93EC93B, a formátuma meg kötelezően FAT).

Vagy a grub fogja a BIOS-ban beállítani, hogy a BIOS EFI-nek lássa?

Semmiképp. Annyi van, hogy a grub képes legacy BIOS gépeken is értelmezni az ESP-t.

Röviden a lényeg:
- EFI alatt megkeresi a GPT-n az ESP-t, majd az NVRAM-ban tárolt nevű fájlt betölti onnan (ez tipikusan FS0:\EFI\BOOT\GRUBX64.EFI vagy FS0:\EFI\BOOT\BOOTX64.EFI)
- BIOS alatt a legelső szektor töltődik be, és az azt csinál, amit akar, nincs további szabály vagy megkötés. Régi gépeken ez tipikusan az MBR partíciós táblát nyalta végig, de értelmezheti a GPT-t is akár.

Namost a grub tud egy olyan programot rakni a legelső szektorba, ami képes megkeresni az ESP-t, és onnan betölteni a grub további fájljait, ez viszont speciális, normál esetben a grub vagy legacy módban települ (grub-install --target=i386-pc), vagy EFI módban (grub-install --target=x86_64-efi), és nem pedig hibrid (azaz mindkettőt támogató) módban. Trükközni kell, hogy mindkettő felmenjen (azaz GPT is legyen ESP partícióval, meg speciális boot szektor is). Ha viszont megvan mindkettő, akkor nyugodtan kapcsolgathatod a firmware beállításokban a legacy-t meg az EFI-t, mindkettőn bootolni fog, de addig nem.

Köszönöm a részletes választ, megpróbáltam feldolgozni, de nem tiszta még.

Amit kivettem belőle, hogy

1 - A lemezen van egy GPT partíciós tábla. Ez a legkülső réteg.

2 - Ebben az első (egyik?) partíció az EFI boot partíció. Nálam az "fdisk /dev/nvme0n1" parancs azt mutatja, hogy az 1. partíció típusa EFI System.

3 - Az EFI partíción meg kell lennie a megfelelő fájloknak. Nálam nem tudom, mi volt itt régebben, de jelenleg az EFI partíción ugyanazok a fájlok vannak, ami egy másik, rendesen boot-oló Debian gépen. Ezek szerint az EFI partíció tartalma is rendben.

A fentiek alapján akkor ennek UEFI boot módban indulnia kellene. És nem teszi. Az, hogy a BIOS adja-e hibaüzenetet, vagy az EFI, azt én nem tudom. Azt tudom, hogy bekapcsolva a gépet, azt az üzenetet kapom, hogy nincs bootolható eszköz.

Továbbra sem értem, mi hiányzik az én rendszeremből, hogy a gép elinduljon.

1 - A lemezen van egy GPT partíciós tábla. Ez a legkülső réteg.

Igen.

2 - Ebben az első (egyik?) partíció az EFI boot partíció.

A típusa számít csak, de valóban a legelső partíciónak szokás megadni.

3 - Az EFI partíción meg kell lennie a megfelelő fájloknak.

Pontosan.

Továbbra sem értem, mi hiányzik az én rendszeremből, hogy a gép elinduljon.

Két dolog: vagy a megfelelő fájl a partícióról, vagy pedig arra a fájlra mutató BootOrder bejegyzés az NVRAM-ban az, ami hiányzik nálad.

Nem. Normális gépen nem kell semmit regisztrálgatni, meg kell találja az UEFI a telepített rendszerek indítófájlait az EFI partíción, automatikusan. Bejegyezni csak ahhoz kell, ha sorrendet is akarsz állítani, hogy automatán mi induljon, vagy valami speciális bootparamétert akarsz felvenni, ha pl. közvetlen kernelt bootolsz (EFI stub boot).

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ha nem automatikusan, akkor hogyan? A BIOS-ban nálam a Boot menüpontban csak a boot típusa állítható (UEFI/Legaci). És ha Legaci a típus, akkor az, hogy UEFI first vagy Legacy first. Mást nem tudok állítani. UEFI módban listázza a látott EIF partíciókat, de ott nem tudok módosítani, csak látom a listát. És a merevlemez EFI partíciója nincs a listán.

Lehet, hogy máshol kellene mást állítani?

de úgy tudtam, az UEFI a lemezen egy adatblokk

Az UEFI az, amit régen BIOS-nak neveztünk, és az alaplapon lakik, egy (EE)PROM-ban. Amikor átteszed "BIOS módba" (esetleg úgy hívhatják még, hogy "Legacy mode"), egy CSM nevű komponenst (Compatibility Support Module) tölt be, ami gyakorlatilag emulálja az operációs rendszer számára a régi, klasszikus BIOS-t.

Az UEFI boot szabvány szerint kétféleképpen tud bootolni:

  • eltávolítható médiáról (pl. pendrive, külső USB diszk) úgy, hogy a háttértáron kell legyen egy FAT fájlrendszer, és ott (x86 architektúra esetében) a bootloader egy előre meghatározott helyen, mégpedig \EFI\BOOT\BOOTX64.EFI
  • fixen beszerelt médiáról (pl. HDD, SSD) úgy, hogy a háttértáron, a FAT fájlrendszerű ESP partíción lévő bootloadert tölti be, de ehhez fel kell azt venni az UEFI saját boot menüjébe, ami az alaplapi NVRAM-ban tárolódik.

Az tehát nem elegendő, hogy a HDD tartalmát 1:1-ben átklónozod, vagy éppenséggel átszereled a diszket.

Az UEFI boot manager beállításait Linux alatt az "efibootmgr" programmal tudod szerkeszteni.

Az UEFI törölheti az adott boot menü bejegyzést akkor, ha az ott hivatkozott diszk nem érhető el, vagy ha bekapcsolod a CSM-et.
Tehát pl. a gép általában bootolhatatlanná válik attól, ha a diszket kiveszed, majd ugyanoda visszarakod.

Egyes UEFI implementációk - ha nem találnak mást - akkor megnézik, hogy a diszken ott van-e a Windows saját boot loadere az ESP fájlrendszeren. Ha igen, akkor gyakran önmaguktól felveszik az UEFI boot menübe, amit nevezhetünk kellemesnek és kellemetlennek egyaránt.

az alaplapon lakik, egy (EE)PROM-ban

Ma már szerencsésebb flash memóriának hívni. A hőskorban még EPROM-ban volt a BIOS, olyan kerámiatokban, ami ablakkal volt ellátva, hogy az ablakon át UV-fénnyel törölhető legyen a tartalom, később már gyakran előfordult, hogy műanyagból volt az EPROM tokja, és nem volt rajta ablak, így UV-vel nem lehetett törölni, bár maga a chip belül igazi EPROM volt (a tokon lévő típusjelből legalábbis ez következik), még később használtak EEPROM-okat, amiket már elektromosan lehetett törölni (nem kellett kivenni az alaplapból a chipet), de már évek óta flasht tesznek az alaplapokra (aminek a tartalma szintén átírható kiszerelés nélkül, csak egy kicsit másképpen, mint ahogy az az EEPROM esetében történik).

Akkor ezek szerint az UEFI boot rendszernek van egy rejtett tárolója, ami módosulhatott attól, hogy Legacy módra váltottam? Vagyis magát a lemezt nem bántotta, csak a saját Boot bejegyzését módosította a Legacy emulációra, és amikor visszaállítottam, akkor nem állt vissza a merevlemezre? Ez logikus lenne, bár ez esetben sem értem, hogy a BIOS alatt a bedugott pendrive EFI partíciója megjelenik, mint indítható EFI rendszer, a merevlemez EFI partícióját nem is látja.

Ezt a tárolt beállítást szerkeszthetem az "efibootmgr" paranccsal?

Jelenleg az "efibootmgr" parancs kimenete:

BootCurrent: 0000
Timeout: 0 seconds
Boot0000* EFI USB Device ...
Boot0003* debian HD(1,GPT,6875cc6c-bf7f-48d5-9a6c-0b19ddd5d7e0,0x800,0x100000)/File(\EFI\debian\shimx64.efi)
Boot0004* Windows Boot Manager (HD,1,GPT?7dcb....
Boot2001* EFI USB Device RC
Boot2001* EFI DVD/CDROM RC
Boot2001* EFI Network RC

Ez olyan, mintha rendben meglenne benne a debian indító partíciója. A bejegyzésben hivatkozott shimx64.efi fájl is megvan a partíción.

Akkor ezek szerint az UEFI boot rendszernek van egy rejtett tárolója, ami módosulhatott attól, hogy Legacy módra váltottam?

Igen. Mondjuk nem annyira rejtett, csak épp nem a diszken tárolódik, hanem NVRAM-ban. Viszont...

Ezt a tárolt beállítást szerkeszthetem az "efibootmgr" paranccsal?

...így van, és a kimeneted alapján ez nem is üres.

Ez logikus lenne, bár ez esetben sem értem, hogy a BIOS alatt a bedugott pendrive EFI partíciója megjelenik, mint indítható EFI rendszer, a merevlemez EFI partícióját nem is látja.

Nem szerencsés a boot konfigurálót ebben a szövegkörnyezetben BIOS-nak hívni (azalatt sokkal inkább a legacy CSM modult értjük), de egyébként igen. A pendriveod azért jelenik meg, mert a BoorOrder-ed legelső bejegyzése ez: Boot0000* EFI USB Device ...

Ez olyan, mintha rendben meglenne benne a debian indító partíciója. A bejegyzésben hivatkozott shimx64.efi fájl is megvan a partíción.

Valóban. Az egyetlen, amit el tudok képzelni, hogy a GUID nem stimmel. Ez itt most vagy a diszk GUID-jának kell lennie, vagy a partícióénak.

Esetleg próbáld meg az \EFI\debian\shimx64.efi-t átnevezni \EFI\BOOT\BOOTX64.EFI-re. Elvileg a szabvány szerint ha a BootOrder felsült, akkor az \EFI\BOOT\BOOT(archkód).EFI nevű fájlt kell betölteni. Azonban ahogy mauzi is mondta, sok a bugos firmware, ami nem teszi ezt meg, de egy próbát mindenképp megér. (Ennek a fix elnevezésnek az lenne az előnye, hogy akkor is működnie kell(ene), ha üres vagy hibás a BootOrder). Ha nem jön össze, akkor marad az, hogy visszanevezed shimx64.efi-re, kitörlöd a BootOrder-t, és újra felveszed az efibootmgr paranccsal a bejegyzéseket.

Annyit megtennél, hogy idemásolod nekünk a következő parancs kimenetét? (A meghajtót cseréld le a sajátodra):

fdisk -x /dev/sda

Ebből kiderül, hogy mi a diszked GUID-ja, meg hogy mi a partícióé, és hogy ezek közül valamelyik egyezik-e a BootOrder-belivel. És talán arra is választ tudunk adni, hogy miért nem jelenik meg neked a boot konfigurálóban.

Nem gépelem be az fdisk -x /dev/nvme0n1 parancs teljes kimenetét, de a lényegesebb sorok:

Disklabel type: gpt
Disk identifier: 0030D53-01B6-440C-9B4C-578250ECEB0C
Partititon entries starting LBA: 2

Ha ennek az ID-nak az efibootmgr kimenetében található

6875cc6c-bf7f-48d5-9a6c-0b19ddd5d7e0

kóddal kellene megegyezni, akkor nagy kérdés, hogy ki módosította ezt az ID értéket? Azt sem értem, a BIOS-ban található Boot menüben olvasható EFI listában miért nem szerepel ez, mint egy lehetséges boot eszköz.

Ha átnevezem az \EFI\debian\shimx64.efi fájlt \EFI\BOOT\BOOTX64.EFI nevűre, akkor lőn csoda: elindult a rendszer!

Ez már egy lépés. De még mindig nem tudom, mi történt, és ki csinálta. Ha jól gondolom, a Disk identifier a lemez egyedi azonosítója, az nem változhat.

Érdekes módon, ha legacy módban bootol a pendrive, akkor az "efibootmgr" parancs nem mutat semmit, azt mondja, nincs értelmezve.

UEFI módban bootolva az "efibootmgr" parancs kimenete kicsit mást ad, mint eddig:

BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0002,2001,2002,2003
Boot0002* Linpus Lite HD(1,GPT,6875cc6c-bf7f-48d5-9a6c-0b19ddd5d7e0,0x800,0x100000)/File(\EFI\Boot\grubx64.efi)RC
Boot0003* EFI USB Device ...
Boot0004* Windows Boot Manager (HD,1,GPT?7dcb....
Boot2001* EFI USB Device RC
Boot2001* EFI DVD/CDROM RC
Boot2001* EFI Network RC

Itt nekem az a fura, hogy a /EFI/Boot/grubx64.efi fájl indult el, és nem az, amit én átneveztem.

Visszaneveztem a BOOTX64.EFI fájlt shimx64.efi-re, de a mappa maradt BOOT. Így is elindult a rendszer, ám így is a /EFI/Boot/grubx64.efi fájlt mutatja az efibootmgr.

Visszaneveztem a mappát BOOT-ról debian-ra, és megint nem indul el.

kóddal kellene megegyezni, akkor nagy kérdés, hogy ki módosította ezt az ID értéket?

Bármelyik telepítő megtehette. Az UEFI nagy problémája, hogy a diszk és az NVRAM függetlenül kezelődik, de a tartalmuknak stimmelnie kell, hogy működjenek a dolgok.

Azt sem értem, a BIOS-ban található Boot menüben olvasható EFI listában miért nem szerepel ez, mint egy lehetséges boot eszköz.

Ennek megválaszolásához látni kéne a teljes fdisk -x kimenetet.

Ha átnevezem az \EFI\debian\shimx64.efi fájlt \EFI\BOOT\BOOTX64.EFI nevűre, akkor lőn csoda: elindult a rendszer!

Hurrá!

Ha jól gondolom, a Disk identifier a lemez egyedi azonosítója, az nem változhat.

Nem biztos. Ennek egyedinek kell lennie minden esetben, ezért simán el tudom képzelni, hogyha ütközés van, akkor valami átírhatja (UEFI firmware, Linux kernel, de akár még a GRUB is. A legvalószínűbb az UEFI firmware).

Érdekes módon, ha legacy módban bootol a pendrive, akkor az "efibootmgr" parancs nem mutat semmit, azt mondja, nincs értelmezve.

Igen, ez az elvárt működés. (Legacy CSM esetében nem adódik át az EFI System Table mutatója, így nincs meg a mutató az EFI Runtime Services táblára, amiben az NVRAM kezelő függvények címei vannak. Magyarán az efibootmgr nem tudja elérni azokat a firmware funkciókat, amivel lekérhetné / módosíthatná a listát.)

Itt nekem az a fura, hogy a /EFI/Boot/grubx64.efi fájl indult el, és nem az, amit én átneveztem.

Ez normális. A shim-re csak akkor van szükség, ha engedélyezve van a Secure Boot, és akkor a shim kizárólag az "EFI\BOOT\GRUBX64.EFI" nevű fájlt hajlandó betölteni (valamiért bele van drótozva ez a fájlnév, és nem állítható...). Namost ha nincs Secure Boot bekapcsolva, akkor a shim "kiiktatja" magát, egyből lecséri a BootOrder-t erre a GRUBX64.EFI-re.

Visszaneveztem a BOOTX64.EFI fájlt shimx64.efi-re, de a mappa maradt BOOT. Így is elindult a rendszer, ám így is a /EFI/Boot/grubx64.efi fájlt mutatja az efibootmgr.

Igen, most már nem számít, mivel a BootOrder-ben GRUBX64.EFi szerepel már.

Visszaneveztem a mappát BOOT-ról debian-ra, és megint nem indul el.

Mert ekkor a GRUBX64.EFI nem található, tehát ilyenkor az "EFI\BOOT\BOOTX64.EFI"-t keresné, csakhogy a könyvtárátnevezés miatt az sincs.

Kicsit off itt, de sajnalom, hogy ez igy "el lett rontva". Olyan erzesre ez, mint anno a PnP konfiguracio volt. Ha lenne opcio a gyari firmware utilityben arra, hogy kezzel lehessen modositani a boot opciok listajat az nvramban, barmifele kulso szoftver nelkul, az megoldana egy csomo problemat (pl ezt is). Pont ugy, mint 25 eve a PnP BIOS. Tok jol beinicializalta a hangkartyat, teszemazt a 9-es IRQ-ra, a DOS-os driver meg kototte az ebet a karohoz, hogy a PnP BIOS mar inicializalta a dolgokat, o nem tud masik eroforrast kiosztani, aztan lehetett sakkozni, hogy hogyan kellene a PnP hangkartyat 7-es vagy 5-os IRQ-ra kenyszeriteni (mert a szoftverben meg csak ezt lehetett kivalasztani). Hiaba volt az Intelnek is DOS-os PnP enumeratora, az meg ragaszkodott ahhoz, hogy nincs ra szukseg, 7.0-as DOS (Windows 95 DOS verzioja ugye) eseten. Itt is csak annyi kellett volna, hogy ne csak azt tudd megmondani, hogy adott IRQ/DMA az automata vagy legacy only, hanem meg kellett volna tudni mondani, hogy adott PnP eszkozt hova initeljen a BIOS. Maris kevesbe lett volna Plug & Pray.

Ha lenne opcio a gyari firmware utilityben arra, hogy kezzel lehessen modositani a boot opciok listajat az nvramban, barmifele kulso szoftver nelkul

Újabb (kb. 2018 utáni) Legacy BIOS módot már nem támogató Dell PC-knél, laptopoknál már ez a helyzet. A régebbi gépeknél meg marad az efibootmgr vagy az efibooteditor.  https://github.com/Neverous/efibooteditor
--
Légy derűs, tégy mindent örömmel!

Akkor összefoglalom: most jól indul a rendszer, ha az EFI fájlok a "boot" mappában vannak, mert az NVRAM-ban az /EFI/boot/ mappa van tárolva. Mivel a "Device id" nem változott az NVRAM-ban, ezért annak is jónak kell lennie.

Akkor miért nem indult el a rendszer amikor az NVRAM-ban a /EFI/debian/ mappa volt és az EFI alatt is debian mappa volt?

A teljes fdisk -x kimenete:

Disk /dev/nvme0n1: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: KINGSTON SA2000M81000G                  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 003F0D53-01B6-440C-9B4C-578250ECEB0C
First LBA: 34
Last LBA: 1953525134
Alternative LBA: 1953525167
Partition entries LBA: 2
Allocated partition entries: 128

Device              Start        End    Sectors Type-UUID                            UUID                                 Name Attrs
/dev/nvme0n1p1       2048    1050623    1048576 C12A7328-F81F-11D2-BA4B-00A0C93EC93B 6875CC6C-BF7F-48D5-9A6C-0B19DDD5D7E0      
/dev/nvme0n1p2    1050624 1932679167 1931628544 0FC63DAF-8483-4772-8E79-3D69D8477DE4 B6BC34B9-234D-4092-A787-F49A82CD7332      
/dev/nvme0n1p3 1932679168 1953523711   20844544 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F 2E117AB4-3BF1-48AF-8B34-A00E2943243C      


Disk /dev/loop0: 116,76 MiB, 122433536 bytes, 239128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop1: 8 KiB, 8192 bytes, 16 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop2: 118,23 MiB, 123973632 bytes, 242136 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

( x-daemon | 2023. 11. 24., p – 15:58 )

jo a dd. majd ki kell terjeszteni a particiot.

neked aztan fura humorod van...

Persze. A Windows látni fogja hogy a partíción kívül van unallocated space, amit simán hozzá tudsz csapni a disk managerben. A szopás akkor van, amikor a céllemez kisebb mint a forrás (ilyenkor másolás előtt shrinkelni kell a foglalt területet és utána mehet a dd).

Talán 1x fordult elő velem olyan, hogy magától nem indult el másolás után, de a Windows saját recovery-je megoldotta.

 

https://www.howtoforge.com/linux-dd-command-clone-disk-practical-exampl…

Aláírás _Franko_ miatt törölve. 
RIP Jákub.
neut @

Nalam par hete volt pont ilyen eset, hogy nem indult be a dd-vel masolas utan. (Nem szoktam desktop windows-okkal foglalkozni, ugyhogy nem volt rutinom benne). BCD boot problemakra keszultem fel elotte, de ez nem az volt, a boot mukodott, csak elakadt a splash screenen orokre varakozva valamire. A recovery azt mondta, hogy nem talal semmi windows installaciot, a command line toolokkal csak a recovery particiot sajat magat talalta meg.

A megoldas az volt, hogy ujra atmasoltam dd-vel, es a masodik probalkozasra NEM linux alatt novesztettem meg a particiot, hanem meghagytam akkoranak amekkora eredetileg volt. Poccre indult es a windows disk managerbol siman tudtam noveszteni a particiot es filerendszert.

Hogy pontosan mit rontottam el a particioatmeretezesnel azt nem tudom, mert (szokasommal ellentetben) nem irtam logot rola. Mindenesetre tanulsag: hagyd a windows-ra a particio atmeretezest.

Régóta vágyok én, az androidok mezonkincsére már!

( Zs | 2023. 11. 24., p – 16:40 )

Clean Debian rendszer telepítéssel jártam úgy, hogy friss telepítés és el sem indul. Egyes bugos EFI BIOS-ok ugyanis valamirt elnyesnek... Más is ráfutott: https://wiki.debian.org/UEFI#Quirks.2C_workarounds_and_special_UEFI_fea…
A megoldás nálam az volt, hogy külső eszközről bebootol, rootfs becsatol, alá bind-mount mindenn ami kell (/proc, /sys, /dev, /dev/pts), majd dpkg-reconfigure grub-efi-amd64 és ahogy a leírás is mondja, a Force extra installation to the EFI removable media path kérdésre a válasz: Yes. Innestől EFI alapokon bootol. BIOS alapokon nem bootol.
Ha a te rendszered is EFI-s és a jó EFI-ről átemelted a bugos EFI-s cuccra, járhattál így.

Nekem egy régi HP laptopon csak akkor volt hajlandó bootolni, ha Microsoft64.EFI vagy WINDOWS64.EFI vagy valami hasonló (már nem emlékszem pontosan) volt a neve. Tehát a Debian által rakott EFI fájl nem felelt meg neki, kellett egy ilyen mókolás.

 

Régebbi eszközökön lehet bőven szívás UEFI-vel, az újabbakon érzésre talán kevésbé.

TheAdam

Tapasztalatom szerint ez nem szokott számítani. Mindegy, hogy Microsoft Data vagy EFI System a partíció típusa, egy rendes UEFI ezt nem szokta nézni, csak hogy a rajta lévő fájlrendszer FAT legyen, és találjon rajta .EFI végű binárist. Elvileg lehet FAT12, FAT16 is, de nyilván olyat nem használ senki, FAT32 szokott lenni. Az exFAT-ot nem tudom, arról nincs tudomásom, hogy működne.

Az is igaz, hogy ez nálam azért sem volt sose gond, mert
1) a gány implementációjú gépeket (HP és nagy corporate overloard társaik lezárt rendszereit) kerülöm
2) nem használok Secure Boot-ot (és nem, soha nem volt emiatt vírusom, rootkitem már idestova majdnem egy évtized alatt), az MINDIG ki van kapcsolva
3) kerülöm a bonyolult bootmanagereket (GRUB főleg), helyette általában systemd-boot megy (ennek a neve ellenére semmi köze a systemd-hez, valójában a gummiboot projekt átnevezve) vagy a kernel bootol közvetlenül (EFI stub boot). Így sok minden leegyszerűsödik, nincs szopás shim-mel, mindenféle aláírással, driverekkel, bonyolult bootmanager nem törik el szerencsétlen update vagy rossz klónozás miatt. Egyszerűen csak bootol minden, még dualboottal is, akár egy lemezről, akár két külön lemezről, akár külső meghajtóról, teljesen mindegy, hogy pendrive, HDD, SSD, UEFI vagy Legacy CSM BIOS boot, milyen OS. Ilyen sokat jelent, ha az ember a saját életét nem nehezíti extrákkal.

Ha az ember jól használja, akkor az UEFI boot egyszerűbb, mint a hagyományoss Legacy CSM BIOS MBR boot. Nem kell bootflagekkel, primary, extended, logical partíciókkal szórakozni, meg azzal, hogy a különböző OS-ek átírogatják egymás alatt az MBR-t, és ügyelni kellene a telepítési sorrendre.

Az UEFI engem csak egyszer szopatott meg, én voltam béna. Véletlenül Gentoo-val vitézkedés közben CLI-s bootmgr-rel töröltem az összes bootbejegyzést az UEFI-ből, de még a Boot from HDD, Boot from USB, stb.-ket is, és nem bootolt a gép, még külső meghajtóról sem. Szerencsére a nagy kezdeti ijedelem után megőriztem inkább a hidegvérem, bementem az UEFI-be bootkor, és ott Load Defaults-ot nyomtam, és újra megjelentek ezek a bejegyzések. Egy pillanatra úgy tűnt, hogy téglásítottam a gépet.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Tapasztalatom szerint ez nem szokott számítani.

Én meg még olyannal nem találkoztam, ahol ne számított volna.

egy rendes UEFI ezt nem szokta nézni

Ez nem igaz, a specifikáció elég félreérthetetlenül fogalmaz, hogy néznie KELL. https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#partiti… valamint https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html#gp… "The firmware must add the PartitionTypeGuid to the handle of every active GPT partition using EFI_BOOT_SERVICES.InstallProtocolInterface() . This will allow drivers and applications, including OS loaders, to easily search for handles that represent EFI System Partitions or vendor specific partition types".

Elvileg lehet FAT12, FAT16 is, de nyilván olyat nem használ senki, FAT32 szokott lenni.

Igen, nekem is az a tapasztalatom, hogy csak a FAT32 működik. A spec megenged 12-est és 16-ost (meg ISO-9660-t), de az MSDN szerint csakis FAT32 lehet: "The minimum size of this partition is 100 MB, and must be formatted using the FAT32 file format" (ami a méretet illeti, nálam simán működik 33Mb-s partícióval is, az a legkissebb, ami a FAT32 lehet).

Az exFAT-ot nem tudom, arról nincs tudomásom, hogy működne.

Még nem találkoztam olyan firmware-el, ami kezelte volna, és a spec szerint sem használható. Megjegyzem a spec szerint működnie kéne az ISO-9660-nak is (legalábbis a 13.3.2. fejezet szerint, a 13.3.1.1. fejezet szerint csakis FAT lehet), de még olyan firmware-el sem találkoztam, ami azt kezelte volna. Az viszont mindenhol működött eddig, hogy az ISO-9660 El Torito Boot Catalog egy FAT32-re mutat (azaz ha a CDROM formátum partíciós táblaként van használva, és nem pedig fájlrendszerként).

Ha az ember jól használja, akkor az UEFI boot egyszerűbb, mint a hagyományoss Legacy CSM BIOS MBR boot. Nem kell bootflagekkel, primary, extended, logical partíciókkal szórakozni, meg azzal, hogy a különböző OS-ek átírogatják egymás alatt az MBR-t, és ügyelni kellene a telepítési sorrendre.

Helyette van másfajta szopás vele, pl. hogy nem tudod áttenni a bootdiszket csak úgy egy másik gépbe (mert a boot config nem megy vele, külön konfigurálgatni kell). Na meg hogy dd-vel nem lehet nagyobb diszkre csak úgy átrakni (mert a GPT-nek a diszk végén is szerepelnie kell, amiben van szektorszám és crc is, tehát csak speciális programmal átméretezhető).

Igen, sok HP gép UEFI-je híres erről, hogy fixen a Windows .EFI fájljaihoz van berögzítve a boot, és ahhoz, hogy akármilyen Linux vagy más OS bootoljon UEFI módban, ahhoz az kell, hogy átnevezze az ember a bootfájlokat, így az UEFI azt hiszi, hogy Windowst tölt be, közben meg valami teljesen mást. Nagyon szemét megoldás ez a HP-től, bár állítólag az újabb gépeken leszoktak erről. Nem tudom, kerülöm a HP-kat.

Egy normális, sztenderd implemenetációjú UEFI-s gépen ezzel nem kell szórakozni, ezeken a UEFI megtalál az EFI partíciókon mindenféle .EFI fájlt, akkor is, ha nincs róla bootbejegyzés. ThinkPad X220, IdeaPad 5 Flex 15ARE05, ASUS TUF A15 mind megtalálja nálam, akármilyen bootfájl van az EFI partíción, akármilyen név alatt, automatikusan detektál mindent.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( renard | 2023. 11. 24., p – 23:24 )

Tudtommal a clonezilla csak olvassa a forráslemezt

Ez pontosan így van.

 

Amíg nem értem, mit rontottam el, nem merem az eredeti Widnows rendszert lemásolni clonezillával.

Egy dolog biztos: a Clonezilla nem rontott el semmit. Többen is leírták már, hogy mi okozta a problémát (nem a Clonezilla).

( kleinie | 2023. 11. 27., h – 15:51 )

Nincs olyan opció a boot menüben, hogy "boot from file"? Ha létezik ilyen opció, akkor ha betallózod az EFI partíción lévő shimx64.efi-t azzal el kellene indulnia.

( ncc1701 | 2023. 11. 28., k – 09:36 )

Ipari szinten használok clonezillát. Abban biztos vagyok, h nem az aszarintotta el, az csak olvassa a lemezt ilyenkor.

( WatchDog | 2023. 11. 28., k – 11:56 )

Az újabb laptopokat USB-re, csak GPT-és partícióval/fájlrendszerrel megírt operációs rendszert tudsz telepíteni, MBR-el nem. Mivel nem támogatja, nem fogja látni BIOS szinten. Több ilyennel is találkoztam már.  A régiek MBR-el mentek.
Mondanám, hogy clonezilla-val lemented a rendszert, ami MBR, és azt áttöltöd az újra. Amit ugye nem fog kezeli és az MBR-el, így nem fog elindulni. Viszont, ha a Windows eljut a boot-ig, akkor ott shift+f10-el behozod a parancssort, ahol az MBR típusú partíciót át kell konvertálni GPT-re. Nagyjából a következőképpen tudod megcsinálni:
1) diskpart
2) list disk (ha disk 0, akkor)
3) select disk 0
4) clean (ezzel az a baj, hogy töröl mindent! hogy ez a lépés mennyi hagyható ki nem tudom, azt nem próbáltam!)
5) convert GPT
6) exit
Ezután GPT lesz, és boot-oltnia kellene.
Kisebb hdd-ról nagyobb hdd-re gond nélkül lehet klónozni, amit később ki lehet terjeszteni (ezt már más is leírta).
A fentieket saját tapasztalat írtam le.

( influencer | 2023. 11. 28., k – 17:25 )

Szerintem nem pontos a cím, ideális lenne módosítani: "Bios módosítás után nem indul a laptop". Nem a clonzilla okozta ezt, hanem a BIOS módosításod. Ha el sem indítod a clonezillát is ez lesz.

Ez okozta a gondot, hogy nem UEFIs czt használtál és a BIOShoz nyúltál. 

Remélem sikerül helyreállítanod. Jók az esélyek, mert elvileg nem írtál felül semmit.

Amíg nem tudom biztosan mi történt, addig nem tudom, hogy tényleg a BIOS okozta-e vagy a Clonezilla.

Attól, hogy a BIOS-ban engedélyezem a Legacy boot-ot, attól az addig működő UEFI boot eszköznek meg kellett volna maradnia. És attól, hogy az UEFI és Legacy boot közül a Legacy-t indítja előbb, attól sem lett volna szabad megváltoznia az eredetileg működő UEFI eszköz indíthatóságának.

Tehát sajnos nem látom még, hogy ki és miért is írta felül az NVRAM-ot, és hogy tényleg az NVRAM lett-e felülírva.

( plt | 2023. 11. 29., sze – 15:20 )

A kérdésre nem kaptam választ ugyan, de kiderült, hogy efibootmgr ide vagy oda, a grub-install helyreállítja az EFI bejegyzést is.

Tehát ha az EFI partícióban az eredeti .../debian/... mappa szerepel, és erre nyomok egy grub-inbstall parancsot, akkor onnantól bebootol a gép.

Innentől tudtam tesztelni, hogy mi van, ha a BIOS-ban átállítom Legacy-ra, majd vissza UEFI-re a boot-ot.

És igen: a laptop cseszi el az NVRAM-ot. Clonezilla felmentve!

( taarzaan | 2023. 11. 29., sze – 16:06 )

Szép, hogy meg lett a megoldás... esetleg a kezdő posztot ki lehetne egészíteni ezzel? ...és persze, hogy milyen laptop, milyen verziójú bios-a a ludas? ...nekem is volt, hogy nem indult a windóz, ha ide-oda kapcsolgattam legacy és uefi boot között, de általában helyre jött, ha visszakapcsoltam.