Results 1 to 5 of 5

Thread: Upgrade Problem Using LVM Partitions

  1. #1

    Default Upgrade Problem Using LVM Partitions

    I was trying to do an upgrade in place from OpenSuSE 12.3 to 13.1 by booting from the 13.1 DVD ISO. All of the partitions except the /boot partition are LVM. I chose Installation => Upgrade but as soon as it comes to the filesystem part, it pops up this warning after which I abort:

    Some partitions in the system on /dev/vg0/Root are mounted by kernel device name. This is not reliable for an update since kernel device names are unfortunately not persistent. It is strongly recommended tp start the old system and change the mount by method to any other method for all partitions.

    What is a kernel device name and what are the alternative methods?

    Here is my /etc/fstab:

    /dev/mapper/vg0-Swap swap swap defaults 0 0
    /dev/mapper/vg0-Root / ext4 acl,user_xattr 1 1
    /dev/sda1 /boot ext4 acl,user_xattr 1 2
    /dev/mapper/vg0-Tmp /tmp ext4 acl,user_xattr 1 2
    /dev/mapper/vg0-Var /var ext4 acl,user_xattr 1 2
    proc /proc proc defaults 0 0
    sysfs /sys sysfs noauto 0 0
    debugfs /sys/kernel/debug debugfs noauto 0 0
    devpts /dev/pts devpts mode=0620,gid=5 0 0
    /dev/mapper/vg1-Home /home ext4 acl,user_xattr 1 2

    and my mounted filesystems:


    Filesystem Size Used Avail Use% Mounted on
    devtmpfs 2.0G 32K 2.0G 1% /dev
    tmpfs 2.0G 0 2.0G 0% /dev/shm
    tmpfs 2.0G 3.6M 2.0G 1% /run
    /dev/mapper/vg0-Root 15G 4.5G 9.6G 32% /
    tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
    /dev/mapper/vg1-Home 252G 43G 197G 18% /home
    /dev/mapper/vg0-Var 15G 1.7G 13G 12% /var
    tmpfs 2.0G 3.6M 2.0G 1% /var/lock
    tmpfs 2.0G 3.6M 2.0G 1% /var/run
    /dev/mapper/vg0-Tmp 5.7G 140M 5.3G 3% /tmp
    /dev/sda1 250M 109M 129M 46% /boot


    Thank you,
    Lucky Leavell



  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,608
    Blog Entries
    3

    Default Re: Upgrade Problem Using LVM Partitions

    From that list, "/dev/sda" is the only partition that appears to be a problem. Since 13.2 likes to use UUID, you can switch to using that.

    Use the command: blkid
    as root, to find the UUID of your "/boot" partition. Once you have found that, change the entry in "/etc/fstab" to read

    Code:
    # /dev/sda1 /boot ext4 acl,user_xattr 1 2
    UUID=1234-5678 /boot ext4 acl,user_xattr 1 2
    

    except change that "1234-5678" to the actual UUID. Notice that I suggest leaving the old line commented out. That way you can easily restore it from booting live media, in case something goes wrong.

    You say that you use an LVM. If it happens to be an encrypted LVM, then you might also have device names in "/etc/crypttab".

    After making changes, reboot to make sure everything is still fine. Then try your upgrade again.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  3. #3

    Thumbs up Re: Upgrade Problem Using LVM Partitions

    That was it!

    I had actually already changed the /boot partition to mount by label before reading your reply but it seems to do the same thing.

    What threw me (and hence using LVM in the title) was the warning's reference to /dev/vg0/Root which was misleading since /boot is a separate, non-LVM partition.

    I can afford to be a little adventurous since this is a VM which I took a snapshot of before starting the upgrade process.

    Thank you,
    Lucky Leavell

  4. #4

    Default Re: Upgrade Problem Using LVM Partitions

    If you've changed it I'd go ahead with the installer. I saw this before when all devices had specified UUID assigned.

  5. #5

    Default Re: Upgrade Problem Using LVM Partitions

    Quote Originally Posted by malkor13 View Post
    If you've changed it I'd go ahead with the installer. I saw this before when all devices had specified UUID assigned.
    I did and it completed with no further issues.

    However, the upgrade completed with no networking. It had failed to rename eth0 to emp32 (where do they get these names!).

    But, much worst, it completely trashed the mail server setup. After several frustrating hours trying to unravel that mess, I decided to stop postfix until I had more time today to work on it. On further consideration, I reverted to the snapshot of the old 12.3 system and was back receiving mail in five minutes.

    The 12.3 systems had been upgraded in place from 11.4 with only minor problems. I was expecting a similar ease of upgrade from 12.3 to 13.1. I guess I'll have to to a fresh install of 13.1 (probably on a new VM) and then migrate from 12.3 to the new mail server once I know it is working.

    Thank you,
    Lucky Leavell

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •