Query about parasitic firefox file

[Colin Watson]

On Thu, Mar 08, 2018 at 02:26:42PM +0100, Liam Proven wrote:
> On 8 March 2018 at 14:00, Colin Watson <cjwatson at ubuntu.com> wrote:
> > I must say that to me this looks like a system in dire need of being
> > converted to LVM, if the many filesystems can't be consolidated.  It's
> > then very much easier to extend, rearrange, and so on.  (Shrinking a
> > single filesystem is still often a slow process, but that's up to the
> > filesystem.)
> 
> Well, yes, in a way, but 2 questions...
> 
> [1] AFAIK it is not possible to dual-boot with Windows if the disk is
> partitioned with LVM.

I think this is incorrect.  LVM physical volumes are typically
partitions, not the whole disk, for flexibility and compatibility
reasons.  Windows would have to be on an ordinary partition rather than
in a logical volume, of course, and it wouldn't be able to see inside
the LVM volume group, but you could perfectly well have a partition or
two for Windows (and any shared data partitions that are needed) and
then have the rest of the disk be partitions containing LVM PVs.

As far as I know, Windows won't care about the content of the partitions
that contain PVs any more than it cares about the content of any other
partitions it doesn't understand.  It would have to actively put effort
into making this not work.

> [2] Is it possible to do an in-place conversion? I've read conflicting
> reports, of home-grown tools and so on, but it sounds tricky and
> possibly dangerous...

Well, it depends what you mean by "in-place".  If you have enough
unpartitioned space on your disk, then it's straightforward though
tedious, and doesn't require any special tools.  The procedure goes like
this:

 0) ensure that you have sufficient backups
 1) make a PV in the unpartitioned space
 2) add the new PV to a volume group (on the first iteration, this will
    be a new VG)
 3) make a logical volume for the biggest filesystem that will fit in
    the unallocated space in the VG
 4) make a filesystem in the new LV
 5) rsync data from the source filesystem to the target filesystem
 6) update fstab (making sure to use /dev/mapper/ paths rather than
    labels/UUIDs, to avoid future problems with LVM snapshots),
    unmount/remount, update boot loader and initramfs configuration (in
    the case of a root filesystem), and/or reboot if necessary to make
    sure everything still works
 7) delete the partition containing the filesystem you just moved
 8) if any more filesystems will fit in the unallocated space in the VG,
    go to 3
 9) if any filesystems still exist outside LVM that you want to move, go
    to 1

You obviously have to be careful and have a certain amount of general
sysadmin competence, but it doesn't take any scary machinery.  Bonus:
you can stop at the end of any iteration of this loop if you run out of
time or whatever.

I would certainly avoid tools that do *entirely* in-place conversions
without this sort of progressive reallocation approach.  It may well be
technically possible by rewriting bits of metadata around the existing
filesystems, but I agree with you that it sounds tricky and dangerous.

If there isn't enough unpartitioned space to take this approach, or if
the person executing the procedure isn't comfortable with any of the
steps in it, then it's probably going to be better to do step 0,
destructively repartition the system, and restore from backups.  Or just
make a mental note to use LVM for the next new system one installs ...

-- 
Colin Watson                                       [cjwatson at ubuntu.com]