Bug 1018930 - boot fails with initramfs created by dracut -N (--no-hostonly)
boot fails with initramfs created by dracut -N (--no-hostonly)
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: dracut-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-14 13:46 EDT by Andrew J. Schorr
Modified: 2015-02-17 12:40 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 12:40:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sosreport.txt (70.59 KB, text/plain)
2013-10-14 13:46 EDT, Andrew J. Schorr
no flags Details

  None (edit)
Description Andrew J. Schorr 2013-10-14 13:46:32 EDT
Created attachment 812136 [details]
sosreport.txt

Description of problem: I cannot boot successfully with an initramfs created
using "dracut -N" for --no-hostonly mode.  I came across this problem when
installing Fedora 19 into a chroot hosted inside Fedora 14.  In that environment,
when I run chroot, I get these messages:

dracut -f /boot/initramfs-3.10.11-200.fc19.x86_64.img 3.10.11-200.fc19.x86_64
W: Turning off host-only mode: '/run' is not mounted!
W: Turning off host-only mode: udev database not found!

I had to boot into a Fedora 19 rescue shell in order to run dracut again
to get a working initramfs (in usual hostonly mode).

I subsequently tested that running "dracut -N" in a working Fedora 19 system
does not generate a bootable initramfs.


Version-Release number of selected component (if applicable):
dracut-029-2.fc19.x86_64


How reproducible:
On a Fedora 19 system, run "dracut -N /boot/initramfs.nohostonly `uname -r`"
and then try to boot using that initramfs.


Steps to Reproduce:
1. Run "dracut -N /boot/initramfs.nohostonly `uname -r`"
2. Edit grub.cfg or extlinux.conf to add an entry using the new initramfs
3.

Actual results: System should boot


Expected results: It does not boot.


Additional info:
I am using MD raid 1 on this system:

sh-4.2# cat /proc/mdstat
Personalities : [raid1] 
md125 : active raid1 sdb3[1] sda3[0]
      150872384 blocks super 1.2 [2/2] [UU]
      
md126 : active (auto-read-only) raid1 sdb2[1] sda2[0]
      4191168 blocks super 1.2 [2/2] [UU]
      
md127 : active raid1 sdb1[1] sda1[0]
      1049536 blocks super 1.0 [2/2] [UU]
      
unused devices: <none>
sh-4.2# pvs
  PV         VG     Fmt  Attr PSize   PFree 
  /dev/md125 vg_sys lvm2 a--  143.88g 95.25g
sh-4.2# lvs
  LV         VG     Attr      LSize  Pool Origin Data%  Move Log Copy%  Convert
  extra_disk vg_sys -wi-ao--- 23.38g                                           
  root       vg_sys -wi-ao---  1.62g                                           
  usr        vg_sys -wi-ao--- 22.00g                                           
  var        vg_sys -wi-ao---  1.62g                                           
sh-4.2# cat /etc/fstab
UUID=a46c4049-d7cd-4f65-ae66-f127edb2ab6c /                        ext4     defaults,noatime      1 1
UUID=818abaaa-3e66-4df1-bb91-cb259947b17f /boot                    ext4     defaults,noatime      1 2
UUID=bdda7f59-d3fb-4ad6-b25c-5f496bdad07c /extra_disk              xfs      defaults,nobarrier    1 2
UUID=aafa645a-2608-46ae-ab0a-2336f503ac08 /usr                     ext4     defaults,noatime      1 2
UUID=115c3cad-2f9b-4722-82fe-50ba69192a7b /var                     ext4     defaults              1 2
UUID=38240737-c431-4e2d-b1b9-55cf50c4f930 swap                     swap     defaults              0 0

The /boot partition is on /dev/md127, and the other partitions are logical
volumes.
Comment 1 Harald Hoyer 2013-10-15 04:37:19 EDT
(In reply to Andrew J. Schorr from comment #0)
> Description of problem: I cannot boot successfully with an initramfs created
> using "dracut -N" for --no-hostonly mode. 

In "no-hostonly"/generic mode, you have to tell dracut how to assemble your devices.

You can either add "rd.auto=1" to the kernel command line and dracut tries to assemble everything it finds, or

you can specify exactly which devices dracut should assemble.
In your case you would have to add to the kernel command line:
"rd.md.uuid=<MD_UUID_1> rd.md.uuid=<MD_UUID_2> rd.lvm.vg=vg_sys"

With MD_UUID_1 MD_UUID_2 being the MD UUIDs of your raids:

# /sbin/mdadm --examine --export /dev/md125 | grep MD_UUID
# /sbin/mdadm --examine --export /dev/md126 | grep MD_UUID
Comment 2 Andrew J. Schorr 2013-10-15 13:52:43 EDT
Thanks.  That is very helpful.  I tested one machine, and adding "rd.auto" to
the kernel command line seems to fix the problem.

This leaves me with 2 questions:

1. Is there any reason one would not want to include rd.auto on the kernel
command line?

2. Wouldn't it make sense for the dracut man page to mention that rd.auto
is required when the -N option is used?   Or is this required only because
I am using MD arrays?  The warning messages from dracut also do not
give a proper sense of impending doom:

W: Turning off host-only mode: '/run' is not mounted!
W: Turning off host-only mode: udev database not found!

It would be nice if they warned that the system might not be bootable
unless rd.auto is passed to the kernel.

Thanks,
Andy
Comment 3 Harald Hoyer 2013-10-16 04:31:19 EDT
(In reply to Andrew J. Schorr from comment #2)
> Thanks.  That is very helpful.  I tested one machine, and adding "rd.auto" to
> the kernel command line seems to fix the problem.
> 
> This leaves me with 2 questions:
> 
> 1. Is there any reason one would not want to include rd.auto on the kernel
> command line?

yes, rd.auto only works for very simple setups. For machines with multiple raids, lvms, etc. you don't want to assemble "everything", because you might actually not need it. And assembling mostly modifies timestamps, etc. You only want to assemble as much as you need to get to the root device.

> 
> 2. Wouldn't it make sense for the dracut man page to mention that rd.auto
> is required when the -N option is used?   Or is this required only because
> I am using MD arrays?  The warning messages from dracut also do not
> give a proper sense of impending doom:
> 
> W: Turning off host-only mode: '/run' is not mounted!
> W: Turning off host-only mode: udev database not found!

Well, if you run in a chroot, make sure you present a proper chroot environment with /run /dev /sys /proc mounted (maybe bind mounted from the outside).

> 
> It would be nice if they warned that the system might not be bootable
> unless rd.auto is passed to the kernel.

dracut does not know the kernel command line you will be using and rd.auto is only the last resort, if you don't know your setup.
Comment 4 Andrew J. Schorr 2013-10-16 10:27:33 EDT
Thanks for the clarifications.

I wish the man page made it clear that non-host-only mode may not boot
unless the appropriate kernel parameters are provided.  There is currently
a big warning about the default (-H) mode, but no warnings about -N.  If you
were to read the man page, you would conclude that -N is safer than -H, whereas
the opposite is the case.

It would also be nice if the runtime warnings were to indicate that special
kernel arguments may be required for booting.

Thanks,
Andy
Comment 5 Fedora End Of Life 2015-01-09 15:15:03 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 6 Fedora End Of Life 2015-02-17 12:40:46 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.