I am running Opensuse 15.0 dual booted with Win10 and I would like to upgrade to Opensuse 15.1. I have upgraded previously from 13.2 to 42.0 with references from Opensuse wiki, but on a different machine.
I would also like to move from LVM+Ext4 to BtrFS, along with the upgrade. I have looked online, but did not find much about a migration HowTO to BtrFS.
I also have additional repositories enabled (Nvidia/chrome/Hardware and a few more) which I would like to retain/use after the upgrade.
[ul]
[li]What should be the best option in my scenario ? [upgrade from DVD or upgrade via zypper][/li][li]Do I need to take any precaution so that my Win10 partition does not get corrupted ? Os-Prober and grub2-mkconfig has been consistent for me during “zypper up” so far. [I use win10 mostly for games anyway, but I would like not to do a complete rebuild][/li][li]Any documentation for migrating from LVM-EXT4 to Btrfs ? [My Data is backed up to external HDD][/li][li]I can disable the additional repositories before the upgrade. Is it recommended to switch to nouveau (which is currently blacklisted in modprobe) before the upgrade , or can nvidia module be retained with the upgrade ?[/li][li]I would like to retain the current kernel in case things go south during the upgrade. can a dd backup of my current root partition help in recovering my system in case things go wrong ?[/li][/ul]
This is my regular workhorse machine and I cannot test the migration scenario on a VM mostly due to lack of info. Could you please point me to right direction ?
When you change the underlying construction of mass-storage devices, I doubt you can you any “upgrade” the way that it is done either by the onine method (changing repo addresses and zypper dup) or tyhe Upgrade item in the DVD’s main menu. Both will replace software packages with new ones only and not give you any opportunity to change from LVM to partitions only, or from change in partitioning, or from change of file system type. And you want all of those together ;).
A new installation is IMHO the only solution. I do not know if you have a seperate /home file system, nor where it is placed on, but when it is a seperate file system on a partition, you could keep that partition. But because your queeste is a real reorganisation, I acn imgine that it will be in the place of reorganised space. Thus creating it new might be needed. In any case you can save the contents of /home and restore it (and of course that is an extra save, independent from your normal backup procedure).
BTW, I have no comment in respect of that Windows. Never us it.
Yes, I do have separate /data and /home partitions , and both are backed up. So I am not against the idea to remove the LVs (I cant remember at the moment if root, home and data are on same VG, it’s late and I am on a different machine) and rearrange the volumes. My primary concern is for the root LV and the custom configuration tweaks it has accumulated for about 2 years.
BTW, I have no comment in respect of that Windows. Never us it.
I hear you. Linux is my primary OS since 2011 and I use windows only for games, word and excel.
My personal recommendation is that after a couple upgrades but also depending on how it’s used, a system starts to accumulate significant amounts of junk. Sometime either this time or in the future you should consider a new install which would remove that junk which otherwise is hard to identify and remove.
If you decide to upgrade, it should be safe because the upgrade process is careful to touch only the Linux partitions, but don’t assume anything. Properly backup and/or clone everything you deem valuable. The old thing about “A pound of prevention…” is applicable in spades here.
Always disable all but OSS and OSS-Update repositories before doing an upgrade. You can re-enable and do a separate upgrade from those repos later after you’re certain your basic system was upgraded successfully. There are exceptions, like Pacman… People have been able to upgrade leaving Pacman enabled and sometimes that’s almost necessary.
As I described above, backup or clone your system before an upgrade which should preserve your kernel along with everything else.
You can certainly test an upgrade using virtualization (It won’t be perfect because virtualized hardware is almost always easily supported whereas real, physical hardware can have problems). In fact, virtualization can also serve not only as a testbed but a reliable and easy way to clone a machine (at least virtualized). Some people will even prefer to continue to run these virtual machines for their regular work because of the various conveniences and easy backup/cloning. For whatever virtualization you choose to use, look for P2V (physical to virtual) conversion utilities or solutions. Post in the Virtualization Forum if you have questions or issues.
Yes, very valid point indeed about the ‘junk’ an OS accumulates over the time, however my installation date is still below two years and has tweaks for realtek, nvidia/nouveau, netwrokmanager, openvpn etc. I would prefer to preserve them.
# tune2fs -l /dev/sda7 | grep 'Filesystem created:'
Filesystem created: Sat Oct 27 03:44:20 2018
Just realized that I have been using partitions all along, so it should be easier to “convert” them to Btrfs. The links are goldmine (my office laptop must have been blocking the btrfs wiki links >:()…
I have moved out all but essentials from /home and /data already, so it should be easy to work with them.
Anyways, here are my mounts and partition table -
# df -hPT
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 12G 0 12G 0% /dev
tmpfs tmpfs 12G 66M 12G 1% /dev/shm
tmpfs tmpfs 12G 9.7M 12G 1% /run
tmpfs tmpfs 12G 0 12G 0% /sys/fs/cgroup
/dev/sda7 ext4 41G 14G 25G 36% /
/dev/sda3 vfat 2.0G 5.0M 2.0G 1% /boot/efi
/dev/sdb3 ext4 144G 26G 111G 19% /VMs
/dev/sdb4 xfs 196G 41G 155G 21% /home
tmpfs tmpfs 2.4G 20K 2.4G 1% /run/user/1000
# fdisk -l
Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 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: F4AF905B-0F37-49BA-AD75-2C7C679838F7
Device Start End Sectors Size Type
/dev/sda1 2048 130258762 130256715 62.1G Microsoft basic data
/dev/sda2 130258944 138647551 8388608 4G Linux swap
/dev/sda3 138647552 142841855 4194304 2G EFI System
/dev/sda4 142841856 143863807 1021952 499M Windows recovery environment
/dev/sda5 143863808 144068607 204800 100M EFI System
/dev/sda6 144068608 144101375 32768 16M Microsoft reserved
/dev/sda7 144101376 230230015 86128640 41.1G Linux LVM
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 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: 9E9B9B32-DF6C-4227-996B-E4640B21B16F
Device Start End Sectors Size Type
/dev/sdb1 2048 929519615 929517568 443.2G Microsoft basic data
/dev/sdb2 929519616 1031919615 102400000 48.8G Linux filesystem
/dev/sdb3 1031919616 1339119615 307200000 146.5G Linux filesystem
/dev/sdb4 1339119616 1748719615 409600000 195.3G Linux LVM
Thanks everyone for your inputs. Happy to report that I have upgraded successfully to 15.1, albeit the root volume has not been converted to btrfs yet. I can ‘almost’ count on windows updates to break my system at least once a year and so it has been consistently since 2016 on this machine lol! I’ll convert / to btrfs at that time]
What I did (summary) -
a. backed up /home & /VMs as tarballs on an external drive
b. created 2 USB keys (Gparted and Opensuse DVD) in case I had to rebuild.
c. backed up old repositories as tarball on an external drive & redirected all repositories to 15.1 repo as per wiki’
d. Disabled chrome, vivaldi, hardware & enzokiel’s repo. (Yes, Nvidia was left enabled, though I pointed it to 15.1 repo)
e. hit ‘zypper dup’ (zypper up was done before this!) … it took about 3 hours and complained about few packages to change from pacman to mainstream repo. I went along with the suggestions.
f. Upgrade completed and rebooted. I was in 15.1 with nvidia driver and all tweaks (NM,openvpn,realtek n such) were retained ! Woo Hoo! lol!
g. went to runlevel 3,logged in a root, unmounted /VMs and used the convert utility to change it to btrfs… Updated fstab and mounted again. Data was intact.
h. unmounted /home, reformatted /home as btrfs, set a label , updated fstab and remounted it.
i. rsynced from the backup of /home taken earlier.
j. set default target to graphical.target, rebooted and logged in as regular user. All looked good, and my VMs played fine in KVM…
k. rebooted and checked windows, it was fine as well.
Note:
I understand that this is not a safe method to upgrade, and I should have disabled a lot many repositories,specially nvidia and non-oss repos, but I was prepared for a rebuild. I do not recommend this to anybody.
I prefer using labels in fstab or plain old device path, but the upgrade forced UUID convention on me… This is a minor discomfort and takes about 5 minutes to fix.
Opensuse is just the right amount of “boring” for me (robust, seldom gives errors and rock solid), as long as I give the new releases some time to mature and iron out bugs.
I prefer using labels in fstab or plain old device path, but the upgrade forced UUID convention on me… This is a minor discomfort and takes about 5 minutes to fix.
I use both, labels for improved readability, UUIDs for robust configuration:
erlangen:~ # lsb /dev/sdb
PATH LABEL PARTLABEL PARTUUID UUID FSTYPE MOUNTPOINT
/dev/sdb
/dev/sdb1 EFI System Partition 2fe6b58a-379a-4f6e-899b-8be22ef6e885 4A24-B10D vfat /boot/efi
/dev/sdb2 ArchLinux Linux System f1379b6c-304b-4606-98b8-5cec4f3dd678 690b51d7-7034-4585-b362-615f8056be45 ext4
/dev/sdb3 SLED Linux System 1e7b0509-97cf-4a62-b7fc-db46be72335b 492c5d5e-5d9b-4a99-9d34-e1f9cee09fe9 ext4
/dev/sdb4 Home-SSD Linux Filesystem ced907e6-2af7-42d8-8643-31a61479352b f4c5463f-f43d-420a-a0ea-4456cfbc54fa ext4
/dev/sdb5 Tumbleweed Linux System f4880da8-3641-499b-81b6-4432b106f8ff 204f7d0f-979a-41e1-a483-a597d0357e0b btrfs /mnt
/dev/sdb6 Ubuntu Linux System 6a043f8a-cbec-4432-85c6-85202ba19990 9a3eec78-dd20-44c0-a38a-f705b3bbbc66 ext4
/dev/sdb7 Manjaro-SSD Linux System fa8d0a18-8e3d-4168-8669-16319e8aa902 bf6ba7c9-9068-4a9b-b210-84b6d105df5c ext4
erlangen:~ #
I am not sure what you mean with that, but you can only use one of them in any entry. Different entries may use different. All logical if you know what /etc/fstab is.
I am not sure what you mean with that, but you can only use one of them in any entry. Different entries may use different. All logical if you know what /etc/fstab is.
My brain and solaris/linux knowledge of 10 years say the same. which is why I mentioned “barring comments”.
Some of us are known to use UUIDs in /etc/fstab but put the same details with a device path above or below it and comment out with ‘#’. Makes troubleshooting easier without having to call blkid (or similar) to check UUID everytime.
My statement was not meant in a disrespectful manner in any way. I was merely curious if a way exists to use more than one conventions in fstab.
Could you or another moderator please mark the thread as resolved, before such a trivial matter gets dragged on ?
It is you that decides if you are satisfied and if your case is solved. You post that here (as you have done) and that is it.
People then may still post to the thread and if you are not interested, just unsubscribe to it so you do not get the e-mails about the new posts anymore.
Here is readable information from lsb (aliased to “lsblk -o PATH,LABEL,PARTLABEL,PARTUUID,UUID,FSTYPE,MOUNTPOINT”):
erlangen:~ # lsb
PATH LABEL PARTLABEL PARTUUID UUID FSTYPE MOUNTPOINT
/dev/sda
/dev/sda1 Manjaro Linux System 2c0e640c-3df5-470a-a17c-89b17eba59d8 fad3604b-5a61-4653-8c14-518d850400ba ext4
/dev/sda2 Leap-15.1 Linux System 410b7947-08ad-4fb7-93ea-854f63a3bf78 57bdbf64-b309-477c-b94c-8987e0c8032a ext4
/dev/sda3 Linux System 2d036a71-5df4-f145-8b69-37ef88857893 42f23f3c-9ff6-46f6-a9d9-6894062c37d7 ext4
/dev/sda4 Home-HDD Linux Filesystem 1f1100a4-325e-4d9e-84a3-bc119b98a449 f5177cae-4082-44ed-9471-b99030f06866 ext4 /home-HDD
/dev/sdb
/dev/sdb1 EFI System Partition 2fe6b58a-379a-4f6e-899b-8be22ef6e885 4A24-B10D vfat /boot/efi
/dev/sdb2 ArchLinux Linux System f1379b6c-304b-4606-98b8-5cec4f3dd678 690b51d7-7034-4585-b362-615f8056be45 ext4
/dev/sdb3 SLED Linux System 1e7b0509-97cf-4a62-b7fc-db46be72335b 492c5d5e-5d9b-4a99-9d34-e1f9cee09fe9 ext4
/dev/sdb4 Home-SSD Linux Filesystem ced907e6-2af7-42d8-8643-31a61479352b f4c5463f-f43d-420a-a0ea-4456cfbc54fa ext4
/dev/sdb5 Tumbleweed Linux System f4880da8-3641-499b-81b6-4432b106f8ff 204f7d0f-979a-41e1-a483-a597d0357e0b btrfs /
/dev/sdb6 Ubuntu Linux System 6a043f8a-cbec-4432-85c6-85202ba19990 9a3eec78-dd20-44c0-a38a-f705b3bbbc66 ext4
/dev/sdb7 Manjaro-SSD Linux System fa8d0a18-8e3d-4168-8669-16319e8aa902 bf6ba7c9-9068-4a9b-b210-84b6d105df5c ext4
/dev/nvme0n1
/dev/nvme0n1p1 Fedora Linux System 4d91e611-d1f2-49b6-b92b-caf1925c6bf5 6fe43319-8566-4a09-9d2d-fcf8c104671f ext4
/dev/nvme0n1p2 Tumbleweed Linux System f756cc7f-1727-4f82-8c5e-5b4468a74e72 8b190950-c141-4351-9198-7a9592b4fb34 ext4
/dev/nvme0n1p3 Home Linux Filesystem 63413441-e35b-41a7-9dab-536a91b8f418 704621ef-9b45-4e96-ba7f-1becd3924f08 ext4 /home
/dev/nvme0n1p4 EFI System Partition 0497bfdf-73d7-47a8-9d8e-6b911574f774 6DEC-64F9 vfat
erlangen:~ #
Actually I could do without LABEL/ PARTLABEL, but readability is a point, when it comes to dealing with multiple systems in an efficient manner.
Robustness of configuration is another important point: Missed to check mail for correct configuration. The owner was happy for 3 years. But on March 12, his inbox was empty and he called me for a fix. UUIDs seem cumbersome, but they are unambiguous and never change unless you create a new file system. You can copy and paste them so typing errors are not an issue.
If you don’t absolutely need to execute MS Windows direct on the hardware – no applications which need to have direct access to the graphics system or, the hardware only supporting BIOS/UEFI updates via Windows – have you, considered running only Linux on the hardware and, as a consequence, banning your MS Windows licences to VMs?
For this game, I prefer to use Oracle’s VirtualBox for the VMs because of the Windows 10 support …
@karlmistelberger, neat trick there while handling 12 or so different OS. Your fstab also shows nice way of handling subvolumes spread across partitions and is valuable since I am totally new to btrfs. Thanks for this.
@dcurtisfra, I play games on steam and most of these games have not been ported yet. I have tried games in virtual machines (KVM and VirtualBox) before, but the ping latency is too much and graphic rendering is not handled well, since it is emulated anyway…Building a windows VM on KVM was painful enough to dread troubleshooting it at a possible later point. :|…
The breaking of my machine used to be very frequent (patch Tuesday) earlier (pre 2018) as I was using DOS partitioning with a triple boot set-up. Since moving to GPT, things have been a lot smoother and I moved my second linux OS (CentOS7) as a KVM guest under Opensuse. I don’t care for windows that much to dig in, learn and troubleshoot any further than I have to.
Now if these games were ported to steamOS, I would move windows to a VM in a heartbeat and use it only for the office tools.
which is why I mentioned “barring comments”.