Re: DD bs=4M option on USB mem-stick creates false format
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
Reply to: