1. 01 Aug, 2018 5 commits
    • Mike Fleetwood's avatar
      Update Autoconf macro AX_CXX_COMPILE_STDCXX_11 to latest serial 18 · c9f0677c
      Mike Fleetwood authored
      Update to the latest version of the AX_CXX_COMPILE_STDCXX_11 macro from
      the Autoconf Archive,  Note that the macro now depends on
      AX_CXX_COMPILE_STDCXX so this macro has to be included too.
    • Mike Fleetwood's avatar
      Remove unused member Win_GParted::menu_item · 73e7367e
      Mike Fleetwood authored
      Usage of menu_item was removed in this commit from 2006.
          happy new year ;) fixed some alignment issues removed confirmation dialogs
    • Mike Fleetwood's avatar
      Remove unused members Win_GParted::label_device_info[12] · 5d6f405b
      Mike Fleetwood authored
      Usage of members label_device_info1 and label_device_info2 was removed
      in this commit from 2004.
          several (mostly) i18n related fixes/cleanups
    • Mike Fleetwood's avatar
      Re-add getting EXT2/3/4 free space from dumpe2fs as a fallback (#8) · ed17982e
      Mike Fleetwood authored
      If an EXT2/3/4 file system needs checking, then resize2fs will report an
      error, rather than report the minimum file system size.
          # mkfs.ext4 /dev/sdb11
          # resize2fs -P /dev/sdb11
          resize2fs 1.42.9 (28-Dec-2013)
          Estimated minimum size of the filesystem: 17012
          # debugfs -w -R "ssv state 0" /dev/sdb11
          # resize2fs -P /dev/sdb11
          resize2fs 1.42.9 (28-Dec-2013)
          Please run 'e2fsck -f /dev/sdb11' first.
          # echo $?
      This will prevent GParted reading the file system usage and in turn
      GParted won't allow the file system to be shrunk.  Re-add the previous
      method of reading the free space from dumpe2fs output as a fallback.
      With this change, the worst case scenario is that GParted allows the
      user to attempt to shrink an unclean EXT4 file system, smaller that that
      which resize2fs allows and gets an error telling them so.  As part of
      the failed shrink operation GParted will have checked the file system so
      on refresh GParted will get the correct minimum size next time.
      This scenario only seems to apply to unclean EXT4 file systems because
      resize2fs has a larger minimum size that the free blocks would suggest
      because of extra space requirements when resizing EXT4 file systems [1].
      [1] e2fsprogs 1.44.3, resize/resize2fs.c:calculate_minimum_resize_size()
           * For ext4 we need to allow for up to a flex_bg worth of
           * inode tables of slack space so the resize operation can be
           * guaranteed to finish.
           * We need to reserve a few extra blocks if extents are
           * enabled, in case we need to grow the extent tree.  The more
           * we shrink the file system, the more space we need.
           * The absolute worst case is every single data block is in
           * the part of the file system that needs to be evacuated,
           * with each data block needs to be in its own extent, and
           * with each inode needing at least one extent block.
      Closes #8 - Shrinking an EXT4 partition does not respect resize2fs
    • Mike Fleetwood's avatar
      Use resize2fs -P to get minimum EXT2/3/4 FS size (#8) · fe83f629
      Mike Fleetwood authored
      A user reported GParted failed to shrink an EXT4 file system because
      GParted tried to shrink it smaller than resize2fs reported minimum size.
      Operation details were:
          Shrink /dev/sdc1 from 931.51 GiB to 605.00 GiB             (ERROR)
            calibrate /dev/sdc1                                      (SUCCESS)
              path: /dev/sdc1 (partition)
              start: 63
              end: 1953520064
              size: 1953520002 (931.51 GiB)
            check file system on /dev/sdc1 for errors and (if poss...(SUCCESS)
              e2fsck -f -y -v -C 0 '/dev/sdc1'                       (SUCCESS)
                158165624 blocks are used (64.77% of 244190000)
            shrink file system                                       (ERROR)
              resize2fs -p '/dev/sdc1' 634389176K                    (ERROR)
                resize2fs 1.44.2 (14-May-2018)
                resize2fs: New size smaller than minimum (171882113)
      The GParted figures:
       *  Partition size    = 1953520064 (512b sectors) = 976760032 KiB
       *  FS size           = 244190000 (4K blocks)     = 976760000 KiB
       *  Used FS size      = 158165624 (4K blocks)     = 632662496 KiB
       *  Requested FS size                             = 634389176 KiB
      The resize2fs figure:
       *  Minimum FS size   = 171882113 (4K blocks)     = 687528452 KiB
      GParted uses the number of free blocks in the file system to determine
      the minimum size it can shrink a file system to.  However resize2fs uses
      it's own internally calculated minimum size and won't shrink a file
      system below that size, as seen in the above details.  Resize2fs does
      have a force flag, (-f) which overrides some safety checks which are
      normally enforced, to allow it to try to shrink a file system smaller
      than it's calculated minimum.  GParted currently doesn't use the force
      flag and it seems unwise for it to start to do so.
      So for unmounted EXT2/3/4 file systems, change GParted to use
      'resize2fs -P' to get the minimum file system size, rather than using
      the number of free blocks direct from the super block, as reported by
      'dumpe2fs -h'.
      Mounted file systems still use statvfs() to provide file system usage.
      As mounted EXT2/3/4 file systems can't be shrunk the fact that statvfs()
      produces different, possibly smaller than minimum, figures than those
      from 'resize2fs -P' doesn't matter.
      Closes #8 - Shrinking an EXT4 partition does not respect resize2fs
  2. 31 Jul, 2018 1 commit
    • Mike Fleetwood's avatar
      Work in FS blocks until later while reading EXT2/3/4 usage (#8) · ef8dbe8f
      Mike Fleetwood authored
      No functional change.  Just work in FS block sized units until as late
      as possible in ext2::set_used_sectors(), before converting to device
      sector size units.  This is to make the following change simpler and
      easier to understand.
      Closes #8 - Shrinking an EXT4 partition does not respect resize2fs
  3. 24 Jul, 2018 1 commit
  4. 23 Jul, 2018 2 commits
    • Mike Fleetwood's avatar
      Stop parallelising make distcheck in GitLab CI test jobs (!6) · 112f1d3e
      Mike Fleetwood authored
      Unfortunately parallelising 'make distcheck' causes it to fail like
          $ nproc=`grep -c '^processor' /proc/cpuinfo` || nproc=1
          $ echo nproc=$nproc
          $ make -j $nproc distcheck
          make[1]: Entering directory '/builds/mfleetwo/gparted/gparted-0.31.0-git/_build/sub'
          ERROR: files left after uninstall:
          Makefile:896: recipe for target 'distuninstallcheck' failed
          make[1]: Leaving directory '/builds/mfleetwo/gparted/gparted-0.31.0-git/_build/sub'
          make[1]: *** [distuninstallcheck] Error 1
          make: *** [distcheck] Error 1
          Makefile:840: recipe for target 'distcheck' failed
          ERROR: Job failed: exit code 1
      Therefore go back to serial 'make distcheck'.
      Closes !6 - Reduce the time taken by the GitLab CI jobs
    • Mike Fleetwood's avatar
      Parallelise building GParted in GitLab CI jobs (!6) · ed06299c
      Mike Fleetwood authored
      Reduce the time taken by the GitLab Continuous Integration jobs by
      parallelising make to use all available CPUs in the Docker CI image
      when it is building GParted code.  This includes 'make diskcheck'
      because that also does a second build of the GParted code in a separate
      Closes !6 - Reduce the time taken by the GitLab CI jobs
  5. 19 Jul, 2018 3 commits
  6. 08 Jul, 2018 3 commits
    • Mike Fleetwood's avatar
      Add CI job to test GParted on Ubuntu (!4) · 8cd2181b
      Mike Fleetwood authored
      Closes !4 - Add GitLab CI jobs to build and test GParted
    • Mike Fleetwood's avatar
      Add CI job to build GParted on Ubuntu (!4) · 391aebae
      Mike Fleetwood authored
      Closes !4 - Add GitLab CI jobs to build and test GParted
    • Mike Fleetwood's avatar
      Parameterise CI config ready for also using a Ubuntu image (!4) · eb243523
      Mike Fleetwood authored
      Prepare the GitLab Continuous Integration configuration for also
      building and testing GParted on a Ubuntu image.  The definition of the
      image and before_script, which so far specify the CentOS Docker image
      and how to install the required RPM packages, need to move from being
      top level nodes to being defined per job.  Namely within jobs
      'centos_build' and 'centos_test'.
      To avoid duplicating various nodes within multiple jobs, YAML anchors
      (&LABEL) and references (*LABEL) are used.  They are defined in ignored
      jobs, job names starting with a dot (.).
      Closes !4 - Add GitLab CI jobs to build and test GParted
  7. 05 Jul, 2018 5 commits
    • Mike Fleetwood's avatar
      Rename CI jobs to reflect that they use a CentOS Docker image (!4) · a6b0a26c
      Mike Fleetwood authored
      Ready for adding additional Continuous Integration jobs using different
      distribution Docker images.  Rename thus:
          build -> centos_build
          test  -> centos_test
      Closes !4 - Add GitLab CI jobs to build and test GParted
    • Mike Fleetwood's avatar
      Exclude unit test which fails in Docker CI image (!4) · fe2fc33e
      Mike Fleetwood authored
      Fragment of the tests/test-suite.log from the Docker CI image showing
      details of the unit test failure:
          Running main() from gtest_main.cc
          [==========] Running 26 tests from 1 test case.
          [----------] Global test environment set-up.
          [----------] 26 tests from BlockSpecialTest
          [ RUN      ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches
          test_BlockSpecial.cc:137: Failure
          get_link_name(): Failed to open directory '/dev/disk/by-id'
          test_BlockSpecial.cc:168: Failure
          follow_link_name(): Failed to resolve symbolic link ''
          test_BlockSpecial.cc:255: Failure
          Expected: (lnk.m_name.c_str()) != (bs.m_name.c_str()), actual: "" vs ""
          [  FAILED  ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches (0 ms)
          [==========] 26 tests from 1 test case ran. (1 ms total)
          [  PASSED  ] 25 tests.
          [  FAILED  ] 1 test, listed below:
          [  FAILED  ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches
           1 FAILED TEST
      So the code is trying to find a symbolic link to a block device to use
      in the test.  It is trying to read the directory /dev/disk/by-id to find
      a symbolic link, but the directory doesn't exist in the Docker CI image.
      The used directory was recently changed [1] to use one which existed on
      all distributions.  Docker images don't even have the /dev/disk
      directory.  Exclude just this specific test.
      [1] 7fe41480
          Use /dev/disk/by-id/ to get device symlink in test_BlockSpecial
      Closes !4 - Add GitLab CI jobs to build and test GParted
    • Mike Fleetwood's avatar
      Debug unit test failure in CI test job (!4) · f5e161f6
      Mike Fleetwood authored
      Recursively list all the files below /dev as part of the 'test' job as
      certain block device names are needed by the failing test_BlockSpecial
      unit test.
      The artifact captures all the files from the directory in which the CI
      script runs to build and test GParted.  It creates a ZIP file which can
      be downloaded after the job finishes, whether the job succeeds of fails.
      This is to capture logs from the failure of the test_BlockSpecial unit
      Closes !4 - Add GitLab CI jobs to build and test GParted
    • Mike Fleetwood's avatar
      Add CI testing job on CentOS (!4) · e76a3874
      Mike Fleetwood authored
      Add GitLab Continuous Integration job named 'test' which runs the
      GParted unit tests and distcheck.  Note that the job starts from a fresh
      official CentOS Docker image so also has to rebuild GParted too.
      So far this job fails on unit test test_BlockSpecial.  Fragment of the
      CI job log:
          make  check-TESTS
          make[2]: Entering directory `/builds/mfleetwo/gparted/tests'
          make[3]: Entering directory `/builds/mfleetwo/gparted/tests'
          PASS: test_dummy
          FAIL: test_BlockSpecial
          PASS: test_PasswordRAMStore
          PASS: test_PipeCapture
          make[4]: Entering directory `/builds/mfleetwo/gparted/tests'
          make[4]: Nothing to be done for `all'.
          make[4]: Leaving directory `/builds/mfleetwo/gparted/tests'
          Testsuite summary for gparted 0.31.0-git
          # TOTAL: 4
          # PASS:  3
          # SKIP:  0
          # XFAIL: 0
          # FAIL:  1
          # XPASS: 0
          # ERROR: 0
          See tests/test-suite.log
          Please report to https://bugzilla.gnome.org/enter_bug.cgi?product=gparted
      Closes !4 - Add GitLab CI jobs to build and test GParted
    • Mike Fleetwood's avatar
      Create initial GitLab CI job which builds on CentOS (!4) · 8fc4488f
      Mike Fleetwood authored
      Initial GitLab Continuous Integration configuration with a single job
      named 'build' which just confirms GParted can be built and installed on
      the latest official CentOS Docker image.
      Closes !4 - Add GitLab CI jobs to build and test GParted
  8. 01 Jul, 2018 2 commits
  9. 27 Jun, 2018 1 commit
  10. 22 Jun, 2018 1 commit
  11. 21 Jun, 2018 1 commit
    • Mike Fleetwood's avatar
      Fix LVM2 PV shrinking with lvm2 2.02.171 and later (#1) · 5892b728
      Mike Fleetwood authored
      Shrinking an LVM2 Physical Volume on CentOS 7 with the latest
      lvm2 2.02.177 fails like this:
        Shrink /dev/sda9 from 1.00 GiB to 768.00 MiB
        * calibrate /dev/sda9
        * check file system on /dev/sda9 for errors and (if possib...(SUCCESS)
        * shrink file system                                         (ERROR)
          * lvm pvresize -v --setphysicalvolumesize 786432K '/dev/...(ERROR)
              0 physical volume(s) resized / 1 physical volume(s) not resized
              Wiping internal VG cache
              Wiping cache of LVM-capable devices
              /dev/sda9: Requested size 712.00 MiB is less than real size 1.00 GiB.  Proceed? [y/n]:[n]
              Physical Volume /dev/sda9 not resized.
      This upstream change to lvm2 [1] makes pvresize prompt for confirmation
      whenever the --setphysicalvolumesize option is used.  (The change was
      included in lvm2 2.02.171 and later, which is used in recent
      distributions.  The reporter found the issue on Ubuntu 18.04 LTS and I
      reproduced the issue on RHEL/CentOS 7.5).  The set size option has to be
      used when shrinking the PV before shrinking the partition therefore fix
      this issue by adding lvm common option --yes when using the set size
      [1] https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=cbc69f8c693edf0d1307c9447e2e66d07a04bfe9
          pvresize: Prompt when non-default size supplied.
      Closes #1 - Can't shrink LVM partition due to pvresize prompt
  12. 19 Jun, 2018 7 commits
  13. 18 Jun, 2018 6 commits
  14. 13 Jun, 2018 1 commit
  15. 25 May, 2018 1 commit