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.
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
Allegedly, on or about 28 May 2015, Neal Becker sent:
the rescue, which DOES work, says:
linux16 /vmlinuz-0-rescue-39e9e51995d040a88bf6f0ae625ead80root=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 wrote:
Allegedly, on or about 28 May 2015, Neal Becker sent:
the rescue, which DOES work, says:
linux16 /vmlinuz-0-rescue-39e9e51995d040a88bf6f0ae625ead80root=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?
On Thu, May 28, 2015 at 1:32 PM, Neal Becker ndbecker2@gmail.com wrote:
Neal Becker wrote:
the rescue, which DOES work, says:
linux16 /vmlinuz-0-rescue-39e9e51995d040a88bf6f0ae625ead80root=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 -
Neal Becker -
Tim