Resizing/formatting logical volumes for dual install

[random_jc]

By default, the desktop computer at my institution logs into a linux distribution over which I do not have admin rights (and a network connection is required to make it work). I want to install Linux Mint separately and have a dual boot option at startup. If I run the standard Mint install, the native OS is not detected and I am only offered to erase everything, which I would like to avoid. Attached is a screenshot of GParted, as seen from the Mint live USB.

In my understanding, the difficulty is that from the point of view of GParted, basically everything is bundled into a single lvm partition. I can have a more detailed picture by querying:

Code: Select all

mint@mint:~$ sudo fdisk -l
Disk /dev/loop0: 1.8 GiB, 1925435392 bytes, 3760616 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 270CF93F-236A-4B70-A407-D46FE35BD8A0

Device         Start       End   Sectors   Size Type
/dev/sda1       2048      4095      2048     1M BIOS boot
/dev/sda2       4096   1028095   1024000   500M Microsoft basic data
/dev/sda3    1028096 499707903 498679808 237.8G Linux LVM
/dev/sda4  499707904 500117503    409600   200M Microsoft basic data


Disk /dev/sdb: 14.6 GiB, 15664676864 bytes, 30595072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x65dbb3bc

Device     Boot Start     End Sectors  Size Id Type
/dev/sdb1  *        0 3924479 3924480  1.9G  0 Empty
/dev/sdb2         652    5323    4672  2.3M ef EFI (FAT-12/16/32)


Disk /dev/mapper/vg_box102-swaplv: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mapper/vg_box102-lv_scratch: 179.8 GiB, 193042841600 bytes, 377036800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mapper/vg_box102-lv_root: 50 GiB, 53687091200 bytes, 104857600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

I explored the disks from the native OS, and the scratch disk appears to be empty. So I would like to take this partition "back under control" and install Mint there (or alternatively, to shrink it a lot and use the free space to install Mint).

I do not know how to do this, and I would want to "get it right" the first time, so I want to be extra cautious before taking any step (because I would like to reduce as much as possible the chances to destroy the native OS). I would really appreciate any suggestion on how to proceed.

[rene]

That's a fairly intricate setup; with GPT on a BIOS-machine and LVM. I must say I'm not too sure how the installer copes with an existing LV: if you in the installer choose the "Something else" option, can you then not pick /dev/mapper/vg_box102-lv_scratch as your to be installed system's /?

Note, I'd not in fact (yet) do that even if you can; would indeed resize vg_box102-lv_scratch so as to make sure(r) that the original OS doesn't all of a sudden find something gone it thought would be there. However, that's for later: I'm first of all curious if the installer allows you to install onto the existing ..._scratch in the first place.

It's relatively interesting so I'll try and setup a VM to test tonight if you have the time to spare...

Oh, and by the way, if you have a spare 250G or so USB drive to attach to the system you can always do a byte-for-byte copy of the entire drive onto it first so you can always restore it to original.

[random_jc]

Yes, the installer seems to allow me to do that. To be precise, I attach a screenshot of the installer (the list of "devices" goes further than what is displayed). On the screenshot I already asked that the scratch partition be reformatted into ext4 and mounted as /.

I have plenty of time for doing the actions, so I'm happy to wait for the results of your experiments (I don't have a large USB drive though, so I'll have to do without doing the hard-drive bit-by-bit copy.)

[rene]

OK, looking to be essentially easy then. Not confident enough to advise on the resize of "scratch" and creating a new / partition for the Mint install without in fact trying it, so hang on (for a few hours...)

[rene]

Well, that was uneventful; Linux is officially no fun any more; everything Just Works. That is...

1. I created the following initial situation so as to mimic yours (although in my case a Linux Mint 19.2 Cinnamon 64-bit system). From a root prompt on the Linux Mint 19.2 Cinnamon 64-bit install DVD/USB:

Code: Select all

root@mint:~# fdisk -l
Disk /dev/loop0: 1.8 GiB, 1925435392 bytes, 3760616 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sda: 75 GiB, 80530636800 bytes, 157286400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E3E3D2ED-06AA-43AC-A1D4-74E13D6BB87C

Device     Start       End   Sectors  Size Type
/dev/sda1     34      2047      2014 1007K BIOS boot
/dev/sda2   2048 157286366 157284319   75G Linux LVM


Disk /dev/mapper/vg_box102-swaplv: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/vg_box102-lv_root: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/vg_box102-lv_scratch: 47 GiB, 50461671424 bytes, 98557952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

2. I then reduced lv_scratch by 20G and created a new lv_mint in the free space:

Code: Select all

root@mint:~# lvreduce --resizefs -L-20G vg_box102/lv_scratch
fsck from util-linux 2.31.1
/dev/mapper/vg_box102-lv_scratch: clean, 11/3080192 files, 272209/12319744 blocks
resize2fs 1.44.1 (24-Mar-2018)
Resizing the filesystem on /dev/mapper/vg_box102-lv_scratch to 7076864 (4k) blocks.
The filesystem on /dev/mapper/vg_box102-lv_scratch is now 7076864 (4k) blocks long.

  Size of logical volume vg_box102/lv_scratch changed from <47.00 GiB (12031 extents) to <27.00 GiB (6911 extents).
  Logical volume vg_box102/lv_scratch successfully resized.
root@mint:~# lvcreate -l 100%FREE -n lv_mint vg_box102
  Logical volume "lv_mint" created.

3. Started the install again, picked the "something else" option and chose /dev/mapper/vg_box102-lv_mint to be formatted ext4 and mounted on /.

I didn't explicitly denote /dev/mapper/vg_box102-swaplv as swap, assuming the installer would pick that up automatically but it didn't; it installed using a /swapfile instead, so you should probably explicitly set it to "swap" so as to reuse that swap partition. Bootloader install is simply set to /dev/sda, it will install onto that created BIOS boot partition automatically.

4. Rebooted to a Grub menu listing both the initial and new installs and could boot either.

As far as I can see there's little potential for this turning more involved in your case; lv_scratch is also for you ext4 and, therefore also, apparently not LUKS-encrypted, so the lvreduce should work just the same it seems. Don't forget the --resizefs parameter.

Clearly, no warranty

[random_jc]

Thanks a lot! One point I want to clarify before I give it a try: in the installer the "scratch" partition initially appeared with the "xfs" type, not the ext4 type. I had manually asked that it be formatted into the ext4 format before taking the screenshot. Does that change something?

[rene]

Actually, yes. From http://xfs.org/index.php/Shrinking_Support

Currently XFS Filesystems can't be shrunk.

And indeed, with lv_scratch re-expanded and reformatted to xfs:

Code: Select all

root@mint:~# lvreduce --resizefs -L-20G vg_box102/lv_scratch
Phase 1 - find and verify superblock...
[ ... ]
fsadm: Xfs filesystem shrinking is unsupported.
  /sbin/fsadm failed: 1
  Filesystem resize failed.

Is there anything on lv_scratch? If yes, more than can be temporarily backed up to lv_root? If not you can do so, lvremove all of lv_scratch, recreate lv_scratch smaller, reformat it as xfs and restore what you backed up from it, then lvcreate the new lv_mint as before in the free space.

Wanting to resize the just about only Linux filesystem type that can not be is rather unfortunate...

[random_jc]

I believe that there is really nothing on "scratch", so I want to do as you just said. Can you give me a little bit more guidance on how to do it? I think I'll then be ready to go

[rene]

Sure. But I'd first make really sure:

Code: Select all

root@mint:~# mount /dev/mapper/vg_box102-lv_scratch /mnt
root@mint:~# ls -al /mnt

Nothing indeed?

Code: Select all

root@mint:~# umount /mnt
root@mint:~# lvremove vg_box102/lv_scratch
Do you really want to remove and DISCARD active logical volume vg_box102/lv_scratch? [y/n]: y
  Logical volume "lv_scratch" successfully removed
root@mint:~# lvcreate -L 20G -n lv_scratch vg_box102 
WARNING: xfs signature detected on /dev/vg_box102/lv_scratch at offset 0. Wipe it? [y/n]: y
  Wiping xfs signature on /dev/vg_box102/lv_scratch.
  Logical volume "lv_scratch" created.
root@mint:~# mkfs -t xfs /dev/mapper/vg_box102-lv_scratch 
meta-data=/dev/mapper/vg_box102-lv_scratch isize=512    agcount=4, agsize=1310720 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0, rmapbt=0, reflink=0
data     =                       bsize=4096   blocks=5242880, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
root@mint:~# lvcreate -l 100%FREE -n lv_mint vg_box102
  Logical volume "lv_mint" created.

Of course, the 20G this picks for the new lv_scratch is up to you...

[random_jc]

Thanks! The commands you want to see indeed returned nothing, as far as I understand:

Code: Select all

mint@mint:~$ sudo mount /dev/mapper/vg_box102-lv_scratch /mnt
mint@mint:~$ sudo ls -al /mnt
total 0
drwxrwxrwt. 2 root root   6 Sep 12 13:14 .
drwxr-xr-x  1 root root 260 Sep 13 08:55 ..

So, I'll wait for your final green light on this, and I'll give it a try! Whatever happens, I am super thankful for your help. Maybe there will be surprises, but the chances of that have been greatly reduced by your intervention!

[rene]

Yes, if the subsequent umount /mnt does not complain that nothing was in fact mounted on /mnt (i.e., there was indeed no output from the mount itself) then you may feel free to pick this up at said umount and then at 3 in the original reply. I believe it'll be fairly safe also as far as the old system is concerned.

[EDIT] By the way, all those commands need root, so rather than sudo each time, I'd advise sudo -s to open a root shell to work from.

[Rocky Bennett]

To the OP, If I were you I would consult with your IT manager because messing around with your Institution's PC might mess things up and be against policy.

[rene]

Aah, live a little...

[random_jc]

So I changed the partitions as planned. I could then verify that I can still log in and operate with the native OS. There was a problem on shutdown, where it complained that it "cannot umount /oldroot", and then it stalled there, and I had to force stop. I'll proceed with the Mint install, but if you have suggestions about this shutdown thing, I'm interested.

[EDIT] on a second try, shutdown went on perfectly smoothly

[rene]

Also couldn't really say what that was. The old system will have found a new logical volume lv_mint; maybe something from your old system was trying to in fact access it but hung due to no filesystem yet being present.... or something. Does not seem to agree with a second boot/shutdown working, but if it's fixed itself, I wouldn't worry about it; only if there's an issue once you've installed Mint onto the new logical volume.

[random_jc]

Everything seems to be working perfectly! Thank you so much! We should definitely add some emojis to express deep gratitude!

[rene]

The [SOLVED] will do; cheers.

[rene]

One thing I'm noticing on review: have you also verified that the lv_scratch filesystem is still available from/in the original system if originally it was? I expect it will be, that it was mounted through its device specifier /dev/mapper/vg_box102-lv_scratch, but the more modern thing is to specify file systems via UUID and since we now recreated the file system rather than just shrunk it we'll have created it with a new UUID.

That is... if you could originally access the lv_scratch file system from, say, /mnt/scratch or wherever it lived and can still, all well. If you could originally but not now take a look at the original system's /etc/fstab. If it specifies the lv_scratch fs through UUID run blkid or blkid -a (latter for older versions), note the UUID for lv_scratch and update it in /etc/fstab. After sudo mount -a it should then be back.

[EDIT] As to the "and update it" bit; you said you didn't have admin access. Can do from the Mint system or can conversly update the FS UUID to the fstab UUID but I'll for now assume there's no issue; it's actually fairly standard still to specify via logical volume for LVM...

[random_jc]

Oops... After the Mint install I can no longer log into the native OS... The startup displays

Code: Select all

[FAILED] Failed to start Switch Root.
See 'systemctl status initrd-switch-root.services' for details

Generating "/run/initramfs/rdsosreport.txt"

Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run//initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.

:/#

[rene]

That'll probably not in fact be a large problem. Either a simple matter of needing some custom kernel parameters, or if heavily customized, using the Grub from the original OS entirely (that did use Grub, didn't it?). I must be off to bed, but for tomorrow: what OS is in fact the original OS? I.e., Debian, Ubuntu, ...