-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bcache partition not registered in initramfs (with raid probes from udev) #3
Comments
Is it the latest version from the PPA? Can you run blkid on that device, if it finds something non-bcache you'll have to remove it with wipefs (-a to confirm). Recent make-bcache should prevent you from getting into this situation, if it doesn't it's a bug. |
Yes, it's the latest version from PPA, I installed them 2 days ago. This is the output of blkid from the distro running on btrfs on the top of bcache: To make the bcache partitions, I did this:
Let me know if you need more info. |
Le 21/10/2013 01:53, Mattia Baldani a écrit :
(bcache isn't recognised without a beta release of blkid)
Seems like the udev rules are broken then. They have changed a bit |
I tried with version 1.0.1-1 and still doesn't work... |
I'm out of ideas right now. Either something is preventing the rule from running on the backing device, or something is keeping the device busy just when the kernel is trying to open it. Maybe the latter case would be mentioned in dmesg. Also, installing the package only rebuilds the newest initramfs, in the unlikely case you're booting into an older kernel it would still be running the 1.0.4-1 rules. |
I tried to replace register_quiet with register in /lib/udev/bcache-register, in order to see more dmesg messages, and this is the result: Oct 21 02:35:40 mattia-laptop kernel: [ 2.499854] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on minor 0 Unfortunately nothing of interesting... the cache device sdb1 is registered automatically, the backing device sda1 has been registered manually by me from the initramfs shell. I've used the same kernel for 1.0.1-1 version. I don't know exactly how the udev thing works, but I think the /lib/udev/bcache-register script is launched only for the cache sdb1 device, and not for the backing sda1. By adding a line in that script that registers sda1, everything works fine... |
This page has some info on debugging udev: You already have a |
In /var/log/udev I'm not able to see anything interesting. |
It probably landed in /var/log/syslog, I've updated the wiki page. |
I finally got the udev log from dmesg, this is the point where it register /dev/sdb1 but not the backing /dev/sda1 (look for the line in bold): [ 2.607431] systemd-udevd[111]: LINK 'disk/by-label/Ubuntu\x2013.10\x20amd64' /lib/udev/rules.d/60-persistent-storage.rules:79 |
The dmesg lines suggest that /dev/sda1 and /dev/sda2 are considered raid, Van: Mattia Baldani [email protected] I finally got the udev log from dmesg, this is the point where it register |
Ok thanks, I imagine it's an udev bug... I never had set up a raid in these disks I'm using |
Hi,
I installed your bcache-tools package from your ppa to use bcache for the root partition of my Ubuntu 13.10 install.
I have a bcache backing partition on my HDD at /dev/sda1, and a bcache caching partition on my SSD at /dev/sdb1.
On the top of /dev/bcache0, I have a btrfs filesystem, which is the root filesystem of my Ubuntu install.
The problem is: when I try to start Ubuntu, the boot procedure stops showing me the initramfs busybox shell, because it can't find the root btrfs filesystem which is inside bcache.
By looking at the busybox shell, I have seen that the bcache partition on my SSD is registered, but the one on my HDD not, so the /dev/bcache0 device is not created.
So I tried to launch in the initramfs shell: "echo /dev/sda1 > /sys/fs/bcache/register" and "exit", and then the system continued to boot perfectly.
As a workaround I added the line "echo /dev/sda1 > /sys/fs/bcache/register" at the end of /lib/udev/bcache-register. Now it works for me, but of course this is not a real solution :)
The text was updated successfully, but these errors were encountered: