Announcement

**oshunluvr** · Oct 27, 2017, 08:07 AM

AFAIK, btrfs scan isn't really a command you would normal use since having the btrfs module loaded does this automatically. More likely, you would use btrfs filesystem show to list the available btrfs file systems.

However, the error you're getting might mean you need to manually create the control device node (which isn't normal either). I would assume this isn't required since your 16.04 partition works fine.But just in case, use at your own risk: sudo mknod /dev/btrfs-control c 10 234 Use "sudo" for all btrfs commands.

But a simple modprobe of btrfs should bring up the drive so they could be something else wrong. BTW, GRUB needs two things to work with btrfs:
1. Space to install
2. The btrfs module to be loaded.

Make sure you have insmod btrfs in all your 40_custom stanzas:

Code:

[FONT=monospace][COLOR=#000000]menuentry 'EXAMPLE MENU ENTRY' {[/COLOR]
   insmod part_gpt  
   [B]insmod btrfs[/B]
   search --no-floppy --fs-uuid --set=root <YOUR_UUID_ENTERED_HERE> 
   configfile /@/boot/grub/grub.cfg
}[/FONT]

As far as #1 - if you're using the entire drive instead of a partition, you can't install grub. But since you stated "partitions" I assume this isn't the case.

I haven't ever run into this error. It might be worth wiping the 17.10 partition by running fs-wipe on it, delete the partition, re-make it, re-format it, and re-install. I know that's a crappy answer, but as I said - I've never run into this and I've been using btrfs since tools version 0.19. Assuming you have access to the partition and can write to it and you have space on another btrfs partition, you could transmit the install and home subvolumes off of the damaged partition and avoid the re-install.

**kubicle** · Oct 27, 2017, 08:17 AM

Originally posted by oshunluvr View Post

However, the error you're getting might mean you need to manually create the control device node (which isn't normal either). I would assume this isn't required since your 16.04 partition works fine.But just in case, use at your own risk: sudo mknod /dev/btrfs-control c 10 234

It might not be missing, just not readable to regular users (commonly raw disk data is rw for "root" and group "disk" only), running the command with sudo should fix the permission errors.

**oshunluvr** · Oct 27, 2017, 08:59 AM

Originally posted by kubicle View Post

It might not be missing, just not readable to regular users (commonly raw disk data is rw for "root" and group "disk" only), running the command with sudo should fix the permission errors.

Good point - I just noticed that Teunis did not use sudo to run those commands, which is required. Testing here shows the same result if you don't use sudo. Initially, I did it with sudo reflexively.

**Teunis** · Oct 27, 2017, 10:34 AM

Ah yes sudo.
As a matter of fact I tried and it gave the same errors.

Presently I'm trying from the external neon disk that's also btrfs and oshunlvr's commands do work, these are the outputs:

Code:

teun@teun-verbatim:~$ sudo btrfs filesystem show
[sudo] password for teun: 
Label: none  uuid: 4dc91624-ef9e-42e9-b342-6e57e72a7d58   <== The external SSD with neon
       Total devices 1 FS bytes used 11.73GiB
       devid    1 size 58.90GiB used 14.02GiB path /dev/sdc1

Label: none  uuid: aedae254-9565-4a10-af93-ac80779b072d  <== The internal SSD partition with 17.10
       Total devices 1 FS bytes used 21.39GiB
       devid    1 size 153.32GiB used 24.02GiB path /dev/sda8

teun@teun-verbatim:~$ sudo btrfsck /dev/sda8
Checking filesystem on /dev/sda8
UUID: aedae254-9565-4a10-af93-ac80779b072d
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 22964232216 bytes used err is 0
total csum bytes: 20918244
total tree bytes: 1302953984
total fs tree bytes: 1238532096
total extent tree bytes: 38649856
btree space waste bytes: 210680044
file data blocks allocated: 81882648576
referenced 73780137984
teun@teun-verbatim:~$

This command could return errors but so far it looks OK to me.
Now I'm going back to 16.04, more to follow...

**Teunis** · Oct 27, 2017, 11:16 AM

Tried the same commands from 16.04, got the same returns.

sudo mknod /dev/btrfs-control c 10 234 returns the file already exists.

Because I had apt-btrfs-snapshot installed, from 16.04 I can see 15 snapshots were made.

Question, can I simply delete the first 10 or so?

About moving this install before a wipe, what commands are needed?

**oshunluvr** · Oct 27, 2017, 11:40 AM

Assuming your install boots from the subvolume named "@" which is the default (meaning, unless you changed it, that would be the case), you are free to delete any and all snapshots, just don't delete the original. When you do, I recommend using the "commit" option as it frees the file space immediately;

sudo btrfs su de -c <NAME_OF_SNAPSHOT_TO_DELETE>

Since you've checked the file system and all seems well, I'd look at grub again before taking the wipe-and-re-install path. Post your 40_custom just in case there's a typo you've missed and then I suggest re-installing grub from 16.04 and then updating it again.

**oshunluvr** · Oct 27, 2017, 11:46 AM

Another possibility: assuming enough free space exists on your partitioning containing 16.04, you could move the 17.10 install to the same partition as the 16.04 install and use it there. The steps would be:

Take a read-only snapshot of the 17.10 install and it's home subvolumes.
Use btrfs send|receive to move the snapshots to the other partition.
Re-snapshot the snapshot so it's read-write again.
Edit fstab and grub.cfg within the 17.10 subvolume to reflect the change in UUID and subvolume names.
Edit 40_custom to point to the 17.10 subvolume and update grub.

Done.
NOTE: I just realized you're not using btrfs for your 16.04 install? If that's correct, disregard this post. I suspect your 16.04 install didn't put btrfs.mod in your grub. Do "ls /boot/grub/i386-pc/btrfs.mod". If it returns an error, that's the issue.

**Teunis** · Oct 27, 2017, 12:15 PM

Yes indeed, 16.04 is on two ext4 partitions.
I have space on the external btrfs drive.

Using your example to delete the excess snapshots, kept the first and last two, worked fine but
would the result be any different using Dolphin?

The content of 4_custom:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "BTRFS 17.10" {
set root=(hd0,8)
linux /@/vmlinuz root=aedae254-9565-4a10-af93-ac80779b072d rootflags=subvol=@ ro quiet splash
initrd /@/initrd.img
}

The result of blkid:

teun@W520-15:~$ blkid
/dev/sda1: LABEL="SYSTEM_DRV" UUID="8A703FEA703FDB9F" TYPE="ntfs" PARTUUID="1079f598-01"
/dev/sda2: LABEL="Windows7_OS" UUID="9C16459816457474" TYPE="ntfs" PARTUUID="1079f598-02"
/dev/sda5: UUID="d9e70753-877b-48d1-8007-bd93a182b270" TYPE="swap" PARTUUID="1079f598-05"
/dev/sda6: UUID="bd623d61-43d2-4c12-b9ba-11280147578e" TYPE="ext4" PARTUUID="1079f598-06"
/dev/sda7: UUID="511218a5-2bd6-4db4-89ab-f935590c1e3d" TYPE="ext4" PARTUUID="1079f598-07"
/dev/sda8: UUID="aedae254-9565-4a10-af93-ac80779b072d" UUID_SUB="c6b0a261-4374-43aa-bdc7-54bb363bbc1a" TYPE="btrfs" PARTUUID="1079f598-08"
/dev/sdb1: LABEL="Caddy" UUID="348713a8-1de9-4a57-9138-4a0990f4526d" TYPE="ext4" PARTUUID="688323c1-01"
/dev/sdc1: UUID="4dc91624-ef9e-42e9-b342-6e57e72a7d58" UUID_SUB="ed5a15c2-3bc8-4dba-a1e0-474eb84b31ea" TYPE="btrfs" PARTUUID="1794c6c2-01"
teun@W520-15:~$

sda8 is the btrfs one.

**Snowhog** · Oct 27, 2017, 12:24 PM

If memory serves me correctly, I think your problem is with “set root=(hd0,8)”

Your specifying the first HDD (hd0) but the nineth partition (8), which you don’t have. Oshunluvr will correctly me if I’m wrong.

Well, apparently I am wrong (not the first, nor the last time).

https://www.gnu.org/software/grub/ma...tml#Filesystem

**Teunis** · Oct 27, 2017, 12:56 PM

I agree there are some oddities with the numbering as used by grub.
For that reason I consulted a similar document you linked to

This /dev/sda8 worked for two days.

I just tried one more time to use the KDE partition manager and this time it worked.

Another reboot to see if something broken was magically fixed...

**oshunluvr** · Oct 27, 2017, 12:58 PM

Yes, they did that on purpose so it was more confusing...

**Teunis** · Oct 27, 2017, 01:16 PM

I kind of support the grub numbering, once you make partitions you are typically installing on them meaning the disk itself is no longer in use.
In other words, the installation will be on hdax, never on hda.

Update; although I had the partition manager working there is still no way to boot from the btrfs partition.
An observation, after this recent reboot I just tried to run the partition manager and again it crashed, with or without the external SSD it won't work.

Update, mounting an subsequently dismounting the external btrfs disk will enable the KDE partition manager to run.
In other words, it needs a valid final partition or it will crash.

So a reinstall seems to be the next option.

**oshunluvr** · Oct 27, 2017, 01:19 PM

Well, your 40_custom is different than mine. The advantage to doing it my way, using the grub.cfg file on the other install as a nested menu, means you can select recovery or another kernel on the other install - not just the default one. Your way means you will only boot to the installed default kernel. This works 99% of the time - right up until it doesn't. On mine, I have the menu timeout set to 3 secs. on the first grub menu and 5 secs on the sub-menus.

Plus, if you select the submenu by mistake or change your mind, ESC brings you back to the first grub menu. Of course, I have 6 bootable distros installed using this method.

**oshunluvr** · Oct 27, 2017, 01:23 PM

Originally posted by Teunis View Post

Update; although I had the partition manager working there is still no way to boot from the btrfs partition.
An observation, after this recent reboot I just tried to run the partition manager and again it crashed, with or without the external SSD it won't work.
So a reinstall seems to be the next option.

Yeah, something is wildly wrong. I've never seen Kpartition manager crash this way either.

Announcement

A new btrfs booting problem

A new btrfs booting problem

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment