https://en.opensuse.org/SDB:BTRFS

English Install/Boot/Login
1

My situation seems to be out of sync with that page. Brother-in-law’s bad SSD originally used btrfs for 42.2, and eventually reached 15.1 in November. First I used ddrescue to clone from the bad SSD to another disk. Then I connected the other disk to a working 15.1 as sdb.

These are the last steps from there I’ve taken:

btrfs rescue zero-log /dev/sda1

Then try to mount the device normally. If it works, stop going.
What exactly is
mount normally
with btrfs?

# mount /dev/sdb2 /mnt

has apparently mounted / just fine, but /mnt/home is void, empty. It should contain what needs to be rescued. Is /home that lost, or is some further mounting step(s) required?

2

First, one does not say “/mnt/home is void” (at least you do not say that only). You always show what the system thinks of it, because we believe systems, not people :wink:

ls -l /mnt/home

I do not know if /home belonging to that root file system you just mounted on /mnt, is a separate file system or not. When it is, you must of course mount it (when you need so).

mount /dev/sd.... /mnt/home

Why should that happen out of the blue?

3

Hi
You have to mount each btrfs sub-volume… which is however it’s been configured (see /etc/fstab). All the details in man btrfs-subvolume

For example on my mounted system I see;


btrfs subvolume show /home
@/home
    Name:             home
    UUID:             xxxxxxxxxxxxxxxxxxx
    Parent UUID:         -
    Received UUID:         -
    Creation time:         2019-09-15 14:11:58 -0500
    Subvolume ID:         259
    Generation:         388576
    Gen at creation:     13
    Parent ID:         256
    Top level ID:         256
    Flags:             -
    Snapshot(s):

In your case you have it on /mnt at present so the following will show the info;


btrfs subvolume list /mnt
btrfs subvolume show /mnt/home

To mount the subvolume you need to specify the subvolume id etc as per you /etc/sftab


mount -t btrfs -o subvol=home /dev/sdb2 /mnt/home

More info here: Getting started - btrfs Wiki

4

Malcolm’s post is complete,
If the point was missed, one of the very, very big changes in 15.1 is that by default /home is no longer mounted as its own partition, is now a BTRFS sub-volume on the same partition as root.

TSU

5

Somehow the email notice anyone replied here never reached me. I was so mired in various failures I only just minutes ago thought to take a look here. :stuck_out_tongue:

# ls -l /mnt/home
total 0
# grep home /mnt/etc/fstab
UUID=5893c170-a545-4d9e-9e42-d6682b1fd9a5 /home btrfs subvol=@/home 0 0
# btrfs subvolume list /mnt | grep home
ID 262 gen 954211 top level 257 path @/home
# btrfs subvolume show /mnt/home
ERROR: Not a Btrfs subvolume: Invalid argument
# btrfs subvolume list /mnt | grep snapshots
ID 258 gen 954228 top level 257 path @/.snapshots
ID 259 gen 954240 top level 258 path @/.snapshots/1/snapshot
ID 885 gen 905333 top level 258 path @/.snapshots/74/snapshot
ID 985 gen 905333 top level 258 path @/.snapshots/77/snapshot
ID 989 gen 914097 top level 258 path @/.snapshots/78/snapshot
ID 1143 gen 914097 top level 258 path @/.snapshots/79/snapshot
ID 1146 gen 914097 top level 258 path @/.snapshots/82/snapshot
ID 1147 gen 914097 top level 258 path @/.snapshots/83/snapshot
ID 1148 gen 914097 top level 258 path @/.snapshots/84/snapshot
ID 1149 gen 914097 top level 258 path @/.snapshots/85/snapshot
ID 1150 gen 914097 top level 258 path @/.snapshots/86/snapshot
ID 1151 gen 914097 top level 258 path @/.snapshots/87/snapshot
ID 1155 gen 914097 top level 258 path @/.snapshots/88/snapshot
ID 1156 gen 914097 top level 258 path @/.snapshots/89/snapshot
ID 1157 gen 914097 top level 258 path @/.snapshots/90/snapshot
ID 1164 gen 914097 top level 258 path @/.snapshots/91/snapshot
ID 1165 gen 914097 top level 258 path @/.snapshots/92/snapshot
ID 1168 gen 914097 top level 258 path @/.snapshots/93/snapshot
ID 1232 gen 954180 top level 258 path @/.snapshots/94/snapshot
# mount -t btrfs -o subvol=home /dev/sdb2 /mnt/home
mount: /mnt/home: mount(2) system call failed: No such file or directory.

Am I missing something? Was a critical sector not successfully recovered by ddrescue?

6

Looks to me in your instance /home is in its own partition.
Maybe it’s an upgrade? Maybe I didn’t understand that the system was originally installed with a BTRFS root in 42.2? In that case /home should not be expected to be BTRFS, should be something else (possibly XFS).

TSU

7

You may mount the topmost subvolume of a partition and browse:


erlangen:~ # mount -o subvolid=5 /dev/sdb5 /mnt/
erlangen:~ # ll /mnt/@/
total 0
drwxr-x--- 1 root root   88 Feb  6 19:36 .snapshots
drwxr-xr-x 1 root root   10 Nov  8 18:54 boot
drwxr-xr-x 1 root root   14 Nov  8 18:54 etc
drwxr-xr-x 1 root root   14 Nov  9 13:03 opt
drwx------ 1 root root  722 Feb  6 16:45 root
drwxr-xr-x 1 root root   44 Nov  9 06:47 srv
drwxrwxrwt 1 root root 8424 Feb  7 08:00 tmp
drwxr-xr-x 1 root root   10 Nov  8 18:54 usr
drwxr-xr-x 1 root root  114 Jan 18 20:06 var
erlangen:~ #

Your /home could sit on a different partition, so you may want to check all partitions for btrfs.

8

I am sorry, but I just do not understand any of this.

The original SSD had a damaged rrot partition.
It was partitioned for Leap-42.3, then upgraded to 15.0 and 15.1
Presumably it had EFI, root, home and swap partitions (degault installation).

The damaged drive was cloned.
So the same partitions would be kept as on the original.
The old drives root partition (/dev/sdb2) was mounted at /mnt on the new drive.
Unless /dev/sdb[home] was mounted at </dev/sda[root]>/mnt/home, I would expect /mnt/home to appear as an empty directory (mount point). which is what I think you meant as “void”.

Assuming /home on the old drive was in /dev/sda3 what happens if you


  #  mount /dev/sdb2 /mnt
  #  mount /dev/sdb3 /mnt/home
  >  df -hT |grep -v tmpfs

I am interested in this thread because on the 15th January I updated Leap-15.1 on this laptop and was left with an unbootable system. The btrfs (no snapshots) root partition (/dev/sda3) was being mounted read-only.

I was unable to repair the filesystem so, using a usb rescue boot, I created a new partition (/dev/sda5), mounted sda3 on /mnt and sda5 on /mnt2, copied (cp -a) /mnt/ to /mnt2. chrooted to /mnt2 and used YaST to recreate /etc/fstab and the grub2-efi configuration.

I have been using the machine since, but am looking for hints to see if it is possible to repair the /dev/sda3 filesystem. I do not mean to hijack this thread and intended to start a new thread once I had time to read the btrfs documentation and do some experimentation.

9

Don’t tell about your assumptions, tell about what you have by running ‘fstab -l /dev/cloned-device’.

10 
# **parted -l **<!-- sdb only -->
Model: ATA WDC WD1600BJKT-7 (scsi)
Disk /dev/sdb: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  1078MB  1077MB  primary  ext2            boot, type=83
 2      1078MB  126GB   125GB   primary  btrfs           type=83
 3      126GB   128GB   2147MB  primary  linux-swap(v1)  type=82

That is result of

# **ddrescue /dev/sda /dev/sdb logfile** <!-- this from booting Knoppix USB; ddrescue is absent from Leap 15.1 installation media's rescue system -->

from a 128GB Kingston ssdNOW V series.

# **btrfs subvolume list /mnt | grep home**
ID 262 gen 954211 top level 257 path @/home
# **mount -o subvolid=262 /dev/sdb2 /mnt/**
mount: /mnt: /dev/sdb2 already mounted on /mnt.
# **ll /mnt/@/**
ls: cannot access '/mnt/@/': No such file or directory
11 
# **df -hT |grep -v tmpfs**
Filesystem        Type   Size  Used Avail Use% Mounted on
/dev/sda6         ext4    19G  5.3G   13G  31% /
/dev/sda2         ext2   388M  7.1M  381M   2% /usr/local/bin
/dev/sda1         ext2   794M  107M  647M  15% /boot
/dev/sda7         ext4    50G  4.6M   50G   1% /home <!-- no files or directories except lost+found -->
/dev/sdb2         btrfs  117G   46G   71G  40% /mnt
12

With the many subvolumes existing I found it annoying to inspect their contents by individually mounting them. Thus I changed my procedures to mount toplevel subvolume: **mount -o subvolid=5 /dev/sdb2 /mnt/ **You may try and report.

13 
# **btrfs subvolume list /mnt | grep home**
ID 262 gen 954211 top level 257 path @/home
# **mount -o subvolid=257 /dev/sdb2 /mnt/**
mount: /mnt: /dev/sdb2 already mounted on /mnt.
# **ll /mnt/@/**
ls: cannot access '/mnt/@/': No such file or directory
# **mount -o subvolid=262 /dev/sdb2 /mnt/home/**
# **ll /mnt/@/**
ls: cannot access '/mnt/@/': No such file or directory
# **ll /mnt/home/**
total 0
drwxr-xr-x 1 root root    28 Mar 11  2019 .
drwxr-xr-x 1 root root   182 Feb  5 00:29 ..
drwxr-xr-x 1 root root   876 Nov 12  2016 old-speed
drwxr-xr-x 1 1000 users 1076 Feb  4 22:43 speed
# **mc**

> highlight old-speed and speed > F5 >12433 of 71084 files copied before mc processing ceased in .local/share/Trash/, so I started over doing directory by directory from speed, getting whatever was readable. Probably less than three dozen lost among many thousands.

Mucho gracias!

14

Recommend start a new thread and if you wish refer back to this one.
Will not comment further on this likely tangent.

TSU

15

As the home directory was a btrfs sub-volume, I do not suppose that there is a chance it was included in the snapshots?

That is my intention, sorry that I was not clear.

16

You’re welcome! The procedure is the same as with any other file system.

Users new to btrfs may want to note:

  • The top-level subvolume (with Btrfs id 5) (which one can think of as the root of the volume) can be mounted, and the full filesystem structure will be seen at the mount point; alternatively any other subvolume can be mounted (with the mount options subvol or subvolid, for example subvol=subvol_a) and only anything below that subvolume (in the above example the subvolume subvol_b, its contents, and file file_4) will be visible at the mount point.
  • Subvolumes can be nested and each subvolume (except the top-level subvolume) has a parent subvolume. Mounting a subvolume also makes any of its nested child subvolumes available at their respective location relative to the mount-point.
  • A Btrfs filesystem has a default subvolume
    , which is initially set to be the top-level subvolume and which is mounted if no subvol or subvolid option is specified. - Changing the default subvolume with btrfs subvolume default will make the top level of the filesystem inaccessible, except by use of the subvol=/ or subvolid=5 mount options.
  • Subvolumes can be moved around in the filesystem.

From: SysadminGuide - btrfs Wiki