No worries! Happy to help, and the instructions will work with the HDD, just use the HDD/boot as the in. I shouldn’t have assumed the existing boot was an ssd. Good luck!!!
No worries! Happy to help, and the instructions will work with the HDD, just use the HDD/boot as the in. I shouldn’t have assumed the existing boot was an ssd. Good luck!!!
If you want to clone the existing system onto the new ssd, here’s the broad strokes of what you can do.
lsblk
and note the /dev/sdX
path of the system drive. Write it down./dev/sdX
path of the new ssd. Write it down.dd
command to clone the system drive to the new ssd. The command will look like this:`dd if=/dev/existingBootDrive of=/dev/newSSDDrive bs=8M status=progress oflag=direct’
This command will clone the exact data of the system drive to the new ssd. the if
portion of the command stands for in file
, as in the source of the data you want to clone. Make sure that is your existing boot drive. of
is the out file
, the destination of the clone. Make sure that is your new ssd.
When you do this, the new drive will appear to be the same size as the old drive. This is due to the cloning, but is easily resolved by resizing the partition(s). How you do this depends on the filesystem, so refer to this guide for resizing
UUID
s on the new ssd against what’s in /etc/fstab
on the new disk. To do this, run blkid
to get a list of all the partitions and their UUID
s. Note the UUID
s of the partitions on the new ssd./etc/fstab
, you’ll have to mount the root (/
) partition of the new drive somewhere in the live system. In the terminal you should already be in the home folder of the live system user. Make a new directory with mkdir
. Call it whatever you want. So something like: mkdir newboot
lsblk
and make note of the root partition on the new ssd, then mount that to newboot
(or whatever you called it) with sudo mount /dev/sdX newboot
(where X
is the actual device label for the root parition of the new drive`/etc/fstab
with your terminal text editor of choice. Compare the UUID
s to the ones you noted. If they are the same, you’re golden (they should be the same, but I’ve also had them change on me. ymmv). If they are different, delete the old UUID
and replace it with the new UUID
for each respective partiitonUUID
s to make sure there were no mistakes+1
I self host vaultwarden and its great. Its an easy self host, and in my experience, it has never gone down on me.
That being said, my experience is anecdotal. If you do go the vaultwarden route, realize that your vault is still accessible on your devices (phone, whatever) even if your server goes down, or if you just lose network connectivity. They hold local (encrypted at rest) copies of your vault that are periodically updated.
Additionally, regardless of the route you take you should absolutely be practicing a good 3-2-1 backup strategy with your password vault, as with any other data you value.
Karakeep might work for you
I love zoxide. Makes traversing the filesystem so much faster!
deleted by creator
This is exactly how I have mine set up and I really like it.
I’ve got an internal and external domain with a wildcard cert so if it’s a local only service I can easily create a newservice.localurl.com, and if it’s external I can just as easily set up newservice.externalurl.com
You could. I didn’t even think about it. I’m used to using
dd
, but clonezilla is a totally viable option here.