Hi, kAt wrote: > >> Disk /dev/sdb: 7.2 GiB, 7751073792 bytes, 15138816 sectors > [...] > I suppose this is normal for an 8Gb usb stick. 249Mb go to firmware that > operates the stick????
Hardly. Unless it is an operating-system-on-a-stick. The habit on the storage sector is to count by SI compliant mega and giga. I.e. millions and billions. 7.77511 billion is not 8 giga. (Well, you can be lucky if it is not a fake stick which maps more than one logical block address onto the same physical block. Or one that pretends to be a USB keyboard and begins to reprogram your computer.) > So where does the false alert come from on Gparted about the 2048b? Please show the gparted messages which worry you. > [from other mail:] Rescatux 4.0beta > > Is it a problem with the way I restore the iso, a problem with the iso > that Rescatux forces (I wouldn't think so) or a problem with the stick > itself? It is most probably a problem with the partition tables in the ISO. wget 'https://downloads.sourceforge.net/project/rescatux/rescatux_0_40_b11/rescatux-0.40b11.iso' xorriso -indev rescatux-0.40b11.iso -report_system_area plain shows the same "mjg" layout as Debian installation ISOs: - MBR partition table with nested partitions (some partition editors hate this). - GPT partition table not properly announced by "Protective MBR" and with nested partitions (doubly hated). - APM partition table with block size 2048 (look here for a suspect !) This collection of little sins and contradictions is enough reason for any partition editor to bail out. We should reduce the list to the MBR nested partition sin. > I am trying to use the empty part of the stick to copy and store > temporatily some important files Well understood. You should clean out the surplus partition table headers iso=/dev/sdb # Remove GPT header block. # I add option conv=notrunc for the case this is done with a image file # rather than a device file. It prevents truncation of the file. dd if=/dev/zero conv=notrunc bs=512 seek=1 count=1 of="$iso" # Overwrite APM Block0 signature by unchanged isohybrid MBR start # provided by Debian package "isolinux" since oldstable Debian. # # We want these bytes, and isohdpfx.bin is their cheapest source: # 33 ed 90 90 90 90 90 90 90 90 90 90 90 90 90 90 # 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 dd if=/usr/lib/ISOLINUX/isohdpfx.bin conv=notrunc bs=1 count=32 of="$iso" Then try to find a partition editor which tolerates the nested MBR partitions. Last resort: If no partition editor is willing to work, we could patch some numbers into MBR partition slot 3 to make us a partition by hand. These bytes: 00 ff ff ff 83 ff ff ff bc d0 13 00 44 2f d3 00 at byte position 478 would do this trick: Device Boot Start End Sectors Size Id Type test.iso1 * 64 1374207 1374144 671M 0 Empty test.iso2 1297212 1298619 1408 704K ef EFI (FAT-12/16/32) test.iso3 1298620 15138815 13840196 6.6G 83 Linux i wrote: > > You may use fdisk to add a partition. > > (Let's hope it will not hate that sdb2 is located inside sdb1.) > why does this happen? Because xorriso built it according to the BIOS+EFI isohybrid layout as developed by Matthew Garrett (mjg) in 2010. Rescatux people used something named LIVE-BUILD 5.0_A11-1; HTTP://LIVE-SYSTEMS.ORG/DEVEL/LIVE-BUILD which obviously ran xorriso. This layout with several partition tables shall boot on as many BIOSes and EFIs as possible. Usefulness for partition editors is only a secondary consideration. > So fdisk uses things differently than gdisk, or is the one using the other? Yes. They are different programs. fdisk is mainly for MBR partition tables, gdisk is mainly for GPT. Since i propose to remove the not-so-good GPT and APM, fdisk should be your first try afterwards. > The EFI part is sdb2, right? Which resides inside sdb1? sdb1 makes the whole ISO filesystem mountable. It has partition type 0x00 (= "Empty") because else EFI would refuse to accept the partition of type 0xef (= "EFI") which sits inside sdb1. > So it is normal that if you write such an iso in a 64Gb stick 63Gb > remain useless as long as this system is on it? Good question. Hardly any partition editor really helps to clean up the mess. So, yes, it is quite normal that adding a partition to mjg's partition table equipment is cumbersome. I made some effort in the recent years to enable a less tangled layout based solely on MBR partitions, with the EFI boot image outside the ISO so that there emerge no nested partitions. grub-mkrescue on the other hand offers a partition-editor-friendly layout based entirely on GPT (if no appleisms are configured to go into the ISO). The ISO itself is not mountable by a partition then. But understandably, the distros are not very eager to make experiments with their ISOs, which on the first hand shall boot and not be nice to partition editors. > I am very far from undersdanding this but it is interesting to keep at it? Sure. Maybe we even develop a program to de-mjg-ize an installed ISO for systems which do not need GPT or APM, and to then claim the remaining space as MBR partition 3. Have a nice day :) Thomas
