Query about parasitic firefox file

[Liam Proven]

On 8 March 2018 at 16:11, Colin Watson <cjwatson at ubuntu.com> wrote:

> 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.

Er. You noted that Bret's disk layout goes:

Dell
Windows
Windows
Extended:
  Linux
  Linux
  Linux
  Linux
  Linux
  Windows
  Linux
  Linux
  Linux

In other words, they are intermixed. I do not think Windows would take
well to that, do you?

An additional parethentical consideration:

Windows can, with the addition of suitable freeware drivers and tools,
read Linux partitions. This is useful. It will not work if you use
LVM.

Secondly, Bret has made comments that indicate some confusion and
problems with the current system -- e.g. his inability to remove an
old Debian partition, because he is running GParted _from within his
running system_.

LVM definitely offers more power and flexibilty, yes, but it is
undeniably more complex and requires more knowledge to successfully
use.

Frankly, without false modesty, I consider myself something of an
expert in the field of PC partitioning and filesystems, and it
confuses me!

I would most definitely _never_ recommend it to any person who:
* was dual-booting multiple non-Linux OSes
* already had a complex setup to deal with
* not a skilled practitioner in Linux server storage

So, not wishing to argue for the sake of it, but no, I think this is
very much *not* a good use case for LVM and I must strongly disagree
with your recommendation of it as a solution.

Similarly to disagreeing with Ralf last year when he advocated a
filesystem layout to someone that included provision for multi-booting
several OSes, when that person had just 1 working Linux and wanted
more space.

I worked in tech support for many years. When someone is in a bad
situation, the best answer is the simplest possible one that will
help. Any unnecessary complexity is an invitation to disaster.
Introducing any unnecessary complications, steps or tools is just
giving more chances for failure.

Remember the KISS principle. Always keep it as simple as possible.


> 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

By in-place, I mean is it possible to run  a command or tool that will
turn existing MBR partitions into LVM volumes, after which space can
be combined or re-allocated.

I do not mean a process of gradual incremental creation of new
volumes, moving  data into them, and then removing old ones. That is
not "in place".

If Bret is having difficulty removing one existing ext4 volume
(because it is mounted), is the complex 9-step process you suggest
really a good alternative?

I think the answer is a very clear "no".

> You obviously have to be careful and have a certain amount of general
> sysadmin competence,

But we have evidence that he does not have that.

> If there isn't enough unpartitioned space to take this approach,

There isn't. We can see that.

> or if
> the person executing the procedure isn't comfortable with any of the
> steps in it

We can already see that he is not.

> then it's probably going to be better to do step 0,
> destructively repartition the system, and restore from backups.

We do not know that he has any.

Why destructively repartition? There is nothing here that can't be
done with Gparted from a standard unmodified Ubuntu install medium.

> Or just
> make a mental note to use LVM for the next new system one installs ...

Not for those without a high level of technical skill, no.

An important element of giving advice is to pitch it at an appropriate
level for the person being advised.

-- 
Liam Proven • Profile: https://about.me/liamproven
Email: lproven at cix.co.uk • Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven
UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053