Giter Club home page Giter Club logo

grubby's People

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar

Forkers

bcl vathpela atodorov nacc kellinm jasonvmiller malmond77 nullr0ute ausil prarit npmccallum jkkm jbastian lkundrak rbisewski jiazhang0 jstodola vj-kumar yuvalturg flygoat likrovo ols3er ipatrykx ondrejbudai frozencemetery zhangrui182 nilusyi praczyns

grubby's Issues

Unable to remove specific arg

For args like console where there can be multiple instances, --remove-args will remove the first instance with matching param name. I'd like to be able to remove the specific instance. Is that possible? Thanks!

# grubby --info $k | grep args | tr ' ' '\n' | grep console
console=tty1
console=ttyS1,115200n"

# grubby --update-kernel $k --remove-args console=ttyS1,115200n

# grubby --info $k | grep args | tr ' ' '\n' | grep console
console=ttyS1,115200n"

BUG: Missing `fclose` in `writeConfig`.

There is no fclose call at the end of writeConfig in the case the file is being written somewhere other than stdout, which can cause rename to get issued before the write call, ultimately resulting in an empty configuration file moved into place in some cases.

Document return values in man page

Knowing return values is very important for automation.
Manual page of grubby(in centos 7.4, v 23.el7) dont mention what are the return values.

Can you please extend the man page?

use fifreeze when modifying configs on rootfs

User with /boot directory on an XFS root fs, experiences an unbootable system (no grub menu, just a grub prompt). The short version of the cause is plymouthd exempts itself from forced kill by systemd at reboot time, which prevents systemd from remounting rootfs ro, which prevents grubby's modifications of grub.cfg (or presumably extlinux.conf or anything else) from being flushed to fs metadata. The modification is only flushed to the journal, which GRUB and other bootloaders cannot read or playback. So the modified grub.cfg is not locatable by the bootloader binary.

Merely mounting and umounting this rootfs is enough to cause journal replay and now the bootloader can see the grubby modified grub.cfg.

XFS developers basically ding the thing modifying the bootloader configuration generator/modifier for not ensuring the file is fully committed to disk. So if grubby itself can't umount, or remount ro, (which seems likely it can't), then it needs to freeze/unfreeze the file system. It's not sufficient to sync() as this only guarantees data and journal entries are on disk it does not guarantee the dirty journal entries are flushed to fs metadata.

Detailed bug and troubleshooting:
https://bugzilla.redhat.com/show_bug.cgi?id=1227736

XFS list, most relevant emails:

"Yup - I've been trying to tell you that these are the exact
guarantees that freezing the fs will provide the bootloader
installer...."
https://www.spinics.net/lists/linux-xfs/msg07051.html
"files were sync()d then the file size updates are still
in the journal which has not been replayed. This is what we've been
saying is the problem all along and that a post-update freeze will
work around."
https://www.spinics.net/lists/linux-xfs/msg07084.html

Code already exists to do this but is restricted to PPC64LE only:
https://github.com/rhinstaller/grubby/blob/master/new-kernel-pkg

# if /boot is a mountpoint, force the meta data on disk
# to by-pass writeback delay.
# PPC64LE-only to deal with Petitboot issues
if [ "$ARCH" = "ppc64le" ]; then
    sync && mountpoint -q /boot && fsfreeze -f /boot && fsfreeze -u /boot
fi

[RFE] Grubby filter --info= --initrd=

I'm inserting a few rescue iso images into my boot environment using MEMDISK from syslinux.

At this time grubby doesn't allow me an easy way to filter by initrd and kernel.

Example

# grubby --info=/boot/memdisk 
index=0
kernel=/boot/memdisk
args="iso"
initrd=/boot/pxefallback.iso
title=CAUTION - REINSTALL SYSTEM
index=4
kernel=/boot/memdisk
initrd=/boot/freedos.img
title=Boot to FreeDOS (for DOS firmware updates)

# grubby --info=/boot/memdisk --initrd=/boot/freedos.img
grubby: kernel path expected

Being able to filter for just the image I'm looking for feels like the intent of --info this RFE would help extend it for my use case.

Btrfs, mounted top level results in bogus initrd prefix, boot failure

The recent Btrfs subvolume change has a problem.

Summary:
rootfs is on subvolume root, and /boot is a directory in it. The correct grub2-mkconfig entries use prefix/root/boot/
But grubby occasionally uses prefix //boot/ only for the initrdefi line, the linuxefi line remains /root/boot/ and the result is on reboot GRUB can't find the initramfs, and boot fails.

The problem happens only when the top level of the file system is mounted. For example:

Does not happen:

[chris@f28s ~]$ cat /proc/mounts | grep btrfs
/dev/sda1 / btrfs rw,seclabel,noatime,compress=zstd,space_cache=v2,subvolid=325,subvol=/root 0 0
/dev/sda1 /var/lib/libvirt/images btrfs rw,seclabel,relatime,compress=zstd,space_cache=v2,subvolid=350,subvol=/libvirtimages 0 0

Does happen:

[chris@f28s ~]$ cat /proc/mounts | grep btrfs
/dev/sda1 / btrfs rw,seclabel,noatime,compress=zstd,space_cache=v2,subvolid=325,subvol=/root 0 0
/dev/sda1 /var/lib/libvirt/images btrfs rw,seclabel,relatime,compress=zstd,space_cache=v2,subvolid=350,subvol=/libvirtimages 0 0
/dev/sda1 /mnt/int btrfs rw,seclabel,relatime,compress=zstd,space_cache=v2,subvolid=5,subvol=/ 0 0

grub2-mkconfig doesn't make this mistake.

grubby modified grub.cfg exhibting the problem in the first menu entry
grubby_grub.txt

strace grubby (new-kernel-pkg runs grubby twice, the problem happens with the 2nd command that uses --update-kernel and --initrd flags)
strace grubby update initrd.txt

kernel options lost if upgrade before reboot

Initially observed on CentOS 8 stream but reproduced with Fedora rawhide 20210525.

If a kernel option is added and then kernel upgraded (or reinstalled) before reboot then the kernel option is lost.

Steps to reproduce

Initial Status

# rpm -q kernel-core grubby
kernel-core-5.13.0-0.rc3.25.fc35.x86_64
grubby-8.40-52.fc35.x86_64
uname -a
Fedora (5.13.0-0.rc3.25.fc35.x86_64) 35 (Cloud Edition Prerelease)

# grubby --info=DEFAULT
index=1
kernel="/boot/vmlinuz-5.13.0-0.rc3.25.fc35.x86_64"
args="ro no_timer_check net.ifnames=0 console=tty1 console=ttyS0,115200n8"
root="UUID=ec0ebe42-73a3-441f-9910-dce10ec8253e"
initrd="/boot/initramfs-5.13.0-0.rc3.25.fc35.x86_64.img"
title="Fedora (5.13.0-0.rc3.25.fc35.x86_64) 35 (Cloud Edition Prerelease)"
id="4ce7a933859f4a76a5111fba2d010ca3-5.13.0-0.rc3.25.fc35.x86_64"

Add a Kernel Parameter.

# /sbin/grubby --update-kernel=DEFAULT --args=foo=bar

kernel parameter is added.

# grubby --info=DEFAULT
index=1
kernel="/boot/vmlinuz-5.13.0-0.rc3.25.fc35.x86_64"
args="ro no_timer_check net.ifnames=0 console=tty1 console=ttyS0,115200n8 foo=bar"
root="UUID=ec0ebe42-73a3-441f-9910-dce10ec8253e"
initrd="/boot/initramfs-5.13.0-0.rc3.25.fc35.x86_64.img"
title="Fedora (5.13.0-0.rc3.25.fc35.x86_64) 35 (Cloud Edition Prerelease)"
id="4ce7a933859f4a76a5111fba2d010ca3-5.13.0-0.rc3.25.fc35.x86_64"

Now upgrade (or reinstall) kernel with no reboot so the kernel parameter is pending.

dnf reinstall kernel-core

and check parameters again:

# grubby --info=DEFAULT
index=1
kernel="/boot/vmlinuz-5.13.0-0.rc3.25.fc35.x86_64"
args="ro no_timer_check net.ifnames=0 console=tty1 console=ttyS0,115200n8"
root="UUID=ec0ebe42-73a3-441f-9910-dce10ec8253e"
initrd="/boot/initramfs-5.13.0-0.rc3.25.fc35.x86_64.img"
title="Fedora (5.13.0-0.rc3.25.fc35.x86_64) 35 (Cloud Edition Prerelease)"
id="4ce7a933859f4a76a5111fba2d010ca3-5.13.0-0.rc3.25.fc35.x86_64"

The kernel parameter foo=bar has vanished.

What should happen

The kernel parameter should not be lost on kernel upgrade even if no reboot has been made to activate that kernel
parameter yet.

multiple images for initrd but only the first one got recognized

I try to config a grub menuentry with grubby.

with line: initrd: /initrd.img ignition.img.

But when I try to print the config with grubby --info some_index
I found something like:

initrd: /boot/initrd.img /ignition.img

which I expected /boot/initrd.img /boot/ignition.img.

Did I miss any thing here?

git fsck fails 

$ git clone https://github.com/rhboot/grubby.git
$ cd grubby
$ git fsck

Output:

error in tag 9861a77979d622d6df23528b71b9b631756684cc: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 3a0fe075da607fc91a977e370e1774a0f82c30fd: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 161514ab1b6cad6107762608f49279c74d21761f: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 034886e84d26a30c21a631c43ca89c3aebb653d9: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag cbe6360c30677e0cd254075b191ebbc40be02206: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 9f95a6b5a4e18b935ba06f6aaec80cd3493218c9: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 77109d4c5d1c922c8f638fb05e65d64b36becdc5: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 1437016fe3f71e063ccc6a0207c40a2c4b85cbba: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 0360eaec724a6cfe8e1a6d8259a1815e5f0fb2eb: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 6f24fbc51bdeaebbb99bb145228ee8a94647cd8e: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag ad989b9b3ca777ea890852e58ef1fcca212c4fe8: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 63371c3f7174ae2048328ec8214c6530917de9a0: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 8ffc7fe20fb2a7c57d4c37b7630233447a3a54fc: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag aa742f6196502a19d8c09b076298807caab46784: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag e72e289d159c6d3ec524c2a1487408f2a3a0aebc: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 96dfa03efd221536422805534273b06fb1b52f15: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag a88f5bab6119d0074cdd565f4aac22641c0b6d0f: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 6e32d5311341fd42b40a5b57967f68bbb0265486: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 79091f7f54ddf5da1f755454337c208ba77a8934: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 298ec0cc479d8bd841a4400cfef2e41451a98de9: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 30f22938b24d40335be42947b29eb543f05458ed: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 557a43cfd8ec8f5e2152161a4806bfecf35a13e1: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 2aaaf95ddf7f6930f15840ec733cd2aaad853fd8: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 3058b4f5d15a707b1a99feedb9ba15862079389d: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag ef29a5fdfc60751f82e54694ca2a9dc2afac4e22: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 4c0cecac6bb16776c93f6e677079a02ecca0cc21: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag afdbbc6035b8352490c1369378156cc47368d5f4: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 480dc12d0080c56256d93759a1b341802d84cc10: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 374c27ae67a7d2c1896d3b07a82ddfc3708776a0: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 6cc318d0a3fa6cc9ac0ff5d80c067b1f9f481c57: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 322e9d0e3159ebdaa008cc8bd7a2a9f42a35c791: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 7f57b17959965e0c6fff1d0b8207bea21f50c4a0: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 214439348fa3f086c8c7aa2b4005e4df9c06e478: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 91a6ed239c22f7e3deecf65b77470d8885743377: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag a2cb3c516f28ffc2b6c9d62a0408bee91101f334: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag ce46e9244b957844433d9a546e70da1826f4b763: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag 94779a6de5ba9d3a6720e4bcb23d7bad375db528: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag eed81ab7eb3407ce52df2f961450b94fa9e19eca: missingSpaceBeforeDate: invalid author/committer line - missing space before date
error in tag c0a6b97ee6196775187ec787cc7a2122645b3aaf: missingSpaceBeforeDate: invalid author/committer line - missing space before date
Checking objects: 100% (8280/8280), done.

stray symlinks in /boot ($LINK_PATH)

When installing a kernel with the INSTALL_PATH variable set to install to a specific location, installkernel-bls still tries to setup symlinks to vmlinux and System.map in /boot.

I'm curious as to the rationale for these symlinks - it seems to me they should also obey the INSTALL_PATH variable if set.

The relevant lines are:

ln -fs ${RELATIVE_PATH}$INSTALL_PATH/$KERNEL_NAME-$KERNEL_VERSION $LINK_PATH/$KERNEL_NAME
ln -fs ${RELATIVE_PATH}$INSTALL_PATH/System.map-$KERNEL_VERSION $LINK_PATH/System.map

grubby getting confused when root attribute ends in 'root'

My root device is /dev/mapper/fedora_localhost--live-root. When I run this:
grubby -c original.cfg --grub2 --remove-kernel=/boot/vmlinuz-5.9.15-200.fc33.x86_64 -o new.cfg
on a correct config file, it becomes something like this:

---snip---
if [ -z "${kernelopts}" ]; then
  set kernelopts="root=/dev/mapper/fedora_localhost--live-root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet "
fi
---snip---

Essentially, it gets into a loop of root=/dev/mapper/fedora_localhost--live-root=/dev/mapper/fedora_localhost--live-root=... (sometimes it repeats many more times).

grubby.zip

Log file: do you actually need to fdatasync() after every write? 

# time ./grubby --default-kernel
/boot/vmlinuz-3.10.0-229.20.1.el7.x86_64

real    0m0.151s
user    0m0.006s
sys     0m0.010s
# time grubby --default-kernel
/boot/vmlinuz-3.10.0-229.20.1.el7.x86_64

real    0m12.558s
user    0m0.005s
sys     0m0.022s
# git diff
diff --git a/log.c b/log.c
index 2bcfa40..1e82a9e 100644
--- a/log.c
+++ b/log.c
@@ -101,7 +101,7 @@ log_vmessage(FILE *log, const char *msg, va_list ap)

        vfprintf(log ? log : f, msg, aq);
        va_end(aq);
-       fdatasync(log ? fileno(log) : log_fd);
+       //fdatasync(log ? fileno(log) : log_fd);

        return 0;
 }

Thanks.

BTRFS: grubby fatal error: unable to find a suitable template

grubby-8.40-3.fc24.x86_64

Summary:
When a Btrfs subvolume is mounted at /boot, grubby fails to update grub.cfg with this error message. grub2-mkconfig has no issue with this configuration and produces working grub.cfg.

Detail:

[chris@localhost ~]$ cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Thu Jan 19 15:38:36 2017
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=6b187fa6-f62a-47f8-b09c-0bcbc7a7036e /                       btrfs   subvol=root     0 0
UUID=6b187fa6-f62a-47f8-b09c-0bcbc7a7036e /home                   btrfs   subvol=home     0 0
UUID=ee093fa4-8d28-4169-83c8-ff5c998f599e swap                    swap    defaults        0 0

[chris@localhost ~]$ sudo blkid
/dev/vda1: UUID="9c6af6bb-a87c-4881-8406-e2e5abd5efa5" TYPE="ext4" PARTUUID="361cd7e6-01"
/dev/vda2: UUID="ee093fa4-8d28-4169-83c8-ff5c998f599e" TYPE="swap" PARTUUID="361cd7e6-02"
/dev/vda3: LABEL="fedora" UUID="6b187fa6-f62a-47f8-b09c-0bcbc7a7036e" UUID_SUB="355f5c4d-952a-4d03-a793-74accbe14540" TYPE="btrfs" PARTUUID="361cd7e6-03"

[chris@localhost ~]$ stat /
  File: /
  Size: 154       	Blocks: 0          IO Block: 4096   directory
Device: 27h/39d	Inode: 256         Links: 1
Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:root_t:s0
Access: 2017-01-19 13:38:39.723713159 -0700
Modify: 2017-01-10 04:12:29.516524841 -0700
Change: 2017-01-19 13:30:47.771278980 -0700
 Birth: -

[chris@localhost ~]$ stat /boot
  File: /boot
  Size: 790       	Blocks: 0          IO Block: 4096   directory
Device: 27h/39d	Inode: 257         Links: 1
Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:boot_t:s0
Access: 2017-01-19 13:55:11.488599883 -0700
Modify: 2017-01-19 13:55:10.570588940 -0700
Change: 2017-01-19 13:55:10.570588940 -0700
 Birth: -

[chris@localhost ~]$ cat /proc/mounts   ##summary
/dev/vda3 / btrfs rw,seclabel,relatime,space_cache,subvolid=257,subvol=/root 0 0
/dev/vda3 /home btrfs rw,seclabel,relatime,space_cache,subvolid=258,subvol=/home 0 0

Evaluation:
This example uses /boot as a directory in the 'root' subvolume which is in turn mounted at /.

Basically this bug is not so much a Btrfs subvolume problem per se, but a combination of how Fedora's installer creates subvolumes at the top level of the Btrfs volume, and how they end up being bind mounted behind the scenes with the Btrfs subvol= mount option found in fstab. GRUB understands this by always following the top level of the volume whether it's mounted or not. Grubby doesn't seem to know about the top level of Btrfs volumes, it merely follows the mounted path structure. Therefore it doesn't recognize the path /root/boot/ instead it only sees the path as /boot/.

An old downstream bug report uses a 'boot' subvolume mounted at /boot which runs into the identical error.
https://bugzilla.redhat.com/show_bug.cgi?id=864198

grub.cfg.txt
grubby-debug.log.txt

Enhancement - Support for setting/clearing `--unrestricted` from menu entries

I do not see anyway in grubby to set or clear the --unrestricted in a menuentry. It seems that when using --copy-default, the current default kernel value is copied. Without using --copy-default then --unrestricted is omitted. (Note, I am using version 8.28 at the moment, but looked at latest in git also.)

Request an option to allow setting/removing this flag from existing and new menu entries.

grubby/grubby.c

Line 3448 in 526e39e

char *lineend = "--class gnu-linux --class gnu --class os {";

new-kernel-pkg: Add --dracutoptions

I want to create an initramfs using xz compression but there is no way to do that from new-kernel-pkg. I have to manually edit new-kernel-pkg with '--xz' and then call new-kernel-pkg.

Add --dracutoptions which is a list of options that will be added to the dracut command line.

/sbin/installkernel doesn't update default grub kernel

The make rpm target (now make rpm-pkg target) in the kernel used to create an RPM package that, when installed, would become the new default selection in the grub menu.

The code currently in the kernel doesn't do that anymore:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/package/mkspec#n110

Installing this kernel should make it the default entry in grub.

(tested on Fedora 30 with the current tip of the linus git kernel)

grubby does not find kernel images on btrfs subvolumes

Description of problem:

Config files created for/by BootLoaderSpec contain verbose paths to kernel images containing the whole btrfs subvolume paths, while the kernel images are accessible from the mounted path in the running system:

# ls /boot/vmlinuz-5.0.16-300.fc30.x86_64 
/boot/vmlinuz-5.0.16-300.fc30.x86_64


# head -4 /boot/loader/entries/76c448f84ac94df9b7354b30c92fb8eb-5.0.16-300.fc30.x86_64.conf 
title Fedora (5.0.16-300.fc30.x86_64) 30 (Thirty)
version 5.0.16-300.fc30.x86_64
linux /root/boot/vmlinuz-5.0.16-300.fc30.x86_64
initrd /root/boot/initramfs-5.0.16-300.fc30.x86_64.img
       ^^^^^^^^^^^

This results in incomprehensible error messages when using grubby:

grubby --info /boot/vmlinuz-5.0.14-300.fc30.x86_64
The param /boot/vmlinuz-5.0.14-300.fc30.x86_64 is incorrect

It seems like it's actually not possible at all to use grubby --update-kernel, even with the full path:

grubby --update-kernel /root/boot/vmlinuz-5.0.14-300.fc30.x86_64 
The param /boot/vmlinuz-5.0.14-300.fc30.x86_64 is incorrect

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

grub2-common.noarch          1:2.02-80.fc30                 @updates                       
grubby.x86_64                8.40-30.fc30                   @fedora

How reproducible:
Always, when the partition containing /boot is mounted from a btrfs subvolume

Expected results:
Accessing kernel images via grubby should work when accessing them from the running system's path (/boot instead of /root/boot).

Additional info:

sudo btrfs subvolume list /
ID 258 gen 1087767 top level 5 path home
ID 320 gen 1087767 top level 5 path root

dracut boot options

In modernize branch, util/functions' default_get_kernel_args() will not work for /etc/sysconfig/{keyboard,i18n} (BTW a clean RHEL 7 install does not have these files), because dracut option mapping differs from /etc/{vconsole.conf,locale.conf}.

Is RHEL 6 compatibility necessary?

The following patch makes it work. Command line option quoting (FOO="bar") removed, because RHEL 6's dracut does not parse them correctly (not a problem in RHEL 7).

Master branch commit a6843cb was thought only for Fedora 19+ and RHEL 7+, because they have dracut with the HostOnly feature.

--- util/functions  2016-04-19 12:54:48.262619997 -0300
+++ util/functions  2016-04-19 12:55:44.373661497 -0300
@@ -173,30 +173,45 @@

 default_get_kernel_args()
 {
+    local dracut_legacy="no"
     local kernargs=""
-    # add dracut i18n, keyboard and plymouth kernel args if requested
+    local kernargs_map=""
+
     if [ -r /etc/vconsole.conf ]; then
         . /etc/vconsole.conf
     elif  [ -r /etc/sysconfig/keyboard ]; then
         . /etc/sysconfig/keyboard
+        dracut_legacy="yes"
     fi

     if [ -r /etc/locale.conf ]; then
         . /etc/locale.conf
     elif [ -r /etc/sysconfig/i18n ]; then
         . /etc/sysconfig/i18n
+        dracut_legacy="yes"
+    fi
+
+    if [ "$dracut_legacy" = "no" ]; then
+        kernargs_map='KEYMAP        rd.vconsole.keymap
+                      FONT          rd.vconsole.font
+                      FONT_MAP      rd.vconsole.font.map
+                      FONT_UNIMAP   rd.vconsole.font.unimap
+                      UNICODE       rd.vconsole.font.unicode
+                      EXT_KEYMAP    rd.vconsole.keymap.ext
+                      LANG          rd.locale.LANG
+                      LC_ALL        rd.locale.LC_ALL'
+    else
+        kernargs_map='KEYBOARDTYPE   KEYBOARDTYPE
+                      KEYTABLE       KEYTABLE
+                      SYSFONT        SYSFONT
+                      SYSFONTACM     SYSFONTACM
+                      UNIMAP         UNIMAP
+                      LANG           LANG'
     fi

     while read opt rd_opt; do
-        [ -n "${!opt}" ] && kernargs="$kernargs $rd_opt=\"${!opt}\""
-    done <<< 'KEYMAP        rd.vconsole.keymap
-              FONT          rd.vconsole.font
-              FONT_MAP      rd.vconsole.font.map
-              FONT_UNIMAP   rd.vconsole.font.unimap
-              UNICODE       rd.vconsole.font.unicode
-              EXT_KEYMAP    rd.vconsole.keymap.ext
-              LANG          rd.locale.LANG
-              LC_ALL        rd.locale.LC_ALL'
+        [ -n "${!opt}" ] && kernargs="$kernargs $rd_opt=${!opt}"
+    done <<< "$kernargs_map"

     echo $kernargs
 }

new-kernel-pkg: do not rely on /etc/fstab for kernel root device

/dev/sda1 could be a symlink to /dev/xvda1 on a Xen guest. If this is the case, /dev/sda1 is a valid fstab entry but not a valid root cmdline parameter, because /dev/sda1 becomes avaliable only after udevd runs. I made an amazon ec2 instance unbootable this way.

Why not use /proc/cmdline only for $rootdevice?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.