Új hozzászólás Aktív témák

• #132 WN31RD addikt proximus #131

  Új Válasz 2003-09-20 12:21:45 #132

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz proximus #131 üzenetére

  Nem, a hexdumpot inkább hanyagoljuk. Azt csak azért írtam, mert azzal gyorsan ellenőrizni lehet, hogy MBR vagy FAT boot record vagy esetleg valami más van-e a file elején.
  
  Az offset azt adja meg a mountnak ill. a losetupnak, hogy hány byte-ot hagyjon ki a felcsatolandó file elején. A .vmdk - amennyiben a teljes terület le lett foglalva az elején, mert ha nem lett lefogalva, akkor nem lehet mountolni - egy teljes merevlemez adatait tartalmazza, partíciós táblával (MBR-rel) együtt. Tehát ha megpróbálod felcsatolni, nem fog menni, mert nem rögtön a filerendszer van az elején. Meg kell adni a Linuxnak, hogy hol kezdődik a tényleges filerendszer az image-ben, erre való az offset. Általában LBA üzemmódban van a HDD VMware alatt, és ilyenkor az első partíció szinte mindig a 63-ik szektoron kezdődik, tehát 63*512 byte kihagyására van szükség (egy szektor mindig = 512 byte). Előfordulhat azonban, hogy valamiért mégsem ez a helyzet (pl. több partíció van a .vmdk-ban, és nem az elsőt szeretnéd használni), ekkor az fdiskkel kideríthető, milyen offsetre lesz szükség, a következőképpen:
  
  # fdisk imagefile
  átváltunk szektor alapú listázásra:
  : u
  : p
  és ekkor kiírja az image-ben levő partíciókat. Ebből a start értékek érdekesek, ezek mutatják meg, hogy az adott partíció hányadik szektoron kezdődik. Ezt kell beszorozni 512-vel, és megadni offsetként.
  : q
  
  Ne használd ezt a módszert arra, hogy filerendszert hozz létre a .vmdk-ban, azaz semmiképpen ne próbálkozz a mkfs* parancsokkal, mert nem fogják tudni, hogy mekkora helyet használhatnak.
  
  Remélem, így már tökéletesen érthető.

Új hozzászólás Aktív témák