Announcement

Collapse
No announcement yet.

Switching from Opensuse to Kbuntu maining the old data

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    [Installation] Switching from Opensuse to Kbuntu maining the old data

    I do a lot of sdr these days and I find compiling cutting edge github code becoming harder and harder these days on Opensuse Leap. That is the github code is built on Debian systems. I want to change my system from Opensuse to Kbuntu.

    This is on a Lenovo notebook that dual boots windows 10 and linux. I have a 1Tbyte SSD and will buy a new 2TByte SSD to remove any chance of data loss. That is I will keep the old SSD around until everything is working properly.

    The idea is to clone the 1TByte drive to the 2Tbyte drive. I have the hardware to do this and know how to use Clonezilla. (I clone my SSD for backup). i will be posting some disk data but it is probably best to explain what I want to do verbally first

    I set up Opensuse with / and /home on separate partitions. The plan is to clone the 1TByte to the new 2Tbyte drive. I will place / for Kubuntu where it is presently located for Opensuse. Either install it there directly or if need be I can reformat the / partition with gparted and provide a blank home for Kbuntu /.

    Ideally kbuntu will see the /home partition and not touch it other than to enter it into fstab. I don't know if the installer is that smart.

    I have a small partition that I use for swap. It will be in the way if I want to resize /home to use the rest of the 2Tbyte drive. I could move it but I am thinking of just not using a swap partition since the notebook has 24Gbytes of RAM. I never found hibernate to be useful, mostly because my USB peripherals are not simple drives but radios and such.

    I have never made a partition with data larger with gparted but this seems doable these days based on what I have read on the internet.

    This all sounds doable. The only thing I am unsure about is grub.

    Thanks in advance for any suggestions.

    Here is the output from fdisk and lsblk respectively.

    Code:
    Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
    Disk model: Samsung SSD 970 PRO 1TB
    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: AB0A3DE5-F683-4869-887D-2323516CA579
    
    Device Start End Sectors Size Type
    /dev/nvme0n1p1 2048 534527 532480 260M EFI System
    /dev/nvme0n1p2 534528 567295 32768 16M Microsoft reserved
    /dev/nvme0n1p3 567296 123153844 122586549 58.5G Microsoft basic data
    /dev/nvme0n1p4 123154432 125138943 1984512 969M Windows recovery environment
    /dev/nvme0n1p5 125140992 125157375 16384 8M BIOS boot
    /dev/nvme0n1p6 125157376 313901055 188743680 90G Linux filesystem
    /dev/nvme0n1p7 313901056 1924513791 1610612736 768G Linux filesystem
    /dev/nvme0n1p8 1956046848 2000409230 44362383 21.2G Linux swap
    Code:
    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
    nvme0n1 259:0 0 953.9G 0 disk
    ├─nvme0n1p1 259:1 0 260M 0 part /boot/efi
    ├─nvme0n1p2 259:2 0 16M 0 part
    ├─nvme0n1p3 259:3 0 58.5G 0 part
    ├─nvme0n1p4 259:4 0 969M 0 part
    ├─nvme0n1p5 259:5 0 8M 0 part
    ├─nvme0n1p6 259:6 0 90G 0 part /
    ├─nvme0n1p7 259:7 0 768G 0 part /home
    └─nvme0n1p8 259:8 0 21.2G 0 part [SWAP]​




    #2
    Installers aren't very "smart" in my experience and ours won't "find" your home partition. How would it "know" which partition is home? The installer will find swap partitions at installation because "swap" is a partition type. Home is just a regular Linux partition.

    However, it is simple enough to select "Manual Partitioning" when you get to that step and identify the partition as /home. Of course, also making sure the "Format" checkbox in NOT selected.

    Gparted usually does a fine job resizing a partition and as long as you have a full backup, I wouldn't sweat it.

    For the rest of it, I have questions/suggestions:

    It seems very odd that you have both an EFI and BIOS boot partition. I assume you're booting using UEFI and 8M isn't much space to lose, but it's odd. Must have been an openSUSE thing from the past. GRUB will locate the EFI partition and use it properly. I doubt the unneeded BIOS boot partition will have any negative effect. Pretty much since version 20.04 EFI is the default. GRUB will just add an entry to the EFI menu and you should be good to go.

    90G is HUGE for a normal installation partition size but with 2TB on the drive space is unlikely to become an issue.

    This might be obvious, but since your SWAP partition will end up in between your old /home and the free space on the disk, I would simply delete the swap partition then expand into the free space as far as you want, then recreate it. BTW, the default Ubuntu installation uses a swap FILE these days instead of a partition, so you could just not use a separate partition for swap at all. Normally it would reside on the / partition but since this is linux you can put it wherever you want. For example, a /home partition with 1.7TB would have plenty of room. The install will default to / for the swap file and frankly I'm not sure if the installer allows you to select a different location at install time. No matter, simple enough to un-mount it, delete it, recreate it, and edit fstab after your first boot. I know of no reason to use a swap partition over a swap file except if you boot multiple Linux installs and what to share swap space among them, like I do.

    Going to throw this out there because I can't help myself, but you might consider using BTRFS instead of the ancient EXT file system. BTRFS has many benefits including native snapshot and backup capabilities among many others.

    Good luck with the process, let us know how it goes, and welcome to Kubuntu Forums. I look forward to your future contributions.

    Please Read Me

    Comment


      #3
      Ditto on nuking the swap.

      Yes I will have this doubly backed up since I am going to save the old SSD plus an image on spinning rust. It will find a home in some project for the SSD. It is a high endurance drive. To be honest I didn't expect to upgrade this notebook but Opensuse is becoming difficult for what I want to run. The old package search is broken. They added OPI but even those downloads have issues.

      I have a large / because I build a lot of code from github. So /usr/local/src and /usr/local/bin do get filled. I also have a local cache of openstreetmap since I use this notebook in the field without internet access.

      I had a lot of issues with the snapshots when i did my initial opensuse installation. I ended up getting rid of BTRFS.

      Comment


        #4
        The only "issues" I've ever heard of with BTRFS snapshots were cause by the early releases of "snapper" utilities that didn't "take out the trash" by themselves, not BTRFS itself. I don't rely on outside utilities unless there's some benefit. I just wrote a cronjob script that rotates daily snapshots over a one week period and makes a weekly backup without my intervention. Saved my bacon on many MANY occasions for sure.

        IIRC, OpenSUSE defaulted to a massively complex set of BTRFS subvolumes for absolutely no reason that I could discern other than to make the installation obscure and make "normal" BTRFS backups almost impossible. It's almost like they had an engineering discussion about how to make using BTRFS as difficult as possible so no one would like it. *buntus by default use a single file system and two subvolumes - root and home. Easy to understand and simple to snapshot/backup.

        Of course, it's your system so you-do-you, lol. Good luck with the cloning. I have to use Windows for work and it's the bane of my existence. The first thing I'll be doing when I finally retire for good will be to burn Windows to the ground!

        Please Read Me

        Comment


          #5
          IMO cloning is a thing Windows needs, and can cause problems because UUIDs get cloned. I suggest installing Kubuntu to btrfs on the new drive, then think about copying stuff to it. Linux doesn't mind being copied about, so long as grub is sorted out and /etc/fstab is corrected. If you want to keep the openSUSE install updated, I suggest uninstalling grub from it, to stop the openSUSE grub fighting with the Kubuntu grub. I'm assuming the new grub will find the openSUSE install; if it doesn't, you can drop in a /boot/grub/custom.cfg that boots to openSUSE, just ask here if you don't know how to do that.

          If you're working with a lot of source, I recommend frequent automatic snapshots. There's no other good defence against several classes of screw-ups, such as misplaced deletions. I use snapper to do snapshots hourly, and have met online someone setting up 5 minute snapshots.
          Regards, John Little

          Comment


            #6
            Originally posted by jlittle View Post
            […]I'm assuming the new grub will find the openSUSE install; if it doesn't, you can drop in a /boot/grub/custom.cfg that boots to openSUSE, just ask here if you don't know how to do that.
            […]
            Unfortunately I am quite sure it will not find it, so be prepared to use a custom.cfg (which should not be too hard), or let openSUSE handle GRUB entirely (that works with every combination of other distributions I have tried so far).
            Last edited by Schwarzer Kater; Jan 17, 2023, 05:21 AM.
            Debian KDE & LXQt • Kubuntu & Lubuntu • openSUSE KDE • Windows • macOS X
            Desktop: Lenovo ThinkCentre M75s • Laptop: Apple MacBook Pro 13" • and others

            get rid of Snap scriptreinstall Snap for release-upgrade scriptinstall traditional Firefox script

            Comment

            Working...
            X