Bug 841696 - RFE include custom rules for fast bootup support
RFE include custom rules for fast bootup support
Status: NEW
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-19 17:49 EDT by Jóhann B. Guðmundsson
Modified: 2017-02-21 11:25 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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)

  None (edit)
Description Jóhann B. Guðmundsson 2012-07-19 17:49:31 EDT
Description of problem:

See https://github.com/petersenna/Fedora17-fastboot/tree/master/etc/grub.d

Unfortunately users will have to have a unit like this since we still depend on the presence of /dev/root in grubby in the 21 century...

#### dev-root.service ####

[Unit]
Description=Dev Root Hack
ConditionPathExists=!/dev/root

[Service]
Type=oneshot
ExecStart=/bin/ln -s /dev/sdaX /dev/root

[Install]
WantedBy=multi-user.target


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Mads Kiilerich 2012-07-29 18:55:50 EDT
(In reply to comment #0)
> Unfortunately users will have to have a unit like this since we still depend
> on the presence of /dev/root in grubby in the 21 century...

Why should we add a hack to grub2 to workaround what you claim is a bug/missing feature in grubby? Isn't it obvious that it should be fixed in grubby if it is worth fixing?


If you think it belongs in grub2 anyway then I recommend describing your case a lot better.
Comment 2 Jóhann B. Guðmundsson 2012-07-29 23:54:05 EDT
(In reply to comment #1)
> (In reply to comment #0)
> > Unfortunately users will have to have a unit like this since we still depend
> > on the presence of /dev/root in grubby in the 21 century...
> 
> Why should we add a hack to grub2 to workaround what you claim is a
> bug/missing feature in grubby? Isn't it obvious that it should be fixed in
> grubby if it is worth fixing?
> 
> 
> If you think it belongs in grub2 anyway then I recommend describing your
> case a lot better.


The custom rule that is in the github link I provided is needed to generate initramfs less entries in grub2. 

If you got a cleaner way to do that than that I'm all ears.

The unit file I created there in comment one does the same as if you would put
"ln -s /dev/sda$n /dev/root" in rc.local which is needed if users want to continue to be able cleanly update the kernel in the distribution which is nothing that Peter is not aware of. 

You can ask him why he has not fixed it yet granted that his scheduale is open for end user report...
Comment 3 Mads Kiilerich 2012-07-30 08:01:08 EDT
You haven't described what the real problem is and I thus don't have any idea which ways it can be solved.

This seems very similar to what you reported in Bug 737370. In what way is this different ... and what is the status on that issue?
Comment 4 Jóhann B. Guðmundsson 2012-07-30 10:28:24 EDT
So the real problem to be solved is for users to be able boot the kernel from an ext4 partition without initramfs in as user friendly manner as possible since desktop end users are doing this now in the masses to decrease their bootup time. ( bootup goes down to ca <10s on rotating media, <4s on SSD when booting directly from ext4 and disable service associated with lvm)

To do so we are dealing with two problems.

1. Kernel updates
 a) you cant update the kernel without the presence of /dev/root because if you do so generate the bootup menu will fail leaving users with either non working menu entry or an working menu entry without the kernel that got updated/installed.

 b) Kernel updates aren't using grub2-mkconfig to generate the grub menu leaving users that customize grub menu without their customization when the kernel gets updated.

2. Users need to either hack 10_linux script to not generate the initramfs lines or create their own custom script.

This RFE is about 2 which contains an workable grub2 script that will generate two menu entries one labeled "Fast without initrd the other one Fedora Linux" which is just our regular menu. 

Arguably that custom script should be hookup to an trigger that users will need to set to true in "/etc/default/grub" something like GRUB_NOINITRAMFS=true. 

The current steps to boot directly of ext4 are these.

1. Unhash lvm in anaconda's default partition layout
2. Add "ln -s /dev/sda$n /dev/root" to rc.local or use a type oneshot unit to workaround that broken update behavior
3. update/install kernel(s) 
4. run grub2-mkconfig -o /boot/grub2/grub.cfg after each kernel update
Comment 5 Mads Kiilerich 2012-07-30 10:55:47 EDT
(In reply to comment #4)

Thank you for the clarification.

> 1. Kernel updates
>  a) you cant update the kernel without the presence of /dev/root because if
> you do so generate the bootup menu will fail leaving users with either non
> working menu entry or an working menu entry without the kernel that got
> updated/installed.

You say 'kernel update' so I assume you are referring to a grubby bug. Which number?

> 2. Users need to either hack 10_linux script to not generate the initramfs
> lines or create their own custom script.

You mention a grub mkconfig scriptlet ... does that imply that grub2-mkconfig doesn't work for your case at all without this change? That would be a bug that probably should be fixed, not worked around. Please follow up on Bug 737370 first.
Comment 6 Jóhann B. Guðmundsson 2012-07-30 11:51:31 EDT
(In reply to comment #5)
> (In reply to comment #4)
> 
> Thank you for the clarification.
> 
> > 1. Kernel updates
> >  a) you cant update the kernel without the presence of /dev/root because if
> > you do so generate the bootup menu will fail leaving users with either non
> > working menu entry or an working menu entry without the kernel that got
> > updated/installed.
> 
> You say 'kernel update' so I assume you are referring to a grubby bug. Which
> number?

There are probably several duplicate for this issues against grubby. The keyword being "grubby fatal error: unable to find a suitable template". 

Bug 833011 is one such report where you can see the reporter is using "root=/dev/sda1 rootfstype=ext4" 

> 
> > 2. Users need to either hack 10_linux script to not generate the initramfs
> > lines or create their own custom script.
> 
> You mention a grub mkconfig scriptlet ... does that imply that
> grub2-mkconfig doesn't work for your case at all without this change? That
> would be a bug that probably should be fixed, not worked around. Please
> follow up on Bug 737370 first.

This is irrelevant to Bug 737370 and as far as I know you have already fixed "/sbin/grub2-probe: error: cannot stat `/dev/root'" which is what that report is originally about. 

This report is an RFE about adding the custom grub2 script from the github url  to grub2 which adds to grub2 the ability to generate configuration entry's without the initramfs part but we probably should hookup it up via configuration parameter which users need to "enable". 

Given that you seem to have a hard time understanding what this RFE report is about have you even looked at the custom grub script in the github url provide in comment 1?
Comment 7 Mads Kiilerich 2012-07-30 13:10:03 EDT
(In reply to comment #6)
> There are probably several duplicate for this issues against grubby. The
> keyword being "grubby fatal error: unable to find a suitable template". 
> 
> Bug 833011 is one such report where you can see the reporter is using
> "root=/dev/sda1 rootfstype=ext4" 

That issue did not have any evidence of being related to not using an initrd.

Please point at a decent report of the grubby issue.

> > > 2. Users need to either hack 10_linux script to not generate the initramfs
> > > lines or create their own custom script.
> > 
> > You mention a grub mkconfig scriptlet ... does that imply that
> > grub2-mkconfig doesn't work for your case at all without this change? That
> > would be a bug that probably should be fixed, not worked around. Please
> > follow up on Bug 737370 first.
> 
> This is irrelevant to Bug 737370 and as far as I know you have already fixed
> "/sbin/grub2-probe: error: cannot stat `/dev/root'" which is what that
> report is originally about. 

I find it very relevant to know what the baseline is before we consider adding features on top of that.

> This report is an RFE about adding the custom grub2 script from the github
> url  to grub2 which adds to grub2 the ability to generate configuration
> entry's without the initramfs part but we probably should hookup it up via
> configuration parameter which users need to "enable". 
> 
> Given that you seem to have a hard time understanding what this RFE report
> is about have you even looked at the custom grub script in the github url
> provide in comment 1?

I have looked enough to doubt very much that it is a solution that will be accepted upstream or in Fedora. But I can't suggest a better solution before you have described the problem.

AFAICS something like this could solve a part of the problem:

--- /etc/grub.d/10_linux.org	2012-07-30 18:30:04.829132364 +0200
+++ /etc/grub.d/10_linux	2012-07-30 18:52:17.948944921 +0200
@@ -218,6 +218,9 @@
       initramfs=`grep CONFIG_INITRAMFS_SOURCE= "${config}" | cut -f2 -d= | tr -d \"`
   fi
 
+  if [ "x${GRUB_DISABLE_INITRD}" != "xtrue" ]; then
+    initrd=
+  fi
   if test -n "${initrd}" ; then
     gettext_printf "Found initrd image: %s\n" "${dirname}/${initrd}" >&2
   elif test -z "${initramfs}" ; then


The kernel scriptlets explicitly asks grubby to create an initrd. Running without initrd is thus a second class citizen in Fedora - whether you like it or not. But it is possible that an alternative solution could be an /etc/sysconfig/kernel option for disabling the actual initrd creation.
Comment 8 Jóhann B. Guðmundsson 2012-07-30 14:45:15 EDT
(In reply to comment #7)
> (In reply to comment #6)
> > There are probably several duplicate for this issues against grubby. The
> > keyword being "grubby fatal error: unable to find a suitable template". 
> > 
> > Bug 833011 is one such report where you can see the reporter is using
> > "root=/dev/sda1 rootfstype=ext4" 
> 
> That issue did not have any evidence of being related to not using an initrd.

I disagree the kernel command line parameter which I mention there above and is mentioned there in the report is where an user has set up is systemd to boot without initramfs. 

> 
> Please point at a decent report of the grubby issue.

Or you can just search for an report yourself that you deem good enough for you to look into. 

> > > > 2. Users need to either hack 10_linux script to not generate the initramfs
> > > > lines or create their own custom script.
> > > 
> > > You mention a grub mkconfig scriptlet ... does that imply that
> > > grub2-mkconfig doesn't work for your case at all without this change? That
> > > would be a bug that probably should be fixed, not worked around. Please
> > > follow up on Bug 737370 first.
> > 
> > This is irrelevant to Bug 737370 and as far as I know you have already fixed
> > "/sbin/grub2-probe: error: cannot stat `/dev/root'" which is what that
> > report is originally about. 
> 
> I find it very relevant to know what the baseline is before we consider
> adding features on top of that.
> 
> > This report is an RFE about adding the custom grub2 script from the github
> > url  to grub2 which adds to grub2 the ability to generate configuration
> > entry's without the initramfs part but we probably should hookup it up via
> > configuration parameter which users need to "enable". 
> > 
> > Given that you seem to have a hard time understanding what this RFE report
> > is about have you even looked at the custom grub script in the github url
> > provide in comment 1?
> 
> I have looked enough to doubt very much that it is a solution that will be
> accepted upstream or in Fedora. But I can't suggest a better solution before
> you have described the problem.
> 
> AFAICS something like this could solve a part of the problem:
> 
> --- /etc/grub.d/10_linux.org	2012-07-30 18:30:04.829132364 +0200
> +++ /etc/grub.d/10_linux	2012-07-30 18:52:17.948944921 +0200
> @@ -218,6 +218,9 @@
>        initramfs=`grep CONFIG_INITRAMFS_SOURCE= "${config}" | cut -f2 -d= |
> tr -d \"`
>    fi
>  
> +  if [ "x${GRUB_DISABLE_INITRD}" != "xtrue" ]; then
> +    initrd=
> +  fi
>    if test -n "${initrd}" ; then
>      gettext_printf "Found initrd image: %s\n" "${dirname}/${initrd}" >&2
>    elif test -z "${initramfs}" ; then
> 

Yes this might work basically what we want here is the ability to *not* generate initrd	/initramfs line in grub.cfg for every kernel

> The kernel scriptlets explicitly asks grubby to create an initrd. Running
> without initrd is thus a second class citizen in Fedora - whether you like
> it or not.

I consider this an bug in grubby not a "second class" citizen in Fedora if it was, then the kernel community needs to better explain why supported upstream kernel options aren't supported downstream with us as well as provides with an list of what is supported from upstream kernel community and is not so fourth and so one which I'm pretty sure they dont want to do. 

> But it is possible that an alternative solution could be an
> /etc/sysconfig/kernel option for disabling the actual initrd creation.

would grub2 handle that when generating grub.cfg?

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