Commit Graph

14 Commits

Author SHA1 Message Date
Marcel Moolenaar
4299711473 o Provide a private definition for UUIDs (mkimg_uuid_t) because
UUIDs are not portable.
 o  Move mkimg_uuid() to a new file and merge both gpt_uuid_enc()
    and vhd_uuid_enc() into a single mkimg_uuid_enc() that lives
    in the same file.
 o  Move the OS-specific implementation of generating a UUID to
    osdep_uuidgen() and provide the implementations for FreeBSD,
    macOS and Linux.
 o  Expect the partitioning scheme headers to be found by having
    a search to the directory in which the headers live. This
    avoids conflicts on non-FreeBSD machines.
2016-10-18 01:55:07 +00:00
Marcel Moolenaar
8d249f5e2f Switch to using the portable partition scheme headers. 2016-10-16 02:55:52 +00:00
Marcel Moolenaar
6b1235713e Prefer <stdint.h> over <sys/types.h>. While here remove redundant
inclusion of <sys/queue.h>.

Move the inclusion of the disk partitioning headers out of order
and inbetween standard headers and local header. They will change
in a subsequent commit.
2016-10-03 02:37:28 +00:00
Marcel Moolenaar
1080fb197b Replace STAILQ with TAILQ. TAILQs are portable enough that they can
be used on both macOS and Linux. STAILQs are not. In particular,
STAILQ_LAST does not next on Linux. Since neither STAILQ_FOREACH_SAFE
nor TAILQ_FOREACH_SAFE exist on Linux, replace its use with a regular
TAILQ_FOREACH. The _SAFE variant was only used for having the next
pointer in a local variable.
2016-10-03 01:46:47 +00:00
Marcel Moolenaar
5aad7d9a87 Avoid depending on the <sys/endian.h> header for le*enc and be*enc.
Not only is the header unportable, the encoding/decoding functions
are as well.  Instead, duplicate the handful of small inlines we
need into a private header called endian.h.

Aside: an alternative approach is to move the encoding/decoding
functions to a separate system header.  While the header is still
nonportable, such an approach would make it possible to re-use the
definitions by playing games with include paths. This may be the
preferred approach if more (build) utilities need this.  This
change does not preclude that.  In fact, it makes it easier.
2016-09-26 01:06:32 +00:00
Marcel Moolenaar
53fcdb2d1a Fix partition alignment and image rounding when any of -P (block size),
-T (track size) or -H (number of heads) is given:
o   scheme_metadata() always rounded to the block size.  This is not
    always valid (e.g. vtoc8 that must have partitions start at cylinder
    boundaries).
o   The bsd and vtoc8 schemes "resized" the image to make it match the
    geometry, but since the geometry is an approximation and the size
    of the image computed from cylinders * heads * sectors is always
    smaller than the original image size, the partition information ran
    out of bounds.

The fix is to have scheme_metadata() simply pass it's arguments to the
per-scheme metadata callback, so that schemes not only know where the
metadata is to go, but also what the current block address is. It's now
up to the per-scheme callback to reserve room for metadata and to make
sure alignment and rounding is applied.

The BSD scheme now has the most elaborate alignment and rounding. Just
to make the point: partitions are aligned on block boundaries, but the
image is rounded to the next cyclinder boundary.

vtoc8 now properly has all partitions aligned (and rounded) to the
cyclinder boundary.

Obtained from:	Juniper Networks, Inc.
MFC after:	3 days
2014-09-19 23:16:02 +00:00
Marcel Moolenaar
de3307644e Be compatible with boot code that starts right after the disk label in
the second sector by only clearing the amount of bytes needed for the
disklabel in the second sector. Previously we were clearing exactly 1
sector worth of bytes and as such writing over boot code that may have
been there.
Since we do support more than 8 partitions, make sure to set all fields
in d_partitions. For the first 8 partitions this is unneeded, but for
partitioons 9 and up this compensates for the fact that we don't clear
an entire sector anymore.
Obviously, one cannot use more than 8 partitions when using boot code
that starts right after the disk label.

Relevant GRNs:
107879 - Employ unused bytes after the disklabel in the second sector.
189500 - Revert the part of change 107879 that employs the unused bytes
	 after the disklabel in the 2nd sector for boot code.

Obtained from:	Juniper Networks, Inc.
MFC after:	3 days
2014-09-12 04:15:35 +00:00
Marcel Moolenaar
04ca14cc2a Fix checksum calculation:
1.  Iterate over all partitions counted in the label, which can be more
    than the number of partitions given to mkimg(1).
2.  Start the checksum from the beginning of the label; not the beginning
    of the bootarea.

Tested with bsdlabel(8).

MFC after:	3 days
2014-09-12 03:54:16 +00:00
Marcel Moolenaar
762ff43901 Fix CID 1204379 (vtoc8.c) & CID 1204380 (bsd.c): Cast ncyls to lba_t
before multiplying the 32-bit integrals to avoid any possibility of
truncation before widening. Not a likely scenario to begin with...
2014-05-21 17:39:49 +00:00
Marcel Moolenaar
9746454f54 Fix CID 1215128: Free the allocated buf when image_set_size()
returns and error and we return from bsd_write().
2014-05-21 17:36:12 +00:00
Marcel Moolenaar
f0e9dced5c MFuser/marcel/mkimg:
Add support for different output formats:
1.  The output file that was previously written is now called the raw format.
2.  Add the vmdk output format to create VMDK images.

When the format is not given, the raw output format is assumed.
2014-05-15 19:19:57 +00:00
Marcel Moolenaar
789a10b106 Add mkimg_write() which combines lseek(2) and write(2) and uses
sector granularity for both offset and length. Have all schemes
use mkimg_write() instead of mkimg_seek() followed by write(2).

Now that schemes don't use lseek(2) nor write(2) directly, it's
easier to support output formats other than raw disks.
2014-05-06 21:54:05 +00:00
Marcel Moolenaar
f529e2e0a5 Fix build on FreeBSD 8 where partition types for nandfs do not exist. 2014-03-29 22:10:54 +00:00
Marcel Moolenaar
a5eb4ea3ee Add mkimg, a utility for making disk images from raw partition contents.
The partitioning scheme can be one of the schemes supported by gpart.

Reviewed by:	sjg
Obtained from:	Juniper Networks, Inc.
2014-03-29 19:03:10 +00:00