Re: fdisk corrupts data on USB stick

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mageia, run isodumper. It asks if you want to create a persistant
partition. Tell it to put a persistent  partition of of 2GB or so to fill up
the usb. Now you will have a 2GB partition on the usb that you can write to
etc. It will I believe be ext4 by default although you can choose others. No
need for fdisk. As has been stated this is not something that fdisk is
designed for. If you want to fix it so it will do what you want, you are of
course free to do so. Otherwise it is far simpler to use a tool that does what
you want already.

I suspect that isodumper would also work on other linux versions, but do not
know for sure. It is a Python based program, so you would need the appropriate
version of Python installed (or just install Mageia :-). Maybe Debian could
import it.

Of course it would then be irrelevant for util-linux



William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_    theory.physics.ubc.ca/

On Mon, 29 Jan 2024, Thorsten Glaser wrote:

[CAUTION: Non-UBC Email]

Bill Unruh dixit:

Perhaps if you told us what you really wanted to do, instead of asking
why your first method did not work and how to fix it. Eg, you wnat to
add another partition to the usb disk since the boot system only used
5GB of a 128GB usb, and you don't want to waste 123GB of space.

Something like that.

I have: an ISO 9660 filesystem that already contains a bootable MBR
with a partition table and even inlines an EFI thingy:

tglase@x61w:~ $ /sbin/fdisk -l /tmp/grml96-full_2022.11.iso
Disk /tmp/grml96-full_2022.11.iso: 1.62 GiB, 1734606848 bytes, 3387904 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
Disklabel type: dos
Disk identifier: 0x2e49ce75

Device                        Boot Start     End Sectors  Size Id Type
/tmp/grml96-full_2022.11.iso1 *        0 3387903 3387904  1.6G  0 Empty
/tmp/grml96-full_2022.11.iso2        628    8819    8192    4M ef EFI (FAT-12/16/32)

I can dd(8) that to a USB stick and it’ll be bootable. My USB stick
measures 4 GiB however, so I wanted to add a third partition that
uses the remaining space to store extra data, which I can then use
in the live system, alongside on the stick:

tglase@x61w:~ $ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 3.73 GiB, 4009754624 bytes, 7831552 sectors
Disk model: Flash Disk
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: dos
Disk identifier: 0x2e49ce75

Device     Boot   Start     End Sectors  Size Id Type
/dev/sdb1  *          0 3387903 3387904  1.6G  0 Empty
/dev/sdb2           628    8819    8192    4M ef EFI (FAT-12/16/32)
/dev/sdb3       3389440 7831551 4442112  2.1G 83 Linux

(Oh, apparently it’s less than 4 GiB. Anyway.)

So I did “sudo fdisk /dev/sdb” and added a partition, as usual.


Karel Zak dixit:
Thomas Weißschuh dixit:
In the message you may or may not have seen there is a reference to the
`--wipe` option that describes the reasoning and possibilities.

Oh, good point. I guess I’m surprised it does that by default.

There is also --protect-boot and --wipe-partitions, that may help in
some cases.

Incidentally, I *did* know-ish about --wipe-partitions precisely
because the default “auto” (according to the manpage…

Reproduced here for your convenience:
https://manpages.debian.org/bookworm/fdisk/fdisk.8.en.html

… I’m on bullseye, so slightly older but still present) *does* ask
for “auto” in interactive mode.

But --wipe doesn’t‽

      -w, --wipe when
[…]
             given,  the  default is auto, in which case signatures are wiped
             only when in interactive mode.  In all cases detected signatures
[…]
      -W, --wipe-partitions when
[…]
             tion is not given, the default is auto, in which case signatures
             are wiped only when in interactive mode and  after  confirmation
             by user.  In all cases detected signatures are reported by warn‐
[…]

So this inconsistency combined with auto being the default but
auto not meaning the same thing tripped me up.

As for why: "in order to avoid possible collisions".

Huh. But there already was a partition table there, and all I did
was to add another partition in free space at the end.

For convenience it even may have shown a prominent warning in bright red
letters with helpful pointers. Or maybe it didn't.

Let’s see…

tglase@x61w:~ $ sudo fdisk /dev/sdb

Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

The device contains 'iso9660' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.

Command (m for help):

No line wrapping, but no bright red letters either ☻

The terminal wrapped this between --wi and pe, so I guess
this is the reason for me to oversee that. (And even then,
the message does not indicate that I could also disable
wiping there as the option is just named --wipe and not
either paired with --no-wipe or named --wipe-mode which
would have implied multiple possibilities. Here, a user
could think “meh, I don’t want to wipe, so I don’t pass
--wipe and then it won’t do that”.

So, how do I get fdisk to not corrupt the ISO 9660 part?

Try `--wipe never` as explained above.

OK, thanks, will try that next time. Or actually…

tglase@x61w:~ $ sudo fdisk -w never /dev/sdb

Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

The device contains 'iso9660' signature and it may remain on the device. It is recommended to wipe the device with wipefs(8) or fdisk --wipe, in order to avoid possible collisions.

Command (m for help):

… from the message this sounds like it’ll do the trick.
(I still think that “possible collisions” could have been
worded better as well, but I’m not English, so…)

bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh


[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux