Re: boot on btrfs, GRUB usage of subvolume set-default breaks boot
On Oct 14, 2013, at 2:29 PM, Josef Bacik wrote: > On Mon, Oct 14, 2013 at 02:23:58PM -0600, Chris Murphy wrote: >> >> On Oct 14, 2013, at 1:21 PM, Chris Murphy wrote: >> >>> When /boot is on btrfs, and the default subvolume is changed, it makes the >>> system unbootable. The basic configuration is subvolumes: boot, root, home, >>> on one btrfs volume single device. The installer doesn't change the default >>> subvolume, it remains ID 5. >>> >>> If I change the default subvolume and reboot, I get a grub rescue prompt. >>> This means core.img in the MBR gap was found, but >>> /boot/grub/i386-pc/normal.mod could not be found. What's interesting is, at >>> the grub rescue prompt, 'set' returns: >>> >>> prefix=(hd0,msdos1)/boot/grub2 >>> root=hd0,msdos1 >>> >>> This appears to be a full path name, so it should always start from top >>> level regardless of the set-default subvolume, correct? Yet it's behaving >>> relative to the default subvolume. If I use 'ls (hd0,msdos1)' I'm returned >>> the contents of the subvolume I've set as default, which explains why >>> bootability is broken. >> >> Looks like what I'm experiencing is unintended. If a developer or someone >> more knowledgable than me can respond to the questions on grub-devel@ it >> would be very helpful so this can get fixed. >> >> http://lists.gnu.org/archive/html/grub-devel/2013-10/msg00038.html >> > > All grub has to do is read the "default" dir item in the tree_root and then > get > the location out of that dir item and then use that root as the default root. > The kernel does it's own path walk to that root just for dentry sake, but I > imagine grub doesn't have to do that, they can just say "ok this is our root" > and carry on. Thanks. I might be reading the inquiry on grub-devel@ wrong but it seems that's what they're doing now. The idea is that the GRUB prefix path should be immutable, regardless of the user using 'btrfs subvol set-default' to some nested subvolume, so that the system is always bootable. 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: boot on btrfs, GRUB usage of subvolume set-default breaks boot
On Mon, Oct 14, 2013 at 02:23:58PM -0600, Chris Murphy wrote: > > On Oct 14, 2013, at 1:21 PM, Chris Murphy wrote: > > > When /boot is on btrfs, and the default subvolume is changed, it makes the > > system unbootable. The basic configuration is subvolumes: boot, root, home, > > on one btrfs volume single device. The installer doesn't change the default > > subvolume, it remains ID 5. > > > > If I change the default subvolume and reboot, I get a grub rescue prompt. > > This means core.img in the MBR gap was found, but > > /boot/grub/i386-pc/normal.mod could not be found. What's interesting is, at > > the grub rescue prompt, 'set' returns: > > > > prefix=(hd0,msdos1)/boot/grub2 > > root=hd0,msdos1 > > > > This appears to be a full path name, so it should always start from top > > level regardless of the set-default subvolume, correct? Yet it's behaving > > relative to the default subvolume. If I use 'ls (hd0,msdos1)' I'm returned > > the contents of the subvolume I've set as default, which explains why > > bootability is broken. > > Looks like what I'm experiencing is unintended. If a developer or someone > more knowledgable than me can respond to the questions on grub-devel@ it > would be very helpful so this can get fixed. > > http://lists.gnu.org/archive/html/grub-devel/2013-10/msg00038.html > All grub has to do is read the "default" dir item in the tree_root and then get the location out of that dir item and then use that root as the default root. The kernel does it's own path walk to that root just for dentry sake, but I imagine grub doesn't have to do that, they can just say "ok this is our root" and carry on. Thanks, Josef -- 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: boot on btrfs, GRUB usage of subvolume set-default breaks boot
On Oct 14, 2013, at 1:21 PM, Chris Murphy wrote: > When /boot is on btrfs, and the default subvolume is changed, it makes the > system unbootable. The basic configuration is subvolumes: boot, root, home, > on one btrfs volume single device. The installer doesn't change the default > subvolume, it remains ID 5. > > If I change the default subvolume and reboot, I get a grub rescue prompt. > This means core.img in the MBR gap was found, but > /boot/grub/i386-pc/normal.mod could not be found. What's interesting is, at > the grub rescue prompt, 'set' returns: > > prefix=(hd0,msdos1)/boot/grub2 > root=hd0,msdos1 > > This appears to be a full path name, so it should always start from top level > regardless of the set-default subvolume, correct? Yet it's behaving relative > to the default subvolume. If I use 'ls (hd0,msdos1)' I'm returned the > contents of the subvolume I've set as default, which explains why bootability > is broken. Looks like what I'm experiencing is unintended. If a developer or someone more knowledgable than me can respond to the questions on grub-devel@ it would be very helpful so this can get fixed. http://lists.gnu.org/archive/html/grub-devel/2013-10/msg00038.html 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
boot on btrfs, GRUB usage of subvolume set-default breaks boot
When /boot is on btrfs, and the default subvolume is changed, it makes the system unbootable. The basic configuration is subvolumes: boot, root, home, on one btrfs volume single device. The installer doesn't change the default subvolume, it remains ID 5. If I change the default subvolume and reboot, I get a grub rescue prompt. This means core.img in the MBR gap was found, but /boot/grub/i386-pc/normal.mod could not be found. What's interesting is, at the grub rescue prompt, 'set' returns: prefix=(hd0,msdos1)/boot/grub2 root=hd0,msdos1 This appears to be a full path name, so it should always start from top level regardless of the set-default subvolume, correct? Yet it's behaving relative to the default subvolume. If I use 'ls (hd0,msdos1)' I'm returned the contents of the subvolume I've set as default, which explains why bootability is broken. 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
