• 0 Posts
  • 8 Comments
Joined 1 year ago
cake
Cake day: February 17th, 2024

help-circle


  • If you want to clone the existing system onto the new ssd, here’s the broad strokes of what you can do.

    1. Get a usb stick and write your linux distro of choice to it. Doesn’t really matter which one, we’re just using this to clone the system drive to the new drive. You want the system drive to be totally inactive during the clone which is why you’ll do it from a live usb rather than with the system itself booted.
    2. shut down the system
    3. Install the new ssd. DO NOT REMOVE THE CURRENT SYSTEM/BOOT SSD. You should now have two ssds installed.
    4. If you can’t install the second ssd, plug it in to usb via an enclosure
    5. Boot from the live usb
    6. open the terminal
    7. run lsblk and note the /dev/sdX path of the system drive. Write it down.
    8. From the same output, note the /dev/sdX path of the new ssd. Write it down.
    9. Use the 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

    1. Once you’ve resized the partition/disk, double check the partition UUIDs 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 UUIDs. Note the UUIDs of the partitions on the new ssd.
    2. To check /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
    3. run 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`
    4. open /etc/fstab with your terminal text editor of choice. Compare the UUIDs 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 partiiton
    5. Shut down the system
    6. Remove the old boot drive, and install the new boot drive in it’s place
    7. Boot the system. If all goes well, you’ll boot right into tumbleweed as if nothing has changed except you’re running from your shiny new ssd
    8. If it doesn’t boot, boot again from the live usb, and again check the UUIDs to make sure there were no mistakes
    9. Keep the old SSD unmodified in case you need to revert back to it.


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