Skip to content
This repository has been archived by the owner on Oct 16, 2024. It is now read-only.

Releases: intel/bmap-tools

Release v3.6

15 Feb 07:34
Compare
Choose a tag to compare
  1. Improve ZFS compatibility.
  2. Added the 'zstd' compression type support.
  3. Add '--psplash-pipe' option for interacting with psplash.

Release v3.5

15 Feb 07:33
Compare
Choose a tag to compare
  1. Fixed copying of compressed files from URLs.
  2. Python 3.x support fixes and improvements.

Release 3.4

04 Sep 17:22
@kad kad
v3.4
Compare
Choose a tag to compare
  1. bmap-tools has now new home: https://github.com/01org/bmap-tools

  2. Python 3.x support: bmap-tools now compatible with Python 3.3+

  3. bmaptool now can be shipped as standalone application.

  4. ZIP archives now supported. Similar to tar.* archives, image must be first file in archive.

  5. LZ4 compression now supported. Files with the following extensions are recognized as LZ4-compressed: .lz4, .tar.lz4 and .tlz4.

  6. Fixed copying images on XFS file system where predictive caching lead to more blocks to be mapped than needed.

  7. Fixed detection of block size on file systems that do not report it correctly via ioctl FIGETBSZ.

Installation

Linux

curl -Lo bmaptool  https://github.com/01org/bmap-tools/releases/download/v3.4/bmaptool && chmod +x bmaptool && mv bmaptool $HOME/bin/bmaptool

Feel free to leave off the mv bmaptool $HOME/bin if you would like to add bmaptool to your path manually.

Release 3.2

30 Mar 18:35
@kad kad
Compare
Choose a tag to compare
  1. Multi-stream bzip2 archives are now supported. These are usually created
    with the 'pbzip2' compressor.

  2. LZO archives are now supported too. Files with the following extensions are
    recognized as LZO-compressed: ".lzo", ".tar.lzo", ".tzo".

  3. Make 'bmaptool create' (and hence, the BmapCreate module) work with the
    "tmpfs" file-system. Tmpfs does not, unfortunately, support the "FIEMAP"
    ioctl, but it supports the "SEEK_HOLE" option of the "lseek" system call,
    which is now used for finding where the holes are. However, this works only
    with Linux kernels of version 3.8 or higher.

    Generally, "FIEMAP" is faster than "SEEK_HOLE" for large files, so we always
    try to start with using FIEMAP, and if it is not supported, we fall-back to
    using "SEEK_HOLE". Therefore, the "Fiemap" module was re-named to "Filemap",
    since it is now supports more than just the FIEMAP ioctl.

    Unfortunately, our "SEEK_HOLE" method requires the directory where the image
    resides to be accessible for writing, because in current implementation we
    need to create a temporary file there for a short time. The temporary file
    is used to detect whether tmpfs really supports SEEK_HOLE, or the system
    just fakes it by always returning EOF (this is what happens in pre-3.8
    kernels).

  4. Decompression should now require less memory, which should fix
    out-of-memory problems reported by some users recently. Namely, users
    reported that decompressing large bz2-compressed sparse files caused
    out-of-memory situation on machines with 2GB RAM. This should be fixed now.

  5. Reading and decompressing is now faster because we now use more parallelism:
    reading the data form the source URL is done in separate thread,
    decompressing happens in a separate process too. My measurement with Tizen
    IVI images from 'tizen.org' showed 10% read speed improvement, but this
    depends a lot on where the bottle-neck is: the USB stick, the network, or
    the CPU load.

Bug-fix release 3.1

30 Mar 18:40
@kad kad
Compare
Choose a tag to compare

This bug-fix release is about fixing a small screw-up in version 3.0, where we
introduced incompatible bmap format changes, but did not properly increase the
bmap format version number. Instead of making it to be version 2.0, we made it
to be version 1.4. The result is that bmap-tools v2.x crash with those
1.4-formatted bmap files.

This release changes the bmap format version from 1.4 to 2.0 in order to
lessen the versioning screw-up. Increased major bmap format version number will
make sure that older bmap-tools fail with a readable error message, instead of
crashing.

Thus, the situation as follows:

  • bmap-tools v2.x: handle bmap format versions 1.0-1.3, crash with 1.4, and
    nicely exit with 2.0
  • bmap-tools v3.0: handles all 1.x bmap format versions, exits nicely with 2.0
  • bmap-tools v3.1: handles all bmap format versions

Release 3.0

30 Mar 18:39
@kad kad
Compare
Choose a tag to compare
  1. Switch from using SHA1 checksums in the bmap file to SHA256. This required
    bmap format change. The new format version is 1.4. BmapCopy (and thus,
    bmaptool supports all the older versions too). Now it is possible to use any
    hash functions for checksumming, not only SHA256, but SHA256 is the default
    for BmapCreate.

  2. Support OpenPGP (AKA gpg) signatures for the bmap file. From now on the bmap
    file can be signed with gpg, in which case bmaptool verifies the bmap file
    signature. If the signature is bad, bmaptool exits with an error message.
    The verification can be disabled with the --no-sig-verify option.

    Both detached and "in-band" clearsign signatures are supported. Bmaptool
    automatically discovers detached signatures by checking ".sig" and ".asc"
    files.

  3. The Fiemap module (and thus, bmaptool) now always synchronizes the image
    before scanning it for mapped areas. This is done by using the
    "FIEMAP_FLAG_SYNC" flag of the FIEMAP ioctl.

    The reason for synchronizing the file is bugs in early implementations of
    FIEMAP in the kernel and file-systems, and synchronizing the image is a
    known way to work around the bugs.

Bug-fix release 2.6

30 Mar 18:38
@kad kad
Compare
Choose a tag to compare
  • Add on-the-fly decompression support for '.xz' and '.tar.xz' files.

Bug-fix release 2.5

30 Mar 18:37
@kad kad
Compare
Choose a tag to compare
  1. bmaptool (or more precisely, the BmapCopy class) has an optimization where
    we switch to the "noop" I/O scheduler when writing directly to block
    devices. We also lessen the allowed amount of dirty data for this block
    device in order to create less memory pressure on the system. These tweaks
    are done by touching the corresponding sysfs files of the block device. The
    old bmaptool behavior was that it failed when it could not modify these
    files. However, there are systems where users can write to some block
    devices (USB sticks, for example), but they do not have permissions to
    change the sysfs files, and bmaptool did not work for normal users on such
    systems. In version 2.5 we change the behavior and do not fail anymore if we
    do not have enough permissions for changing sysfs files, simply because this
    is an optimization, although a quite important one. However, we do print a
    warning message.
  2. Many improvements and fixes in the Debian packaging, which should make it
    simpler for distributions to package bmap-tools.