install f22 into btrfs subvolume won't boot

[Neal Becker]

I tried it.  It was not easy to figure out how to use anaconda gui to setup 
install into a subvolume - but I got it done.  I now have 3 subvolumes:

sudo btrfs subvolume list /
[sudo] password for nbecker:
ID 256 gen 1818627 top level 5 path home
ID 259 gen 1818478 top level 5 path root
ID 487 gen 1818625 top level 5 path root00

But if I try to boot with 1st grub entry, I get:
dracut-initqueue warning could not boot
starting dracut emergency shell

If I try to boot off the grub entry labeled 'rescue', it boots OK.

dracut says something about fixing initramfs.

-- 
Those who fail to understand recursion are doomed to repeat it

[Neal Becker]

Neal Becker wrote:

>  I tried it.  It was not easy to figure out how to use anaconda gui
> to
>  setup
>  install into a subvolume - but I got it done.  I now have 3 subvolumes:
>  
>  sudo btrfs subvolume list /
>  [sudo] password for nbecker:
>  ID 256 gen 1818627 top level 5 path home
>  ID 259 gen 1818478 top level 5 path root
>  ID 487 gen 1818625 top level 5 path root00
>  
>  But if I try to boot with 1st grub entry, I get:
>  dracut-initqueue warning could not boot
>  starting dracut emergency shell
>  
>  If I try to boot off the grub entry labeled 'rescue', it boots OK.
>  
>  dracut says something about fixing initramfs.
>   
the rescue, which DOES work, says:

	linux16 /vmlinuz-0-rescue-39e9e51995d040a88bf6f0ae625ead80 
root=UUID=7246327b-1905-4fe2-9b6b-b9376017264f ro rootflags=subvol=root00 
rhgb quiet


the default, which does NOT work, says:
	linux16 /vmlinuz-4.0.4-301.fc22.x86_64 root=/dev/sdb8 ro 
rootflags=subvol=root00 rhgb quiet LANG=en_US.UTF-8


I did see an error about not finding /dev/sdb8 - I think that's the problem.

/etc/fstab says:
UUID=7246327b-1905-4fe2-9b6b-b9376017264f /                       btrfs   
subvolid=5,subvol=root00 0 0
UUID=2c04be93-34c1-4016-ba41-60fd9fd90616 /boot                   ext4    
defaults        1 2
UUID=7246327b-1905-4fe2-9b6b-b9376017264f /home                   btrfs   
subvol=home     0 0



-- 
Those who fail to understand recursion are doomed to repeat it

[Tim]

Allegedly, on or about 28 May 2015, Neal Becker sent:
>  the rescue, which DOES work, says:
>  
>          linux16 /vmlinuz-0-rescue-39e9e51995d040a88bf6f0ae625ead80 
>  root=UUID=7246327b-1905-4fe2-9b6b-b9376017264f ro
>  rootflags=subvol=root00 
>  rhgb quiet
>  
>  
>  the default, which does NOT work, says:
>          linux16 /vmlinuz-4.0.4-301.fc22.x86_64 root=/dev/sdb8 ro 
>  rootflags=subvol=root00 rhgb quiet LANG=en_US.UTF-8
>  
>  
>  I did see an error about not finding /dev/sdb8 - I think that's the
>  problem.  
I had the same problem with prior release(s).  When the computer booted
from the install media, it was sda and the harddrive was sdb.
Post-installation, the computer booted from the harddrive, and called it
sda, but all the written configs point to sdb.

Change the grub config to either point "root=" to sda, or do the more
reliable thing, and use the same UUID code that the working rescue entry
used.

It's a particularly dumb fault to do with boot environments (it's well
known that some BIOSs rearrange the order of devices, depending on what
was booted, or which devices responded first), and those who coded the
installer ought to know better than to use sdb, when there's a reliable
UUID written to the hard drive.

On a related note, since someone had the foresight to make a "rescue"
entry, perhaps someone might, also, have thought to include a "find the
right partition" set of entries.  So when booting fails, a fallback is a
menu with the results from something that probes the partitions, then
lists all the likely bootable candidates for you, and you can pick the
right one.  That'd get you into a working system, without having to try
and figure out the grub command line with inadequate information, and a
horrible environment to work in.

-- 
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64

All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.

George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.

ZNQR LBH YBBX

[Neal Becker]

Tim wrote:

>  Allegedly, on or about 28 May 2015, Neal Becker sent:
> > the rescue, which DOES work, says:
> > 
> >         linux16 /vmlinuz-0-rescue-39e9e51995d040a88bf6f0ae625ead80
> > root=UUID=7246327b-1905-4fe2-9b6b-b9376017264f ro
> > rootflags=subvol=root00
> > rhgb quiet
> > 
> > 
> > the default, which does NOT work, says:
> >         linux16 /vmlinuz-4.0.4-301.fc22.x86_64 root=/dev/sdb8 ro
> > rootflags=subvol=root00 rhgb quiet LANG=en_US.UTF-8
> > 
> > 
> > I did see an error about not finding /dev/sdb8 - I think that's the
> > problem.
>  
>  I had the same problem with prior release(s).  When the computer booted
>  from the install media, it was sda and the harddrive was sdb.
>  Post-installation, the computer booted from the harddrive, and called it
>  sda, but all the written configs point to sdb.
>  
>  Change the grub config to either point "root=" to sda, or do the more
>  reliable thing, and use the same UUID code that the working rescue entry
>  used.
>  
>  It's a particularly dumb fault to do with boot environments (it's well
>  known that some BIOSs rearrange the order of devices, depending on what
>  was booted, or which devices responded first), and those who coded the
>  installer ought to know better than to use sdb, when there's a reliable
>  UUID written to the hard drive.
>  
>  On a related note, since someone had the foresight to make a "rescue"
>  entry, perhaps someone might, also, have thought to include a "find the
>  right partition" set of entries.  So when booting fails, a fallback is a
>  menu with the results from something that probes the partitions, then
>  lists all the likely bootable candidates for you, and you can pick the
>  right one.  That'd get you into a working system, without having to try
>  and figure out the grub command line with inadequate information, and a
>  horrible environment to work in.
>   
Just to confirm, I did edit the grub.cfg file and changed root= to point to 
the same UUID that worked for the 'rescue' entry, and then it did boot.

There are lots of problems here.  Why did anaconda screw up?  Why didn't the 
boot put me into an environment that was more useful to diagnosing and 
fixing the problem?
 

-- 
Those who fail to understand recursion are doomed to repeat it

[Chris Murphy]

On Thu, May 28, 2015 at 1:32 PM, Neal Becker <ndbecker2(a)gmail.com&gt; wrote:
>  Neal Becker wrote: 
>  the rescue, which DOES work, says:
>
>          linux16 /vmlinuz-0-rescue-39e9e51995d040a88bf6f0ae625ead80
>  root=UUID=7246327b-1905-4fe2-9b6b-b9376017264f ro rootflags=subvol=root00
>  rhgb quiet
>
>
>  the default, which does NOT work, says:
>          linux16 /vmlinuz-4.0.4-301.fc22.x86_64 root=/dev/sdb8 ro
>  rootflags=subvol=root00 rhgb quiet LANG=en_US.UTF-8
>
>
>  I did see an error about not finding /dev/sdb8 - I think that's the problem. 
There's a GRUB related bug where for some reason in certain instances
root=/dev/ is used instead of root=UUID=<uuid> and I'm spacing out why
this happens. But the usual fix is to get it to boot manually somehow,
and then recreate the grub.cfg from scratch with grub2-mkconfig - and
invariably that one will have all entries  using UUID rather than
/dev/

-- 
Chris Murphy