Solved: ssd hdd lvm bullseye

[paxmark1]

2016 I went with testing and lvm (logical volume manager). Pointed it to stable when it went stable.
2019 added ram and a ssd. I did a clean install. somehow I ended up with 2 lvm systems. raunes and dbnbuster

Code: Select all

 --- Physical volume ---
  PV Name               /dev/sdb3
  VG Name               raunes-vg
  PV Size               <1.82 TiB / not usable 4.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              476742
  Free PE               151925
  Allocated PE          324817
  PV UUID               TvpysL-c2KT-FNHM-v87l-cIdw-Tqhw-cJl0oF
   
  --- Physical volume ---
  PV Name               /dev/sda5
  VG Name               dbnbuster-vg
  PV Size               465.52 GiB / not usable 2.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              119173
  Free PE               13
  Allocated PE          119160
  PV UUID               HhAX3e-stRh-4aSV-wJ3e-5ldM-6QOd-p72aXC

Has not caused problems, but ... ugly. I am all set to do clean install of bullyseye and start with Sway WM ( I did like Sway and wayland on 2 1gb memory atom netbooks running sid and testing - but all old things die.)

All set to do a clean install. I am backed up sideways and upside down and have a list of all my programs.

hdd of 1.8 gb will have /DATA and /swap

ssd of 480 gb (/dev/sda) will have all the rest including /home.

Would having the ssd (/dev/sda) be set up with lvm and using a standard partioning method for the hdd (/dev/sdb) be a problem; or should I just go with standard parttioning for both drives. My undestanding is that lvm with a mixture of hard disk drives and solid drives is not the best usage.

peace out.

[p.H]

somehow I ended up with 2 lvm systems. raunes and dbnbuster
(...)
Has not caused problems, but ... ugly.

Why "ugly" ? Separate VGs for hard disks and SSDs is perfectly normal.

hdd of 1.8 gb will have /DATA and /swap
ssd of 480 gb (/dev/sda) will have all the rest including /home.

I suggest to put the swap on the SSD.

Would having the ssd (/dev/sda) be set up with lvm and using a standard partioning method for the hdd (/dev/sdb) be a problem

Not a problem if you don't need flexible volume management on the hard disk.

r should I just go with standard parttioning for both drives

Fine if you don't need flexible volume management on either drive.

My undestanding is that lvm with a mixture of hard disk drives and solid drives is not the best usage.

It is not the best usage of the SSD to mix the SSD and the hard drive in the same VG because you don't control LV physical allocation easily. Having separate VGs on the SSD and the hard drive is fine.

[paxmark1]

Thank you very kindly. I appreciate deeply.

[paxmark1]

Install did not go in perfect the first time, probably my error(s)

One was using default instead of defaults for fstab but the other one was when I changed to /dev/mapper/ as it seems to be default now

dev/mapper/VG/LG is incorrect Following the exact instructions of /dev/mapper/VG-LG /BLAH ... fixed the problem.

Sidenote I had been using gparted since Mandrake I believe, but with my WM of LXQT - the KDE partition manager has many fewer dependencies and seems nice. I just use it to view.

I can recommend going to testing if you so choose.

[p.H]

dev/mapper/VG/LG is incorrect Following the exact instructions of /dev/mapper/VG-LG /BLAH ... fixed the problem.

Indeed /dev/mapper/VG/LV is incorrect (and has always been AFAIK). Valid persistent notations are /dev/VG/LV and /dev/mapper/VG-LV (with - in VG and LV names escaped as --, so better avoid - in VG and LV names for better legibility), which are both symlinks pointing to the same actual (but not persistent) /dev/dm-X device node. I think /dev/VG/LV is more legible but /dev/mapper/VG-LV should be used in /etc/fstab and the kernel command line for the root or /usr so that the initramfs can guess it is a logical volume and try to activate it.