Install changed FS type labels

Last night I tried to install OpenSuse in my drive. I selected expert for setting up the filesystem because I wanted it to use only what was already present, without formatting.

I have only 1 drive, which was formatted with:
sda1: Grub boot
sda2: BTRFS with @/, @/home/. @/opt, and a snapshots directory on the volume.

Kubuntu was previously installed, but I don’t like it as much as OpenSUSE, so I tried to install OpenSUSE over the existing system. I expected it to write a new @/ to the volume during the install. That’s when things began to go terribly wrong. Instead of being able to recognize what was already existing on the hard drive, the installer tried to scramble things around in an unnecessary way:

[unable to upload photo]

As you can not see from the screenshot which I can not upload (because I don’t have a url to place any photos into,) the installer tried to relabel sda2 as an XFS filesystem and marked it to be mounted on /home instead of a btrfs on /.

It also divided up the sda1 into:
/dev/sda1 Bios grub
/dev/sda2 swap
/dev/sda3 btrfs /

This was so wrong. I thought I could just edit it to the correct situation and mark it as “do not format”, but that didn’t work. Instead the install failed with:


 Failure occurred during the following Action:
Mounting /dev/sda3 to /

VOLUME_MOUNT_FAILED

System error code was: -3003

/bin/mount -t btrfs '/dev/sda3' '/mnt':
mount: wrong fs type, bad option, bad superblock on /dev/sda3,
   missing codepage or helper program, or other error

   In some cases useful info is found in syslog - try

...

Continue despite the error?

Now I can’t access that partition anymore. kdepartitiontool says the filesystem is “unknown”. I know that I can’t use the partition tool to fix that partition without formatting it, so that’s not an option.
**
So - how can I fix this to make the labels for the filesystem on sda3 actually read as btrfs again so I can recover that partition and boot this drive again? **

There must be some way to restore the btrfs label without hosing the entire partition.

Update:

I have deleted the bogus swap partition (former sda2) which made the btrfs use the designation sda2 once again.
I’m not worried about sda1 (the grub boot) since I can delete that, recreate it, with the original dimensions, and it will be reinstalled when I use the Kubuntu live disk to reinstall the system. After that I’ll worry about how to safely convert it to OpenSUSE.

The pending problem is how to restore the partition table on the btrfs partition, which is now sda2.

root@kubuntu:~# fdisk -l
Disk /dev/loop0: 1.6 GiB, 1678491648 bytes, 3278304 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sda: 2.7 TiB, 3000592982016 bytes, 5860533168 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: F9C78116-9D2E-4304-A329-E3A7704EF117

Device         Start        End    Sectors  Size Type
/dev/sda1         34       2047       2014 1007K BIOS boot
**/dev/sda2  172023808 5860532223 5688508416  2.7T Microsoft basic data**

Partition 1 does not start on physical sector boundary.




Disk /dev/sdc: 29.6 GiB, 31809331712 bytes, 62127601 sectors
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: dos
Disk identifier: 0x06008704

Device     Boot   Start     End Sectors  Size Id Type
/dev/sdc1  *          0 3384575 3384576  1.6G  0 Empty
/dev/sdc2       3362880 3367487    4608  2.3M ef EFI (FAT-12/16/32)
root@kubuntu:~# 

sdc is my live boot USB drive.

Try the following:

erlangen:~ # gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 7814037168 sectors, 3.6 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 27C8C52A-8091-403C-ADF1-E9C791667D40
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3693 sectors (1.8 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048           16383   7.0 MiB     EF02  primary
   2           16384        67119103   32.0 GiB    0700  primary
   3        67119104       134223871   32.0 GiB    0700  primary
   4       134223872      7814035455   3.6 TiB     0700  primary
erlangen:~ #
erlangen:~ # parted -l
Model: ATA WDC WD40EZRX-22S (scsi)
Disk /dev/sda: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: pmbr_boot

Number  Start   End     Size    File system     Name     Flags
 1      1049kB  8389kB  7340kB                  primary  bios_grub
 2      8389kB  34.4GB  34.4GB  linux-swap(v1)  primary  msftdata
 3      34.4GB  68.7GB  34.4GB  ext4            primary  legacy_boot, msftdata
 4      68.7GB  4001GB  3932GB  ext4            primary  msftdata


Model: NVMe Device (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  34.4GB  34.4GB  primary  linux-swap(v1)  type=82
 2      34.4GB  68.7GB  34.4GB  primary  ext4            boot, type=83
 3      68.7GB  512GB   443GB   primary  ext4            type=83


erlangen:~ #

I got this response:

root@kubuntu:~# gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): F9C78116-9D2E-4304-A329-E3A7704EF117
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 8-sector boundaries
Total free space is 172022671 sectors (82.0 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34            2047   1007.0 KiB  EF02  BIOS boot partition
   2       172023808      5860532223   2.6 TiB     0700  primary


root@kubuntu:~# parted -l
Model: ATA ST3000DM001-1ER1 (scsi)
Disk /dev/sda: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                 Flags
 1      17.4kB  1049kB  1031kB               BIOS boot partition  bios_grub
 2      88.1GB  3001GB  2913GB               primary              msftdata


Warning: The driver descriptor says the physical block size is 2048 bytes, but
Linux says it is 512 bytes.
Ignore/Cancel? i                                                          
Model: General USB Flash Disk (scsi)
Disk /dev/sdc: 127GB
Sector size (logical/physical): 2048B/512B
Partition Table: mac
Disk Flags: 

Number  Start   End     Size    File system  Name   Flags
 1      2048B   6143B   4096B                Apple
 2      1722MB  1724MB  2359kB               EFI


root@kubuntu:~#

If you are going to reinstall, how does it matter what is on disk now?

how to safely convert it to OpenSUSE.

Then explain what you are trying to do. Sharing existing btrfs is unlikely supported by installer; nor do I remember any statement anywhere to the contrary. It may be possible to pull off manually, as long as different operating systems use different subtrees, by pre-creating necessary volumes and defining mount points manually during installation. But I am not sure how useful it is in practice.

Try install and execute gparted > device > data rescue:


erlangen:~ # zypper in gparted
Loading repository data...
Reading installed packages...
'gparted' is already installed.
No update candidate for 'gparted-0.29.0-1.1.x86_64'. The highest available version is already installed.
Resolving package dependencies...

Nothing to do.
erlangen:~ # gparted /dev/sda
Created symlink /run/systemd/system/-.mount → /dev/null.
Created symlink /run/systemd/system/boot.mount → /dev/null.
Created symlink /run/systemd/system/home.mount → /dev/null.
Created symlink /run/systemd/system/home\x2dHDD.mount → /dev/null.
Created symlink /run/systemd/system/Leap\x2d42.3.mount → /dev/null.
Created symlink /run/systemd/system/mnt.mount → /dev/null.
Created symlink /run/systemd/system/mnt1.mount → /dev/null.
Created symlink /run/systemd/system/run-media-karl-2ff73487\x2de05c\x2d44b1\x2d9e89\x2d6c82dff425e7.mount → /dev/null.
Created symlink /run/systemd/system/run-media-karl-68c08ef7\x2d9d78\x2d4e2a\x2dabf5\x2d77b0f6cf7999.mount → /dev/null.
Created symlink /run/systemd/system/run-user-1000.mount → /dev/null.
Created symlink /run/systemd/system/run-user-1001.mount → /dev/null.
Created symlink /run/systemd/system/run-user-1002.mount → /dev/null.
Created symlink /run/systemd/system/sysroot.mount → /dev/null.
Created symlink /run/systemd/system/tmp.mount → /dev/null.
Created symlink /run/systemd/system/var-lib-machines.mount → /dev/null.
Created symlink /run/systemd/system/var-lib.mount → /dev/null.
Created symlink /run/systemd/system/var-lock.mount → /dev/null.
Created symlink /run/systemd/system/var-run.mount → /dev/null.
Created symlink /run/systemd/system/var.mount → /dev/null.
======================
libparted : 3.2
======================

** (gpartedbin:8417): WARNING **: Invalid borders specified for theme pixmap:
        /usr/share/themes/Breeze/gtk-2.0/../assets/line-h.png,
borders don't fit within the image
Removed /run/systemd/system/-.mount.
Removed /run/systemd/system/boot.mount.
Removed /run/systemd/system/home.mount.
Removed /run/systemd/system/home\x2dHDD.mount.
Removed /run/systemd/system/Leap\x2d42.3.mount.
Removed /run/systemd/system/mnt.mount.
Removed /run/systemd/system/mnt1.mount.
Removed /run/systemd/system/run-media-karl-2ff73487\x2de05c\x2d44b1\x2d9e89\x2d6c82dff425e7.mount.
Removed /run/systemd/system/run-media-karl-68c08ef7\x2d9d78\x2d4e2a\x2dabf5\x2d77b0f6cf7999.mount.
Removed /run/systemd/system/run-user-1000.mount.
Removed /run/systemd/system/run-user-1001.mount.
Removed /run/systemd/system/run-user-1002.mount.
Removed /run/systemd/system/sysroot.mount.
Removed /run/systemd/system/tmp.mount.
Removed /run/systemd/system/var-lib-machines.mount.
Removed /run/systemd/system/var-lib.mount.
Removed /run/systemd/system/var-lock.mount.
Removed /run/systemd/system/var-run.mount.
Removed /run/systemd/system/var.mount.
erlangen:~ # 

Are you in the habit of deleting all your data when installing anything new? From your question it certainly sounds like it. But that’s not the topic of this thread, is it? (Rhetorical question.)

Then explain what you are trying to do.

At the risk of being seen repeating myself, I had previously stated: “The pending problem is how to restore the partition table on the btrfs partition, which is now sda2.” I think that was pretty clear. I even made it bold so that it would stand out, thus making questions like this unnecessary. Apparently that didn’t work.

Sharing existing btrfs is unlikely supported by installer; nor do I remember any statement anywhere to the contrary. It may be possible to pull off manually, as long as different operating systems use different subtrees, by pre-creating necessary volumes and defining mount points manually during installation. But I am not sure how useful it is in practice.

You aren’t following what I’m saying. I don’t want to “share” the volume between two operating systems, I want to replace Kubuntu with OpenSUSE. I never said anything about dual booting, which is possible…
( See: More BTRFS fun: Multibooting to subvolumes on the same partition. - Kubuntu Forums. ) Installing a new system into the volume without formating it will typically overwrite the @/ subvolume. Snapshots aren’t touched, so they can easily be used to restore @/home and other subvolumes, if needed.

But again, that’s not the topic of this thread. The topic is **how to restore the partition table on the btrfs partition **which got hosed by the OpenSUSE install program. I need the system to once again know that my sda2 is a btrfs filesystem. So, with all due respect, please refrain from directing everyone’s attention away from the topic of this thread.

This is why it is recommended to have a separate home partition. Don’t get fooled by BTRFS subtrees they are NOT separate file systems they are part of the same btree that makes up the file system. If you format the root all parts are formatted. So restore the home from your backup.

Thank you for your opinion.

Now, do you have any relevant answers as to how to restore the partition table?

You formatted it away restore from your backups

Clearly you don’t, so I can’t imagine why you keep posting non sequiturs here.

Two things you failed to read and comprehend:

  1. I selected expert for setting up the filesystem because I wanted it to use only what was already present, without formatting.

So the drive was not “formatted”, the install program just trashed the partition table, that’s all. All the data is still there. I just can’t mount the drive. Your saying that it was formatted is an incorrect, and absolutely unhelpful opinion, not a fact.

  1. I have only 1 drive…" and as to the only backup possible without a second drive: "…a snapshots directory on the volume.

If you’re going to turn out to be one of those people who simply cannot provide relevant help, and instead harp endlessly on the merits of ‘backups’, then please put your money where your mouth is: donate so I can roll my wheelchair down to the store and buy a second 3T drive. Otherwise, please comprehend that I’m asking for specific help with a specific problem, for a specific reason, I’m not asking for opinions or lectures.

Try to be more like karlmistelberger who is really giving relevant help without the distracting opinions.

If you did not format then you have a mix of OS’s

No backup is not a good idea

Boot from a live Linux and show us fdisk -l

I doubt the installer trashed the disk partition table though it may have trashed the BTRFS subtrees which is not a partition table

Can you mount the BTRFS partition from a live?

Incorrect. Again you are assuming something which isn’t the case. In my first post I indicated that I set it to not do a format, but the install did not occur at all, as I said:
“Instead the install failed with:”

Failure occurred during the following Action:
Mounting /dev/sda3 to /

VOLUME_MOUNT_FAILED

System error code was: -3003

/bin/mount -t btrfs '/dev/sda3' '/mnt':
mount: wrong fs type, bad option, bad superblock on /dev/sda3,
   missing codepage or helper program, or other error

So the mounting failed, thus nothing got written, so how can there be a mix of OS’s when nothing got installed?

No backup is not a good idea

It has nothing to do with “ideas”. I am retired, disabled, have no income, thus cannot just go out and buy what I should have but cannot afford. I asked you to stop lecturing me about backups. If you are that concerned about backups, then do as I asked - donate so I can buy a decent system. If you don’t want to do that, then at least stop the lecturing about what is or isn’t a good idea.

Boot from a live Linux and show us fdisk -l

Been there, done that. Scroll back and look, you’ll find it.

I doubt the installer trashed the disk partition table though it may have trashed the BTRFS subtrees which is not a partition table

Really? I’m pretty sure that I can delete a subtree without rendering the entire partition unmountable due to “wrong fs type, bad option, bad superblock”. I also don’t see how subtrees have anything to do with “wrong fs type, bad option, bad superblock”. I also don’t see how the installer program’s partition tool may have trashed the BTRFS subtrees. Is it also a subtree tool?

If you have a way to test your theory, then please produce it. otherwise it’s just nutzlose Spekulation which doesn’t help.

Can you mount the BTRFS partition from a live?

You keep asking questions the answers of which were already given. Aren’t you reading the previous posts? If I could mount the btrfs partition then I wouldn’t need any help in making it mountable again. So obviously, no, it cannot be mounted. I’m in a live filesystem now, and as I indicated right in the beginning it cannot be mounted.

Herr karlmistelberger asked me to run gparted > device > data rescue which I have been running a long time now. I hope that it will provide a solution.

Hi
Everybody take a chill pill :wink:

@rwbehne1 since you don’t have a backup of any kind, then perhaps try TestDisk (http://www.cgsecurity.org/wiki/TestDisk) to see if this can recover the partition table…

FWIW, I use sgdisk to make gpt partition backups (as well as uefi partition, and nvram data), something to look at in the future as well as perhaps some additional USB storage for a data backup…

kubuntu@kubuntu:/$ **sudo mount /dev/sda2 /mnt**
mount: wrong fs type, bad option, bad superblock on /dev/sda2,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
kubuntu@kubuntu:/$ **dmesg | tail**
[18727.584698] raid6: avx2x4   gen() 28159 MB/s
[18727.632692] raid6: avx2x4   xor() 20658 MB/s
[18727.632693] raid6: using algorithm avx2x4 gen() 28159 MB/s
[18727.632694] raid6: .... xor() 20658 MB/s, rmw enabled                                                                                      
[18727.632694] raid6: using avx2x2 recovery algorithm                                                                                         
[18727.634047] xor: automatically using best checksumming function   avx                                                                      
[18727.662082] Btrfs loaded, crc32c=crc32c-intel                                                                                              
[18727.688035] JFS: nTxBlock = 8192, nTxLock = 65536                                                                                          
[18727.719521] SGI XFS with ACLs, security attributes, realtime, no debug enabled                                                             
[22020.175751] perf: interrupt took too long (2501 > 2500), lowering kernel.perf_event_max_sample_rate to 79750                               
kubuntu@kubuntu:/$

Just a “friendly” tip:

With snotty responses like this, I have decided not to try to help you, and I imagine a few others will decide the same as me.

I likely will avoid any threads you start.