Syslinux - Jan 2014 - [PATCH] Proposal for a pacifier option with mkdiskimage

Hi,

me:
> > [mkdiskimage] -s does not prevent zeroizing on block device. Probably
> > because truncate() fails.
hpa:
> Yes, we should probably fix that.  The tool was originally designed for
> images, not for hardware devices, and it doesn't make much sense to
zero
> the whole hardware device like that.
Maybe for privacy reasons ?
But indeed: -s should skip zeroizing, regardless of truncate.

Additionally the argument of truncate is currently wrong by a
factor of 512:
  $ mkdiskimage_orig.in -s image.img 250 64 32
  $ ls -l image.img
  -rw-r--r-- 1 xyz xyz  512000 2014-01-28 08:33 image.img


How about this ?
Tested with USB stick and image file, with and without -s:
-------------------------------------------------------------------------
--- mkdiskimage_orig.in    2014-01-23 12:23:34.000000000 +0100
+++ mkdiskimage_with_lower_s.in    2014-01-28 08:25:02.000000000 +0100
@@ -217,8 +217,11 @@ print OUTPUT "\x55\xaa";
 $totalsize = $c*$h*$s;
 $tracks    = $c*$h;
 
-# If -s is given, try to simply use truncate...
-unless ($opt{'s'} && truncate(OUTPUT, $totalsize)) {
+# If -s is given, simply use truncate. Do not care for success. Failure is
+# normal with Linux block devices.
+if ($opt{'s'}) {
+    truncate(OUTPUT, $totalsize * 512);
+} else {
     $track = "\0" x (512*$s);
 
     # Print fractional track
-------------------------------------------------------------------------

One could test for regular file and issue a warning message.
But i assume that access problems would already show up when
the MBR is written.

Is there the risk of 32 bit rollover with "$totalsize * 512"
with Perl on 32 bit machines ?
(My amd64 can handle -M 6000 255 63.)


After my wiki activities i still wonder:

Is mkdiskimage supposed to work on NT/2K/XP/DOS systems ?
Perl plus MS goes quite beyond my horizon.


Have a nice day :)

Thomas

Am 28.01.2014 08:44, schrieb Thomas Schmitt:
>
> Yes, we should probably fix that.  The tool was originally designed for
> images, not for hardware devices, and it doesn't make much sense to
zero
> the whole hardware device like that.
Probably not. But a left over backup GPT at the end of a "disk" (hard 
disk, thumb drive, SSD, eMMC) now confuses some UEFI implementations 
that look for GPT first (or only) on boot media.

Regards,
Mattias

PS: I just received some Bay Trail hardware, so let the fun wit 32 Bit 
UEFI begin.

-- 
Mattias Schlenker - Redaktion + EDV-Beratung + Linux-CD/DVD-Konzepte
August-Bebel-Str. 74 - 04275 LEIPZIG - GERMANY

Bitte fuer geschaeftliche Telefonate vorzugsweise die VoIP-Telefonnummer
+49 341 39290767 verwenden, da ich diese aufs Mobiltelefon routen kann!

Hi,

hpa wrote:
> > it doesn't make much sense to zero the whole hardware device like
that.
Mattias Schlenker wrote:
> Probably not. But a left over backup GPT at the end of a "disk"
(hard disk,
> thumb drive, SSD, eMMC) now confuses some UEFI implementations that look
for
> GPT first (or only) on boot media.
mkdiskimage does not reliably address this issue. It zeroises only
the partition, which may end nearly 8 MB before the device end.

By the same cause, image files do not get inflated to the full
size but only up to the partition end:

  $ mkdiskimage_orig.in -M image.img 100 255 63
  $ image.img
  -rw-r--r-- 1 xyz xyz  98703360 2014-01-29 10:31 image.img
  
This happens too with my proposed bug fix for option -s.
(truncate(OUTPUT, $totalsize * 512);)


@hpa:
Is this a bug or a feature ?


Have a nice day :)

Thomas

Hallo, Mattias,

Du meintest am 28.01.14:
>> Yes, we should probably fix that.  The tool was originally designed
>> for images, not for hardware devices, and it doesn't make much
sense
>> to zero the whole hardware device like that.
> Probably not. But a left over backup GPT at the end of a "disk"
(hard
> disk, thumb drive, SSD, eMMC) now confuses some UEFI implementations
> that look for GPT first (or only) on boot media.
Maybe it's a completely other problem: I had to learn that I had to  
delete other (older) file systems with "wipefs".

Especially when I worked with "btrfs".

Viele Gruesse!
Helmut