RE: Can anyone boot a system using btrfs root with linux 3.14 or newer? - RESOLVED
The problem reported in this thread has been RESOLVED. It's not BTRFS's fault. Debugging on my part led to the actual problem in do_mounts.c - some filesystems mount routines return error codes other than 0, EACCES and EINVAL and such return codes result in the kernel panicking without trying to mount root with all of the available filesystems. Patch is available as attachment to bug 74901 - https://bugzilla.kernel.org/show_bug.cgi?id=74901 . The bugentry documents how I managed to find the problem. Also, the patch has been sent to the linux kernel mailing list - see http://news.gmane.org/find-root.php?group=gmane.linux.kernelarticle=1691881 Hopefully, it will find its way into the kernel, and later on - in stable releases. Thanks to you all! -- Plamen Petrov -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer? - RESOLVED
On 27/04/14 13:00, Пламен Петров wrote: The problem reported in this thread has been RESOLVED. It's not BTRFS's fault. Debugging on my part led to the actual problem in do_mounts.c - some filesystems mount routines return error codes other than 0, EACCES and EINVAL and such return codes result in the kernel panicking without trying to mount root with all of the available filesystems. Patch is available as attachment to bug 74901 - https://bugzilla.kernel.org/show_bug.cgi?id=74901 . The bugentry documents how I managed to find the problem. Well deduced and that looks to be a good natural clean fix. My only question is: What was the original intent to deliberately fail if something other than EACCES or EINVAL were reported? Also, the patch has been sent to the linux kernel mailing list - see http://news.gmane.org/find-root.php?group=gmane.linux.kernelarticle=1691881 Hopefully, it will find its way into the kernel, and later on - in stable releases. That all looks very good and very thorough. Thanks to you all! -- Plamen Petrov Thanks to you for chasing it through! AND for posting the Resolved to let everyone know. :-) Regards, Martin -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
Chris Mason posted on Thu, 24 Apr 2014 20:08:28 -0400 as excerpted: On 04/24/2014 08:04 PM, Chris Murphy wrote: So I don't think the order is it. The biggest difference I'm seeing between the 3.13.11 and 3.14.1 dmesg's provided: 3.13.11: [1.861740] bio: create slab bio-1 at 1 [1.863389] Btrfs loaded 3.14.1: [3.949312] bio: create slab bio-1 at 1 [3.950942] Btrfs loaded It's happening much later, and it's right at this point VFS complains: [4.182603] VFS: Cannot open root device sda2 or unknown-block(8,2): error -38 The 8,2 message is consistent with the kernel not knowing what file system sda2 is. Seems like it's saying I see sda2, I know you want to use it as root, but I don't know what's there - *poof* and it panics. That's what I'm thinking too... I vaguely recall there recently being btrfs boot problems with the module compiled in… Yes, it was with the crc code. I noticed he has compression on and I'm wondering if we're hitting a similar ordering problem with the zlib init. Everyone: I didn't think of this earlier, when I first saw the thread, but coming home and catching up after work, I think my subconscious must have been working on it all day, and even before I read this message, I was wondering if it might be another variant of that CRC32 problem. I was impatiently going thru the messages to see if someone mentioned it before I started another subthread on it... and here it is. =:^ But both crc32 and crc32c are loaded at about the same point in both kernels, before the filesystem tries to load, so that can't be it. But your zlib theory looks like a good candidate, Chris (Mason), and my sysadmin's intuition is behaving like a Geiger counter at Fukishima ATM, so I think we're on the right track! =:^) The best way to know for sure is to please try with an initrd. If that does work we'll know it's an init ordering problem and we can track it down from there. Indeed, altho as I know from experience, reading/writing that is a lot easier than actually setting up an initr*, if you've not used one in a decade and haven't the foggiest how to create one. (Being a gentooer here, I ended up following a recommendation from an only semi-related gentoo discussion, and setting up dracut for my initr* when I needed one to support a multi-device btrfs rootfs. Wasn't too hard, but I did need to set aside some undisturbed time to study up on it and get it configured and working. Since this thread's about a single-device btrfs rootfs, he got away without one until now, but...) Meanwhile, if an initr* bypasses the issue, the fact that I'm running a multi-device btrfs root here, and thus an initr*, would explain why I hadn't run into the problem, here... There goes that Geiger counter again! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Thu, Apr 24, 2014 at 10:23 AM, Chris Murphy li...@colorremedies.com wrote: It sounds like either a grub.cfg misconfiguration, or a failure to correctly build the initrd/initramfs. So I'd post the grub.cfg kernel command line for the boot entry that works and the entry that fails, for comparison. And then also check and see if whatever utility builds your initrd has been upgraded along with your kernel, maybe there's a bug/regression. I believe the OP mentioned that he's using a distro without initrd, and that all required modules are built in. -- Fajar Chris Murphy-- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On 04/23/2014 04:58 PM, Marc MERLIN wrote: On Wed, Apr 23, 2014 at 10:37:44PM +0300, Пламен Петров wrote: So now, we're kind of guessing. To save us all time, could you capture a serial console boot from the running 3.13 and then the failing 3.14. Well, for the details - see for example here: https://bugzilla.kernel.org/attachment.cgi?id=133111 how does a 3.14.1 built the way described earlier fails. Thanks, that helps. Except, now I'm perplexed. It indeed shows btrfs loaded and your block device being detected. However it does not show a btrfs mount error. The mount error is popping up after the printk about not being able to find root. Add rootwait to the command line. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On 04/24/2014 08:34 AM, Chris Mason wrote: On 04/23/2014 04:58 PM, Marc MERLIN wrote: On Wed, Apr 23, 2014 at 10:37:44PM +0300, Пламен Петров wrote: So now, we're kind of guessing. To save us all time, could you capture a serial console boot from the running 3.13 and then the failing 3.14. Well, for the details - see for example here: https://bugzilla.kernel.org/attachment.cgi?id=133111 how does a 3.14.1 built the way described earlier fails. Thanks, that helps. Except, now I'm perplexed. It indeed shows btrfs loaded and your block device being detected. However it does not show a btrfs mount error. The mount error is popping up after the printk about not being able to find root. Add rootwait to the command line. Sorry, that's almost but not quite what I meant to say. The device detection message is popping up after the printk about not being able to find root. Add rootwait to the command line. In other words, the mount is failing before the root device is detected. rootwait will make us wait (forever) instead of failing. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Can anyone boot a system using btrfs root with linux 3.14 or newer?
-Original Message- From: Chris Mason [mailto:c...@fb.com] Sent: Thursday, April 24, 2014 3:36 PM To: Marc MERLIN; Пламен Петров Cc: linux-btrfs@vger.kernel.org Subject: Re: Can anyone boot a system using btrfs root with linux 3.14 or newer? On 04/24/2014 08:34 AM, Chris Mason wrote: On 04/23/2014 04:58 PM, Marc MERLIN wrote: On Wed, Apr 23, 2014 at 10:37:44PM +0300, Пламен Петров wrote: So now, we're kind of guessing. To save us all time, could you capture a serial console boot from the running 3.13 and then the failing 3.14. Well, for the details - see for example here: https://bugzilla.kernel.org/attachment.cgi?id=133111 how does a 3.14.1 built the way described earlier fails. Thanks, that helps. Except, now I'm perplexed. It indeed shows btrfs loaded and your block device being detected. However it does not show a btrfs mount error. The mount error is popping up after the printk about not being able to find root. Add rootwait to the command line. Sorry, that's almost but not quite what I meant to say. The device detection message is popping up after the printk about not being able to find root. Add rootwait to the command line. In other words, the mount is failing before the root device is detected. rootwait will make us wait (forever) instead of failing. -chris Today I managed to try adding rootwait to the kernel commandline - the kernel panic with it in place, too. - Plamen Petrov -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Can anyone boot a system using btrfs root with linux 3.14 or newer?
-Original Message- From: Пламен Петров [mailto:pla...@petrovi.no-ip.info] Sent: Wednesday, April 23, 2014 10:38 PM To: 'Marc MERLIN' Cc: 'linux-btrfs@vger.kernel.org' Subject: RE: Can anyone boot a system using btrfs root with linux 3.14 or newer? -Original Message- From: Marc MERLIN [mailto:m...@merlins.org] Sent: Wednesday, April 23, 2014 10:16 PM To: Пламен Петров Cc: linux-btrfs@vger.kernel.org Subject: Re: Can anyone boot a system using btrfs root with linux 3.14 or newer? On Wed, Apr 23, 2014 at 10:06:12PM +0300, Пламен Петров wrote: Just to clarify - I am using a monolithic kernel built from source, and it has all the stuff it needs to support built-in, and then some. And no modules. The sources I'm using are the vanilla kernels from Linus and Greg KH downloaded from kernel.org. Ok. Check out the attached config I am using - it’s a kernel I'm running on one server and a couple of virtual machines. That's the working .config. I suggest you diff that one with the new one you have for 3.14 Until now - copying said config and doing a make oldconfig or make olddefconfig and compiling-then-booting worked fine. This should indeed work, this is what I do too. So now, we're kind of guessing. To save us all time, could you capture a serial console boot from the running 3.13 and then the failing 3.14. Well, for the details - see for example here: https://bugzilla.kernel.org/attachment.cgi?id=133111 how does a 3.14.1 built the way described earlier fails. And for that matter - see the whole bugzilla bug entry - I went on and bisected this, using the linux-stable git tree, and after that landed me on the commit that introduces some shiny new btrfs feature for 3.14 - I decided my git bisection has gone wrong. And because I reported it on April 17-th and since then there has been no activity on the bugzilla entry besides me updating it - I posted my problem here, for more eyes to see. I just realized that the l gave no way for identifying the particular bugzilla entry. Here it is: https://bugzilla.kernel.org/show_bug.cgi?id=74261 Sorry about that! - Plamen Petrov -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Thu, Apr 24, 2014 at 08:19:21PM +0300, Пламен Петров wrote: I just realized that the l gave no way for identifying the particular bugzilla entry. Here it is: https://bugzilla.kernel.org/show_bug.cgi?id=74261 Thanks. But to save us a lot more speculation, can you please try booting a linux system (either initrd, or another one with a non btrfs root), and then trying to mount that filesystem from the command line? Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Can anyone boot a system using btrfs root with linux 3.14 or newer?
-Original Message- From: Marc MERLIN [mailto:m...@merlins.org] Sent: Thursday, April 24, 2014 8:33 PM To: Пламен Петров Cc: linux-btrfs@vger.kernel.org Subject: Re: Can anyone boot a system using btrfs root with linux 3.14 or newer? On Thu, Apr 24, 2014 at 08:19:21PM +0300, Пламен Петров wrote: I just realized that the l gave no way for identifying the particular bugzilla entry. Here it is: https://bugzilla.kernel.org/show_bug.cgi?id=74261 Thanks. But to save us a lot more speculation, can you please try booting a linux system (either initrd, or another one with a non btrfs root), and then trying to mount that filesystem from the command line? Using 3.14.1 perhaps? I will try to do that now, but if I can't manage to do it today - expect the results tomorrow. One more detail I managed to rule out today is that my problematic filesystems used subvol-other-than-root as default, made like so: $ mount /dev/sda2 /sda2 -o relatime,compress=zlib,subvol=system-main-fs $ btrfs subvolume set-default system-main-fs /sda2 Only using different name for the subvolume. Anyway - its irrelevant. I formatted a fresh root as BTRFS, skipped the above, and tried booting 3.14.1 - result was kernel panic. So different default subvolume or not - its not the problem. - Plamen Petrov -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Thu, Apr 24, 2014 at 09:51:30PM +0300, Пламен Петров wrote: So, here is what I did: My debug VM had: sda sda1 200 MB /boot - ext2 sda2 5 GB / - BTRFS sda3 5 GB / - XFS sda4 One extra partition used for mangling (XFS). sda2 and sda3 were mostly the same, except /etc/fstab, for obvious reasons. I booted 3.14.1 using sda3 as root, and then tried mounting sda2. It went OK, here is what dmesg said: [ 12.412465] Btrfs loaded [ 86.490078] BTRFS: device fsid 2ba08fbc-4b95-46cc-b638-299f16462620 devid 1 transid 22 /dev/sda2 [ 86.492947] BTRFS info (device sda2): disk space caching is enabled [ 86.579155] BTRFS: creating UUID tree [ 86.748681] mount (1899) used greatest stack depth: 2560 bytes left Ok, that's good news. It indeed rules out that your new kernel cannot mount an older btrfs filesystem. At this point, you may have a problem with the device not being available when btrfs tries to mount it. From the above - the first obvious thing is that with 3.13.11 BTRFS gets loaded much earlier in the boot process - that is why the second dmesg dump is much larger, and both start at Btrfs loaded - mind you. Next was booting the BTRFS sda2 with 3.14.1. Sadly, it panicked again. So, no dmesg dump - just a screenshot. See the attached file. So, what got changed during the 3.14 merge window, that messed up booting for BTRFS partitions? Should I try building an allyesconfig kernel, in case something is messed up with my kernel .configs? What do you think guys and galls? Anything you want me try - this is entirely disposable VM now, so I'll gladly try everything you ask... So, I'm not sure how many people use btrfs built it vs as a module. Clearly the code works for mounting your partition, but when built in the kernel, there seems to be a timing issue. For reference, you said this was the bug where you found the CL that causes this change: https://bugzilla.kernel.org/show_bug.cgi?id=74261 You said using rootwait as recommended by Chris Mason did not help. What output are you getting when you use this? By the way, you should be able to define a pseudo serial port in your VM and specify something like console=tty0 console=ttyS0,38400n8 on your boot command line. This will give you serial console output in text that you can cut/paste/diff Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Can anyone boot a system using btrfs root with linux 3.14 or newer?
-Original Message- From: Marc MERLIN [mailto:m...@merlins.org] Sent: Thursday, April 24, 2014 10:31 PM To: Пламен Петров Cc: linux-btrfs@vger.kernel.org Subject: Re: Can anyone boot a system using btrfs root with linux 3.14 or newer? On Thu, Apr 24, 2014 at 09:51:30PM +0300, Пламен Петров wrote: So, here is what I did: My debug VM had: sda sda1 200 MB /boot - ext2 sda2 5 GB / - BTRFS sda3 5 GB / - XFS sda4 One extra partition used for mangling (XFS). sda2 and sda3 were mostly the same, except /etc/fstab, for obvious reasons. I booted 3.14.1 using sda3 as root, and then tried mounting sda2. It went OK, here is what dmesg said: [ 12.412465] Btrfs loaded [ 86.490078] BTRFS: device fsid 2ba08fbc-4b95-46cc-b638-299f16462620 devid 1 transid 22 /dev/sda2 [ 86.492947] BTRFS info (device sda2): disk space caching is enabled [ 86.579155] BTRFS: creating UUID tree [ 86.748681] mount (1899) used greatest stack depth: 2560 bytes left Ok, that's good news. It indeed rules out that your new kernel cannot mount an older btrfs filesystem. At this point, you may have a problem with the device not being available when btrfs tries to mount it. Need a way to pinpoint the actual problem then. From the above - the first obvious thing is that with 3.13.11 BTRFS gets loaded much earlier in the boot process - that is why the second dmesg dump is much larger, and both start at Btrfs loaded - mind you. Next was booting the BTRFS sda2 with 3.14.1. Sadly, it panicked again. So, no dmesg dump - just a screenshot. See the attached file. So, what got changed during the 3.14 merge window, that messed up booting for BTRFS partitions? Should I try building an allyesconfig kernel, in case something is messed up with my kernel .configs? What do you think guys and galls? Anything you want me try - this is entirely disposable VM now, so I'll gladly try everything you ask... So, I'm not sure how many people use btrfs built it vs as a module. Clearly the code works for mounting your partition, but when built in the kernel, there seems to be a timing issue. Yeah, and an issue that just popped up with kernels = 3.14. If memory serves - I started using BTRFS on linux 3.6.x, and since then I followed exactly the same method of upgrading the kernel - described in this thread and in the bugzilla entry - and it always Just Works TM! For reference, you said this was the bug where you found the CL that causes this change: https://bugzilla.kernel.org/show_bug.cgi?id=74261 You said using rootwait as recommended by Chris Mason did not help. What output are you getting when you use this? The image file attached to my previous mail applies to both rootwait and no-rootwait cases. Result is always a kernel panic for 3.14.x on BTRFS root. All other filesystem/kernel combos just work either way. By the way, you should be able to define a pseudo serial port in your VM and specify something like console=tty0 console=ttyS0,38400n8 on your boot command line. This will give you serial console output in text that you can cut/paste/diff I will try and use this the next time. Thanks! - Plamen Petrov -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Apr 24, 2014, at 12:51 PM, Пламен Петров pla...@petrovi.no-ip.info wrote: I booted 3.14.1 using sda3 as root, and then tried mounting sda2. It went OK, here is what dmesg said: [ 12.412465] Btrfs loaded For me, with Btrfs not compiled in the kernel, and with an initramfs, on SSD I get Btrfs loaded at 2.4 seconds. On HDD, it still happens by 6-7 seconds. So without an initrd and with btrfs compiled into the kernel I'd expect to see Btrfs loaded before 12.4 seconds. Is this an SSD? Or HDD, or hardware raid? I'd like to see the dmesg from the beginning, until Btrfs Loaded, for both 3.13.11 and 3.14.1 (via serial console output). I think the clue is in the part before Btrfs loaded. Also can you post a diff of the config file for the working 3.13.11 and not working 3.14.1 kernels? Chris Murphy-- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Can anyone boot a system using btrfs root with linux 3.14 or newer?
-Original Message- From: Chris Murphy [mailto:li...@colorremedies.com] Sent: Friday, April 25, 2014 12:06 AM To: Пламен Петров Cc: 'Marc MERLIN'; linux-btrfs@vger.kernel.org Subject: Re: Can anyone boot a system using btrfs root with linux 3.14 or newer? On Apr 24, 2014, at 12:51 PM, Пламен Петров pla...@petrovi.no-ip.info wrote: I booted 3.14.1 using sda3 as root, and then tried mounting sda2. It went OK, here is what dmesg said: [ 12.412465] Btrfs loaded For me, with Btrfs not compiled in the kernel, and with an initramfs, on SSD I get Btrfs loaded at 2.4 seconds. On HDD, it still happens by 6-7 seconds. Well, the actual time doesn't matter - I use this monolithic kernel on both virtual machines as well as a physical server. Up until 3.13.x this arrangement worked flawlessly, now for 3.14.x - everything will be the same except me using BTRFS... So without an initrd and with btrfs compiled into the kernel I'd expect to see Btrfs loaded before 12.4 seconds. Is this an SSD? Or HDD, or hardware raid? The most recent dmesg dumps were from a virtual machine. I'd like to see the dmesg from the beginning, until Btrfs Loaded, for both 3.13.11 and 3.14.1 (via serial console output). I think the clue is in the part before Btrfs loaded. I will try to provide these, but it will have to wait for tomorrow as currently my monolithic kernel .config does not support serial ports, so I will have to reconfigure, recompile both 3.13.x and 3.14.x to test them and provide the requested data. Also can you post a diff of the config file for the working 3.13.11 and not working 3.14.1 kernels? The requested diff was posted earlier, reattaching once more. - Plamen Petrov diff config-v3.14.1-mix64 config-v3.13.11-mix64 3c3 # Linux/x86 3.14.1 Kernel Configuration --- # Linux/x86 3.13.11 Kernel Configuration 155a156 # CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set 230,234d230 CONFIG_HAVE_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR is not set CONFIG_CC_STACKPROTECTOR_NONE=y # CONFIG_CC_STACKPROTECTOR_REGULAR is not set # CONFIG_CC_STACKPROTECTOR_STRONG is not set 309d304 # CONFIG_XEN_PVH is not set 358a354 CONFIG_MICROCODE_INTEL_LIB=y 407d402 # CONFIG_ZSMALLOC is not set 419a415 # CONFIG_CC_STACKPROTECTOR is not set 430d425 # CONFIG_RANDOMIZE_BASE is not set 762,763d756 # CONFIG_NET_SCH_HHF is not set # CONFIG_NET_SCH_PIE is not set 794,795c787 # CONFIG_CGROUP_NET_PRIO is not set # CONFIG_CGROUP_NET_CLASSID is not set --- # CONFIG_NETPRIO_CGROUP is not set 944d935 # CONFIG_GENWQE is not set 997a989 # CONFIG_SCSI_AIC7XXX_OLD is not set 1158d1149 CONFIG_DM_BUFIO=y 1256d1246 # CONFIG_I40EVF is not set 1489d1478 CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y 1608d1596 # CONFIG_I2C_DESIGNWARE_PLATFORM is not set 1622d1609 # CONFIG_I2C_ROBOTFUZZ_OSIF is not set 1807a1795 # CONFIG_CPU_THERMAL is not set 1811d1798 # CONFIG_ACPI_INT3403_THERMAL is not set 1851d1837 # CONFIG_MFD_MAX14577 is not set 1872d1857 # CONFIG_MFD_LP3943 is not set 1904d1888 CONFIG_INTEL_GTT=y 1928d1911 # CONFIG_DRM_I915_UMS is not set 1940d1922 # CONFIG_DRM_BOCHS is not set 1978d1959 # CONFIG_FB_OPENCORES is not set 2080a2062 # CONFIG_HID_LOGITECH_DJ is not set 2184d2165 # CONFIG_USB_MUSB_HDRC is not set 2186d2166 # CONFIG_USB_DWC2 is not set 2225d2204 # CONFIG_USB_OTG_FSM is not set 2269d2247 # CONFIG_RTC_DRV_ISL12057 is not set 2403d2380 CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y 2450a2428 CONFIG_GENERIC_ACL=y 2604d2581 CONFIG_PANIC_TIMEOUT=0
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Apr 24, 2014, at 2:26 PM, Пламен Петров pla...@petrovi.no-ip.info wrote: -Original Message- From: Marc MERLIN [mailto:m...@merlins.org] You said using rootwait as recommended by Chris Mason did not help. What output are you getting when you use this? The image file attached to my previous mail applies to both rootwait and no-rootwait cases. Result is always a kernel panic for 3.14.x on BTRFS root. All other filesystem/kernel combos just work either way. rootwait should mean it waits indefinitely for rootfs to appear, so why does it still kernel panic? Is the root= parameter using UUID? If not can you try UUID instead of /dev/sda2? For Btrfs this is still the volume UUID, not subvolume UUID. Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Fri, Apr 25, 2014 at 01:22:32AM +0300, Пламен Петров wrote: -Original Message- From: Chris Murphy [mailto:li...@colorremedies.com] Sent: Friday, April 25, 2014 12:06 AM To: Пламен Петров Cc: 'Marc MERLIN'; linux-btrfs@vger.kernel.org Subject: Re: Can anyone boot a system using btrfs root with linux 3.14 or newer? On Apr 24, 2014, at 12:51 PM, Пламен Петров pla...@petrovi.no-ip.info wrote: I booted 3.14.1 using sda3 as root, and then tried mounting sda2. It went OK, here is what dmesg said: [ 12.412465] Btrfs loaded For me, with Btrfs not compiled in the kernel, and with an initramfs, on SSD I get Btrfs loaded at 2.4 seconds. On HDD, it still happens by 6-7 seconds. So without an initrd and with btrfs compiled into the kernel I'd expect to see Btrfs loaded before 12.4 seconds. Is this an SSD? Or HDD, or hardware raid? I'd like to see the dmesg from the beginning, until Btrfs Loaded, for both 3.13.11 and 3.14.1 (via serial console output). I think the clue is in the part before Btrfs loaded. Also can you post a diff of the config file for the working 3.13.11 and not working 3.14.1 kernels? Attached to this mail find the requested kernel .config files, the result of duff -u between them, as well as the output to serial console of both kernels 3.13.11 and 3.14.1 compiled with attached configs. Thanks for the serial console logs. I see that you didn't add rootwait to the command line of your 3.14 boot. Please do that so that we can see that output. I'm pasting a diff of them for the benefit of others. The obvious things to me are: In 3.13 the device appears after btrfs is loaded: Btrfs loaded (...) scsi2 : ioc0: LSI53C1030 B0, FwRev=01032920h, Ports=1, MaxQ=128, IRQ=17 scsi 2:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2 scsi target2:0:0: Beginning Domain Validation scsi target2:0:0: Domain Validation skipping write tests scsi target2:0:0: Ending Domain Validation scsi target2:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 127) sd 2:0:0:0: [sda] 25165824 512-byte logical blocks: (12.8 GB/12.0 GiB) sd 2:0:0:0: [sda] Write Protect is off sd 2:0:0:0: [sda] Cache data unavailable sd 2:0:0:0: [sda] Assuming drive cache: write through sd 2:0:0:0: [sda] Cache data unavailable sd 2:0:0:0: [sda] Assuming drive cache: write through sd 2:0:0:0: Attached scsi generic sg1 type 0 Fusion MPT FC Host driver 3.04.20 Fusion MPT SAS Host driver 3.04.20 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-pci: EHCI PCI platform driver ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci-pci: OHCI PCI platform driver sda: sda1 sda2 sda3 sda4 In 3.14 the device shows up before btrfs is loaded: sd 2:0:0:0: [sda] Cache data unavailable sd 2:0:0:0: [sda] Assuming drive cache: write through sd 2:0:0:0: [sda] Attached SCSI disk (...) Btrfs loaded --- dmesg-3.13.11-mix64-serial.txt 2014-04-24 16:00:44.442491091 -0700 +++ dmesg-3.14.1-mix64-serial.txt 2014-04-24 16:00:50.394404267 -0700 @@ -1,7 +1,7 @@ Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Initializing cgroup subsys cpuacct -Linux version 3.13.11-mix64 (root@crux) (gcc version 4.7.3 (CRUX-x86_64-multilib) ) #1 SMP Fri Apr 25 00:59:11 EEST 2014 +Linux version 3.14.1-mix64 (root@crux) (gcc version 4.7.3 (CRUX-x86_64-multilib) ) #1 SMP Fri Apr 25 00:31:28 EEST 2014 Command line: rw root=/dev/sda2 vga=6 raid=noautodetect console=ttyS0,9600n8 console=tty0 e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009efff] usable @@ -190,7 +190,7 @@ e820: [mem 0x4000-0xefff] available for PCI devices Booting paravirtualized kernel on bare hardware setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1 -PERCPU: Embedded 25 pages/cpu @88003fc0 s8 r0 d22400 u262144 +PERCPU: Embedded 25 pages/cpu @88003fc0 s80192 r0 d22208 u262144 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 257897 Kernel command line: rw root=/dev/sda2 vga=6 raid=noautodetect console=ttyS0,9600n8 console=tty0 PID hash table entries: 4096 (order: 3, 32768 bytes) @@ -198,7 +198,7 @@ Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... No AGP bridge found -Memory: 1012808K/1048056K available (7848K kernel code, 519K rwdata, 2604K rodata, 920K init, 2572K bss, 35248K reserved) +Memory: 1012780K/1048056K available (7943K kernel code, 527K rwdata, 2628K rodata, 932K init, 2580K bss, 35276K reserved) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 Hierarchical RCU implementation. CONFIG_RCU_FANOUT set to non-default value of 32 @@ -210,16 +210,16 @@ tsc: Detected 3000.079 MHz processor Calibrating delay loop (skipped) preset value.. 6000.15 BogoMIPS (lpj=3790) pid_max: default: 32768 minimum: 301 +ACPI: Core revision 20131218 +ACPI: All ACPI Tables successfully acquired Security
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Apr 24, 2014, at 5:07 PM, Marc MERLIN m...@merlins.org wrote: In 3.14 the device shows up before btrfs is loaded: sd 2:0:0:0: [sda] Cache data unavailable sd 2:0:0:0: [sda] Assuming drive cache: write through sd 2:0:0:0: [sda] Attached SCSI disk (...) Btrfs loaded Same for me though, and I can boot. [0.693215] ata1.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133 [0.693799] ata1.00: 167772160 sectors, multi 128: LBA48 NCQ (depth 31/32) [0.694153] ata1.00: configured for UDMA/133 [0.695475] scsi 0:0:0:0: Direct-Access ATA VBOX HARDDISK1.0 PQ: 0 ANSI: 5 [0.699386] sd 0:0:0:0: [sda] 167772160 512-byte logical blocks: (85.8 GB/80.0 GiB) [0.699443] sd 0:0:0:0: Attached scsi generic sg0 type 0 [0.700604] sd 0:0:0:0: [sda] Write Protect is off [0.701151] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [0.701187] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [0.707841] sda: sda1 sda2 sda3 [0.709846] sd 0:0:0:0: [sda] Attached SCSI disk (…) [2.380090] bio: create slab bio-1 at 1 [2.384645] Btrfs loaded So I don't think the order is it. The biggest difference I'm seeing between the 3.13.11 and 3.14.1 dmesg's provided: 3.13.11: [1.861740] bio: create slab bio-1 at 1 [1.863389] Btrfs loaded 3.14.1: [3.949312] bio: create slab bio-1 at 1 [3.950942] Btrfs loaded It's happening much later, and it's right at this point VFS complains: [4.182603] VFS: Cannot open root device sda2 or unknown-block(8,2): error -38 The 8,2 message is consistent with the kernel not knowing what file system sda2 is. Seems like it's saying I see sda2, I know you want to use it as root, but I don't know what's there - *poof* and it panics. If rootwait alone doesn't work, I wonder if root=uuid=2ba08fbc-4b95-46cc-b638-299f16462620 instead of root=/dev/sda2 will work along with rootwait. It should then wait for that fs uuid to become available, rather than waiting for sda2 to become available. I vaguely recall there recently being btrfs boot problems with the module compiled in… Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On 04/24/2014 08:04 PM, Chris Murphy wrote: On Apr 24, 2014, at 5:07 PM, Marc MERLIN m...@merlins.org wrote: In 3.14 the device shows up before btrfs is loaded: sd 2:0:0:0: [sda] Cache data unavailable sd 2:0:0:0: [sda] Assuming drive cache: write through sd 2:0:0:0: [sda] Attached SCSI disk (...) Btrfs loaded Same for me though, and I can boot. [0.693215] ata1.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133 [0.693799] ata1.00: 167772160 sectors, multi 128: LBA48 NCQ (depth 31/32) [0.694153] ata1.00: configured for UDMA/133 [0.695475] scsi 0:0:0:0: Direct-Access ATA VBOX HARDDISK1.0 PQ: 0 ANSI: 5 [0.699386] sd 0:0:0:0: [sda] 167772160 512-byte logical blocks: (85.8 GB/80.0 GiB) [0.699443] sd 0:0:0:0: Attached scsi generic sg0 type 0 [0.700604] sd 0:0:0:0: [sda] Write Protect is off [0.701151] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [0.701187] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [0.707841] sda: sda1 sda2 sda3 [0.709846] sd 0:0:0:0: [sda] Attached SCSI disk (…) [2.380090] bio: create slab bio-1 at 1 [2.384645] Btrfs loaded So I don't think the order is it. The biggest difference I'm seeing between the 3.13.11 and 3.14.1 dmesg's provided: 3.13.11: [1.861740] bio: create slab bio-1 at 1 [1.863389] Btrfs loaded 3.14.1: [3.949312] bio: create slab bio-1 at 1 [3.950942] Btrfs loaded It's happening much later, and it's right at this point VFS complains: [4.182603] VFS: Cannot open root device sda2 or unknown-block(8,2): error -38 The 8,2 message is consistent with the kernel not knowing what file system sda2 is. Seems like it's saying I see sda2, I know you want to use it as root, but I don't know what's there - *poof* and it panics. If rootwait alone doesn't work, I wonder if root=uuid=2ba08fbc-4b95-46cc-b638-299f16462620 instead of root=/dev/sda2 will work along with rootwait. It should then wait for that fs uuid to become available, rather than waiting for sda2 to become available. I vaguely recall there recently being btrfs boot problems with the module compiled in… Yes, it was with the crc code. I noticed he has compression on and I'm wondering if we're hitting a similar ordering problem with the zlib init. The best way to know for sure is to please try with an initrd. If that does work we'll know it's an init ordering problem and we can track it down from there. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Can anyone boot a system using btrfs root with linux 3.14 or newer?
-Original Message- From: Chris Murphy [mailto:li...@colorremedies.com] Sent: Friday, April 25, 2014 3:04 AM To: Marc MERLIN Cc: Пламен Петров; linux-btrfs@vger.kernel.org Subject: Re: Can anyone boot a system using btrfs root with linux 3.14 or newer? On Apr 24, 2014, at 5:07 PM, Marc MERLIN m...@merlins.org wrote: In 3.14 the device shows up before btrfs is loaded: sd 2:0:0:0: [sda] Cache data unavailable sd 2:0:0:0: [sda] Assuming drive cache: write through sd 2:0:0:0: [sda] Attached SCSI disk (...) Btrfs loaded Same for me though, and I can boot. [0.693215] ata1.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133 [0.693799] ata1.00: 167772160 sectors, multi 128: LBA48 NCQ (depth 31/32) [0.694153] ata1.00: configured for UDMA/133 [0.695475] scsi 0:0:0:0: Direct-Access ATA VBOX HARDDISK 1.0 PQ: 0 ANSI: 5 [0.699386] sd 0:0:0:0: [sda] 167772160 512-byte logical blocks: (85.8 GB/80.0 GiB) [0.699443] sd 0:0:0:0: Attached scsi generic sg0 type 0 [0.700604] sd 0:0:0:0: [sda] Write Protect is off [0.701151] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [0.701187] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [0.707841] sda: sda1 sda2 sda3 [0.709846] sd 0:0:0:0: [sda] Attached SCSI disk (:) [2.380090] bio: create slab bio-1 at 1 [2.384645] Btrfs loaded So I don't think the order is it. The biggest difference I'm seeing between the 3.13.11 and 3.14.1 dmesg's provided: 3.13.11: [1.861740] bio: create slab bio-1 at 1 [1.863389] Btrfs loaded 3.14.1: [3.949312] bio: create slab bio-1 at 1 [3.950942] Btrfs loaded It's happening much later, and it's right at this point VFS complains: [4.182603] VFS: Cannot open root device sda2 or unknown-block(8,2): error -38 The 8,2 message is consistent with the kernel not knowing what file system sda2 is. Seems like it's saying I see sda2, I know you want to use it as root, but I don't know what's there - *poof* and it panics. If rootwait alone doesn't work, I wonder if root=uuid=2ba08fbc-4b95-46cc- b638-299f16462620 instead of root=/dev/sda2 will work along with rootwait. It should then wait for that fs uuid to become available, rather than waiting for sda2 to become available. It does indeed wait, but I did not wait for it - just booted, saw it ended in Waiting for root device uuid=... and pasted the serial output. Is it supposed to somehow find its rootfs later? See the attached file. - Plamen Petrov [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.14.1-mix64 (root@crux) (gcc version 4.7.3 (CRUX-x86_64-multilib) ) #1 SMP Fri Apr 25 00:31:28 EEST 2014 [0.00] Command line: rw root=uuid=2ba08fbc-4b95-46cc-b638-299f16462620 vga=6 raid=noautodetect console=ttyS0,9600n8 console=tty0 rootwait [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009efff] usable [0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000ca000-0x000cbfff] reserved [0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x3fed] usable [0.00] BIOS-e820: [mem 0x3fee-0x3fefefff] ACPI data [0.00] BIOS-e820: [mem 0x3feff000-0x3fef] ACPI NVS [0.00] BIOS-e820: [mem 0x3ff0-0x3fff] usable [0.00] BIOS-e820: [mem 0xf000-0xf7ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xfffe-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] Hypervisor detected: VMware [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x4 max_arch_pfn = 0x4 [0.00] x86 PAT enabled: cpu 0, old 0x0, new 0x7010600070106 [0.00] found SMP MP-table at [mem 0x000f6bf0-0x000f6bff] mapped at [880f6bf0] [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] init_memory_mapping: [mem 0x3fc0-0x3fdf] [0.00] init_memory_mapping: [mem 0x3c00-0x3fbf] [0.00] init_memory_mapping: [mem 0x0010-0x3bff] [0.00] init_memory_mapping: [mem 0x3fe0-0x3fed] [0.00] init_memory_mapping: [mem 0x3ff0-0x3fff] [0.00] ACPI: RSDP 000f6b80 24 (v02 PTLTD ) [0.00] ACPI: XSDT 3feeda33 5C (v01 INTEL 440BX
RE: Can anyone boot a system using btrfs root with linux 3.14 or newer?
-Original Message- From: Chris Mason [mailto:c...@fb.com] Sent: Friday, April 25, 2014 3:08 AM To: Chris Murphy; Marc MERLIN Cc: Пламен Петров; linux-btrfs@vger.kernel.org Subject: Re: Can anyone boot a system using btrfs root with linux 3.14 or newer? On 04/24/2014 08:04 PM, Chris Murphy wrote: On Apr 24, 2014, at 5:07 PM, Marc MERLIN m...@merlins.org wrote: In 3.14 the device shows up before btrfs is loaded: sd 2:0:0:0: [sda] Cache data unavailable sd 2:0:0:0: [sda] Assuming drive cache: write through sd 2:0:0:0: [sda] Attached SCSI disk (...) Btrfs loaded Same for me though, and I can boot. [0.693215] ata1.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133 [0.693799] ata1.00: 167772160 sectors, multi 128: LBA48 NCQ (depth 31/32) [0.694153] ata1.00: configured for UDMA/133 [0.695475] scsi 0:0:0:0: Direct-Access ATA VBOX HARDDISK 1.0 PQ: 0 ANSI: 5 [0.699386] sd 0:0:0:0: [sda] 167772160 512-byte logical blocks: (85.8 GB/80.0 GiB) [0.699443] sd 0:0:0:0: Attached scsi generic sg0 type 0 [0.700604] sd 0:0:0:0: [sda] Write Protect is off [0.701151] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [0.701187] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [0.707841] sda: sda1 sda2 sda3 [0.709846] sd 0:0:0:0: [sda] Attached SCSI disk (…) [2.380090] bio: create slab bio-1 at 1 [2.384645] Btrfs loaded So I don't think the order is it. The biggest difference I'm seeing between the 3.13.11 and 3.14.1 dmesg's provided: 3.13.11: [1.861740] bio: create slab bio-1 at 1 [1.863389] Btrfs loaded 3.14.1: [3.949312] bio: create slab bio-1 at 1 [3.950942] Btrfs loaded It's happening much later, and it's right at this point VFS complains: [4.182603] VFS: Cannot open root device sda2 or unknown-block(8,2): error -38 The 8,2 message is consistent with the kernel not knowing what file system sda2 is. Seems like it's saying I see sda2, I know you want to use it as root, but I don't know what's there - *poof* and it panics. If rootwait alone doesn't work, I wonder if root=uuid=2ba08fbc-4b95-46cc- b638-299f16462620 instead of root=/dev/sda2 will work along with rootwait. It should then wait for that fs uuid to become available, rather than waiting for sda2 to become available. I vaguely recall there recently being btrfs boot problems with the module compiled in… Yes, it was with the crc code. I noticed he has compression on and I'm wondering if we're hitting a similar ordering problem with the zlib init. The best way to know for sure is to please try with an initrd. This will have to wait, though. Busy right now. If that does work we'll know it's an init ordering problem and we can track it down from there. Thanks, guys! Plamen Petrov -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Can anyone boot a system using btrfs root with linux 3.14 or newer?
Can anyone boot a system using btrfs root with linux 3.14 or newer? Because I can't. I'm trying to move some 3.13.x based systems to 3.14.x and the kernel panics during boot. It says to append a correct root=sdaX partition, but the one provided is correct, because if use 3.13.x with the same kernel command line - the system boots fine. The thing is - there is an ext2 /boot partition and root / is btrfs, like so: # cat /etc/fstab # # /etc/fstab: static file system information # # file systemdir typeoptions dump pass #/dev/#REISERFS_ROOT# / reiserfs defaults 0 0 #/dev/#EXT3FS_ROOT#/ ext3 defaults 0 1 /dev/sda2 / btrfs relatime,compress=zlib 0 0 /dev/sda1 /boot ext4 defaults 0 1 #/dev/#JFS_ROOT# / jfs defaults 1 1 Here is my relevant GRUB config file part: #menuentry 0 title Linux root (hd0,0) kernel /vmlinuz rw root=/dev/sda2 vga=6 raid=noautodetect And for the record - I used the same kernel config as the one from 3.13.x - I just copied my old .config file over to linux 3.14.x sources and did a make olddefconfig and compiled my kernel, just as I did with all previous ones... Ideas? P.S. Please, CC me - I'm not subscribed. - Plamen Petrov -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Wed, Apr 23, 2014 at 08:30:08PM +0300, Пламен Петров wrote: Can anyone boot a system using btrfs root with linux 3.14 or newer? Because I can't. It works fine for me. I'm trying to move some 3.13.x based systems to 3.14.x and the kernel panics during boot. It says to append a correct root=sdaX partition, but the one provided is correct, because if use 3.13.x with the same kernel command line - the system boots fine. My guess is that you have btrfs compiled as a module, it then needs to be in an initrd, and you either haven't built it and put it in the right place, or grub isn't setup to load that initrd. #menuentry 0 title Linux root (hd0,0) kernel /vmlinuz rw root=/dev/sda2 vga=6 raid=noautodetect That's missing an initrd. Are you absolutely certain then that btrfs is compiled in the kernel and not as a module? Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Wed, Apr 23, 2014 at 11:54:13AM -0700, Marc MERLIN wrote: On Wed, Apr 23, 2014 at 08:30:08PM +0300, Пламен Петров wrote: Can anyone boot a system using btrfs root with linux 3.14 or newer? Because I can't. It works fine for me. I'm trying to move some 3.13.x based systems to 3.14.x and the kernel panics during boot. It says to append a correct root=sdaX partition, but the one provided is correct, because if use 3.13.x with the same kernel command line - the system boots fine. My guess is that you have btrfs compiled as a module, it then needs to be in an initrd, and you either haven't built it and put it in the right place, or grub isn't setup to load that initrd. #menuentry 0 title Linux root (hd0,0) kernel /vmlinuz rw root=/dev/sda2 vga=6 raid=noautodetect That's missing an initrd. Are you absolutely certain then that btrfs is compiled in the kernel and not as a module? And the other thing to check here is that if this is a multi-device filesystem, you need to have your initrd run btrfs dev scan before trying to mount. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- The glass is neither half-full nor half-empty; it is twice as --- large as it needs to be. signature.asc Description: Digital signature
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Wed, Apr 23, 2014 at 10:06:12PM +0300, Пламен Петров wrote: Just to clarify - I am using a monolithic kernel built from source, and it has all the stuff it needs to support built-in, and then some. And no modules. The sources I'm using are the vanilla kernels from Linus and Greg KH downloaded from kernel.org. Ok. Check out the attached config I am using - it’s a kernel I'm running on one server and a couple of virtual machines. That's the working .config. I suggest you diff that one with the new one you have for 3.14 Until now - copying said config and doing a make oldconfig or make olddefconfig and compiling-then-booting worked fine. This should indeed work, this is what I do too. So now, we're kind of guessing. To save us all time, could you capture a serial console boot from the running 3.13 and then the failing 3.14. My guess is that if you diff both you'll likely find what went wrong, but if not you can post here. As for the btrfs FS format, it has not changed in a way that new kernels wouldn't be able to mount an FS from a year ago or more. Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
Пламен Петров pla...@petrovi.no-ip.info schrieb: I'm going with the module suggestion from Marc, too. /dev/sda2 / btrfs relatime,compress=zlib 0 0 This line looks kinda useless to me. The compress=zlib option won't be applied at boot and cannot be changed at runtime because AFAIR btrfs does not allow that yet. This is because during initial mount by the kernel, /etc/fstab has not yet been read (and cannot for obvious reasons). The only way around it is to also append rootflags= to the kernel cmdline. This also explains why in a few other cases btrfs cannot be mounted, although it should make no difference in your case except the compress option won't be applied to the running file system. Also, you may want to try rootdelay=2 or something similar, it sometimes help mounting btrfs at boot. But first try the suggestion abount baking the btrfs module right into the kernel. -- Replies to list only preferred. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Can anyone boot a system using btrfs root with linux 3.14 or newer?
-Original Message- From: Marc MERLIN [mailto:m...@merlins.org] Sent: Wednesday, April 23, 2014 10:16 PM To: Пламен Петров Cc: linux-btrfs@vger.kernel.org Subject: Re: Can anyone boot a system using btrfs root with linux 3.14 or newer? On Wed, Apr 23, 2014 at 10:06:12PM +0300, Пламен Петров wrote: Just to clarify - I am using a monolithic kernel built from source, and it has all the stuff it needs to support built-in, and then some. And no modules. The sources I'm using are the vanilla kernels from Linus and Greg KH downloaded from kernel.org. Ok. Check out the attached config I am using - it’s a kernel I'm running on one server and a couple of virtual machines. That's the working .config. I suggest you diff that one with the new one you have for 3.14 Until now - copying said config and doing a make oldconfig or make olddefconfig and compiling-then-booting worked fine. This should indeed work, this is what I do too. So now, we're kind of guessing. To save us all time, could you capture a serial console boot from the running 3.13 and then the failing 3.14. Well, for the details - see for example here: https://bugzilla.kernel.org/attachment.cgi?id=133111 how does a 3.14.1 built the way described earlier fails. And for that matter - see the whole bugzilla bug entry - I went on and bisected this, using the linux-stable git tree, and after that landed me on the commit that introduces some shiny new btrfs feature for 3.14 - I decided my git bisection has gone wrong. And because I reported it on April 17-th and since then there has been no activity on the bugzilla entry besides me updating it - I posted my problem here, for more eyes to see. My guess is that if you diff both you'll likely find what went wrong, but if not you can post here. See the result of diff config-v3.14.1-mix64 config-v3.13.11-mix64 in the attached file. As for the btrfs FS format, it has not changed in a way that new kernels wouldn't be able to mount an FS from a year ago or more. Good to know! Thanks! Marc - Plamen Petrov diff config-v3.14.1-mix64 config-v3.13.11-mix64 3c3 # Linux/x86 3.14.1 Kernel Configuration --- # Linux/x86 3.13.11 Kernel Configuration 155a156 # CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set 230,234d230 CONFIG_HAVE_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR is not set CONFIG_CC_STACKPROTECTOR_NONE=y # CONFIG_CC_STACKPROTECTOR_REGULAR is not set # CONFIG_CC_STACKPROTECTOR_STRONG is not set 309d304 # CONFIG_XEN_PVH is not set 358a354 CONFIG_MICROCODE_INTEL_LIB=y 407d402 # CONFIG_ZSMALLOC is not set 419a415 # CONFIG_CC_STACKPROTECTOR is not set 430d425 # CONFIG_RANDOMIZE_BASE is not set 762,763d756 # CONFIG_NET_SCH_HHF is not set # CONFIG_NET_SCH_PIE is not set 794,795c787 # CONFIG_CGROUP_NET_PRIO is not set # CONFIG_CGROUP_NET_CLASSID is not set --- # CONFIG_NETPRIO_CGROUP is not set 944d935 # CONFIG_GENWQE is not set 997a989 # CONFIG_SCSI_AIC7XXX_OLD is not set 1158d1149 CONFIG_DM_BUFIO=y 1256d1246 # CONFIG_I40EVF is not set 1489d1478 CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y 1608d1596 # CONFIG_I2C_DESIGNWARE_PLATFORM is not set 1622d1609 # CONFIG_I2C_ROBOTFUZZ_OSIF is not set 1807a1795 # CONFIG_CPU_THERMAL is not set 1811d1798 # CONFIG_ACPI_INT3403_THERMAL is not set 1851d1837 # CONFIG_MFD_MAX14577 is not set 1872d1857 # CONFIG_MFD_LP3943 is not set 1904d1888 CONFIG_INTEL_GTT=y 1928d1911 # CONFIG_DRM_I915_UMS is not set 1940d1922 # CONFIG_DRM_BOCHS is not set 1978d1959 # CONFIG_FB_OPENCORES is not set 2080a2062 # CONFIG_HID_LOGITECH_DJ is not set 2184d2165 # CONFIG_USB_MUSB_HDRC is not set 2186d2166 # CONFIG_USB_DWC2 is not set 2225d2204 # CONFIG_USB_OTG_FSM is not set 2269d2247 # CONFIG_RTC_DRV_ISL12057 is not set 2403d2380 CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y 2450a2428 CONFIG_GENERIC_ACL=y 2604d2581 CONFIG_PANIC_TIMEOUT=0
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Wed, 2014-04-23 at 21:06 +0200, Kai Krakow wrote: Пламен Петров pla...@petrovi.no-ip.info schrieb: I'm going with the module suggestion from Marc, too. /dev/sda2 / btrfs relatime,compress=zlib 0 0 This line looks kinda useless to me. The compress=zlib option won't be applied at boot and cannot be changed at runtime because AFAIR btrfs does not allow that yet. ... My understanding is that the compress= option on btrfs *can* be changed at run time. After remounting with a compress= option, later writes will be done using the newly selected algorithm. The compress= option is filesystem-wide, you cannot currently use different compress= options for different subvolumes. Mounting a subvolume with a different compress= option will change the compression algorithm for all mounted subvolumes on that filesystem. (Note that I wouldn't recommend zlib on most systems as a / filesystem - it's slow to decompress compared to lzo, so it will cause slower boots if your disk is reasonably fast.) -- Calvin Walton calvin.wal...@kepstin.ca -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Wed, Apr 23, 2014 at 10:37:44PM +0300, Пламен Петров wrote: So now, we're kind of guessing. To save us all time, could you capture a serial console boot from the running 3.13 and then the failing 3.14. Well, for the details - see for example here: https://bugzilla.kernel.org/attachment.cgi?id=133111 how does a 3.14.1 built the way described earlier fails. Thanks, that helps. Except, now I'm perplexed. It indeed shows btrfs loaded and your block device being detected. However it does not show a btrfs mount error. I haven't had to debug this in a while, but I'm wondering if you're having a block device problem. It may help to look up what error -38 translates into for that mount error. And for that matter - see the whole bugzilla bug entry - I went on and bisected this, using the linux-stable git tree, and after that landed me on the commit that introduces some shiny new btrfs feature for 3.14 - I decided my git bisection has gone wrong. And because I reported it on April 17-th and since then there has been no activity on the bugzilla entry besides me updating it - I posted my problem here, for more eyes to see. One easier way to debug this would be to create an initrd for 3.13 and 3.14. Make sure it works with 3.13 first, then boot 3.14 and see what error you get. You'll get an error from mount(8) and not the kernel and you'll be dropped to a shell, giving you more debug options. My guess is that if you diff both you'll likely find what went wrong, but if not you can post here. See the result of diff config-v3.14.1-mix64 config-v3.13.11-mix64 in the attached file. diff -u is your friend ;) but diff looks reasonable. As for the btrfs FS format, it has not changed in a way that new kernels wouldn't be able to mount an FS from a year ago or more. Good to know! Thanks! Of course, that doesn't mean you didn't find a bug saying otherwise. If you try from an initrd, it'll make it easier to debug. You don't have to build a new kernel or make btrfs a module, just mounting a working initrd and then trying this again with userland tools will help debug. (alternatively, rescue boot media with your kernel would work too, but that's likely more work to build than an initrd) Actually, you could also use your VM setup to boot another linux image running ext4 as root with your new kernel, setup your existing drive as sdb, and try to mount it then. Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Thu, Apr 24, 2014 at 12:54:57AM +0300, Пламен Петров wrote:
It may help to look up what error -38 translates into for that mount error.
My searches so far failed to return anything useful to solving this problem.
Yeah, I searched before you :) this would require reading the kernel source
to track down -38.
(not hard, I just didn't do it)(
The initrd way will require some reading up on my part - so will have to wait
for tomorrow.
On debian, I just have to run this:
update-initramfs -v -c -k `grep linux-source debian/changelog | awk '{ print
$1 }' | sed s/linux-source-//`
Then see /etc/initramfs-tools/initramfs.conf
but the defaults should work
Running update-grub2 should give you something like this:
echo'Loading Linux 3.12.7-amd64-i915-preempt-20131107 ...'
linux /vmlinuz-3.12.7-amd64-i915-preempt-20131107
root=/dev/mapper/cryptroot ro rootflags=subvol=root
cryptopts=source=/dev/sda4,keyscript=/sbin/cryptgetpw,discard
usbcore.autosuspend=1 pcie_aspm=force i915.i915_enable_rc6 =7
i915.i915_enable_fbc=1 i915.semaphores=1 i915.lvds_downclock=1 acpi_osi=Linux
acpi_backlight=vendor
echo'Loading initial ramdisk ...'
initrd /initrd.img-3.12.7-amd64-i915-preempt-20131107
You don't have to build a
new kernel or make btrfs a module, just mounting a working initrd and then
trying this again with userland tools will help debug.
(alternatively, rescue boot media with your kernel would work too, but
that's
likely more work to build than an initrd)
Not more work - just replaced the kernel on the setup/rescue media with mine
and the result is the same - see attached image file.
That's not what I meant, I meant a rescue media that boots another
filesystem than you root filesystem.
Then from there, you can use normal userland tools to manually mount your
root filesystem and/or see errors.
Marc
--
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems
what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Can anyone boot a system using btrfs root with linux 3.14 or newer?
-Original Message-
From: Marc MERLIN [mailto:m...@merlins.org]
Sent: Thursday, April 24, 2014 1:03 AM
To: Пламен Петров
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Can anyone boot a system using btrfs root with linux 3.14 or
newer?
On Thu, Apr 24, 2014 at 12:54:57AM +0300, Пламен Петров wrote:
It may help to look up what error -38 translates into for that mount
error.
My searches so far failed to return anything useful to solving this problem.
Yeah, I searched before you :) this would require reading the kernel source
to track down -38.
(not hard, I just didn't do it)(
The initrd way will require some reading up on my part - so will have to
wait
for tomorrow.
On debian, I just have to run this:
update-initramfs -v -c -k `grep linux-source debian/changelog | awk '{ print
$1 }' | sed s/linux-source-//`
Well, I'm using a source based distro - ever heard of CRUX - http://crux.nu/ ?
Then see /etc/initramfs-tools/initramfs.conf
but the defaults should work
Running update-grub2 should give you something like this:
echo'Loading Linux 3.12.7-amd64-i915-preempt-20131107 ...'
linux /vmlinuz-3.12.7-amd64-i915-preempt-20131107
root=/dev/mapper/cryptroot ro rootflags=subvol=root
cryptopts=source=/dev/sda4,keyscript=/sbin/cryptgetpw,discard
usbcore.autosuspend=1 pcie_aspm=force i915.i915_enable_rc6 =7
i915.i915_enable_fbc=1 i915.semaphores=1 i915.lvds_downclock=1
acpi_osi=Linux acpi_backlight=vendor
echo'Loading initial ramdisk ...'
initrd /initrd.img-3.12.7-amd64-i915-preempt-20131107
Never got to understand GRUB2 inner workings... so I keep to what works for me
- GRUB Legacy here!
You don't have to build a
new kernel or make btrfs a module, just mounting a working initrd
and then trying this again with userland tools will help debug.
(alternatively, rescue boot media with your kernel would work too,
but that's likely more work to build than an initrd)
Not more work - just replaced the kernel on the setup/rescue media with
mine and the result is the same - see attached image file.
That's not what I meant, I meant a rescue media that boots another
filesystem than you root filesystem.
Then from there, you can use normal userland tools to manually mount your
root filesystem and/or see errors.
Marc
--
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems
what McDonalds is to gourmet
cooking Home page:
http://marc.merlins.org/
I'm trying to boot into the rescue media's environment with my own kernel, but
it fails now that my monolithic kernel has no support for initrd whatsoever (or
something else missing)!
I guess I’ll leave this testing for tomorrow - getting tired and sleepy now...
Thanks!
-
Plamen Petrov
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Apr 23, 2014, at 1:06 PM, Kai Krakow hurikhan77+bt...@gmail.com wrote: Пламен Петров pla...@petrovi.no-ip.info schrieb: I'm going with the module suggestion from Marc, too. /dev/sda2 / btrfs relatime,compress=zlib 0 0 This line looks kinda useless to me. The compress=zlib option won't be applied at boot and cannot be changed at runtime because AFAIR btrfs does not allow that yet. So long as no other part of the same volume (including a subvolume) has been mounted, an ro rootfs remounted upon consultation of fstab will result in the fstab mount options being applied to remount. There might be a handful of btrfs options that don't work with remount, but compress isn't one of them. At least on Fedora since the dawn of btrfs, it's been possible to specify compress in fstab and its honored when rootfs is remounted rw. Also, relatime is default. So the cleaned up mount option for fstab for the above would be merely compress (zlib is the default). Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Wed, Apr 23, 2014 at 03:03:12PM -0700, Marc MERLIN wrote: On Thu, Apr 24, 2014 at 12:54:57AM +0300, Пламен Петров wrote: It may help to look up what error -38 translates into for that mount error. My searches so far failed to return anything useful to solving this problem. Yeah, I searched before you :) this would require reading the kernel source to track down -38. (not hard, I just didn't do it)( #define ENOSYS 38 /* Function not implemented */ Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Computer Science is not about computers, any more than --- astronomy is about telescopes. signature.asc Description: Digital signature
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
The screen shot provided makes it clear that one of the following kernel parameters is incorrect: root=/dev/mapper/cryptroot rootflags=subvol=root So either the dmcrypt volume hasn't been opened, thus isn't available; or rootfs isn't on a subvolume named root found at the top level of the file system. So I'd say this isn't a btrfs problem, rather it's due to some earlier misconfiguration that's preventing rootfs from being mounted. Chris Murphy-- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Wed, Apr 23, 2014 at 04:40:33PM -0600, Chris Murphy wrote: The screen shot provided makes it clear that one of the following kernel parameters is incorrect: root=/dev/mapper/cryptroot rootflags=subvol=root So either the dmcrypt volume hasn't been opened, thus isn't available; or rootfs isn't on a subvolume named root found at the top level of the file system. So I'd say this isn't a btrfs problem, rather it's due to some earlier misconfiguration that's preventing rootfs from being mounted. You'll need an initrd to run cryptsetup (or whatever) to collect a passphrase and decrypt the volume before you try to mount it. This sounds like a case for an initrd again. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Computer Science is not about computers, any more than --- astronomy is about telescopes. signature.asc Description: Digital signature
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Wed, Apr 23, 2014 at 11:43:03PM +0100, Hugo Mills wrote: On Wed, Apr 23, 2014 at 04:40:33PM -0600, Chris Murphy wrote: The screen shot provided makes it clear that one of the following kernel parameters is incorrect: root=/dev/mapper/cryptroot rootflags=subvol=root So either the dmcrypt volume hasn't been opened, thus isn't available; or rootfs isn't on a subvolume named root found at the top level of the file system. So I'd say this isn't a btrfs problem, rather it's due to some earlier misconfiguration that's preventing rootfs from being mounted. You'll need an initrd to run cryptsetup (or whatever) to collect a passphrase and decrypt the volume before you try to mount it. This sounds like a case for an initrd again. I think you are confused, that's my config I pasted as an example. He does not use dmcrypt in his example. Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ signature.asc Description: Digital signature
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
On Wed, Apr 23, 2014 at 03:50:18PM -0700, Marc MERLIN wrote: On Wed, Apr 23, 2014 at 11:43:03PM +0100, Hugo Mills wrote: On Wed, Apr 23, 2014 at 04:40:33PM -0600, Chris Murphy wrote: The screen shot provided makes it clear that one of the following kernel parameters is incorrect: root=/dev/mapper/cryptroot rootflags=subvol=root So either the dmcrypt volume hasn't been opened, thus isn't available; or rootfs isn't on a subvolume named root found at the top level of the file system. So I'd say this isn't a btrfs problem, rather it's due to some earlier misconfiguration that's preventing rootfs from being mounted. You'll need an initrd to run cryptsetup (or whatever) to collect a passphrase and decrypt the volume before you try to mount it. This sounds like a case for an initrd again. I think you are confused, that's my config I pasted as an example. He does not use dmcrypt in his example. Ah, OK. Never mind, then. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Computer Science is not about computers, any more than --- astronomy is about telescopes. signature.asc Description: Digital signature
Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
It sounds like either a grub.cfg misconfiguration, or a failure to correctly build the initrd/initramfs. So I'd post the grub.cfg kernel command line for the boot entry that works and the entry that fails, for comparison. And then also check and see if whatever utility builds your initrd has been upgraded along with your kernel, maybe there's a bug/regression. Chris Murphy-- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
