Btrfs devel - Oct 2013 - 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Oct 14, 2013, at 1:21 PM, Chris Murphy <lists@colorremedies.com> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Oct 14, 2013 at 02:23:58PM -0600, Chris Murphy
wrote:
> 
> On Oct 14, 2013, at 1:21 PM, Chris Murphy <lists@colorremedies.com>
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Oct 14, 2013, at 2:29 PM, Josef Bacik <jbacik@fusionio.com> wrote:
> On Mon, Oct 14, 2013 at 02:23:58PM -0600, Chris Murphy wrote:
>> 
>> On Oct 14, 2013, at 1:21 PM, Chris Murphy
<lists@colorremedies.com> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html