Bug 1885323 - dracut calls sync with unsupported FILE parameter
Summary: dracut calls sync with unsupported FILE parameter
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dracut
Version: 7.8
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: qe-baseos-daemons
Depends On:
TreeView+ depends on / blocked
Reported: 2020-10-05 15:41 UTC by Filippo Carletti
Modified: 2021-10-01 14:24 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: ---
Doc Text:
Clone Of:
Last Closed:
Target Upstream Version:

Attachments (Terms of Use)

Description Filippo Carletti 2020-10-05 15:41:34 UTC
Description of problem:

dracut calls the sync command with the optional FILE parameter.

[root@ns7dis ~]# grep -n sync /usr/sbin/dracut
1708:if ! sync "$outfile" 2> /dev/null; then
1709:    dinfo "dracut: sync operartion on newly created initramfs $outfile failed"

[outfile is the initramfs]

sync command from coreutils-8.22 does not support the optional FILE parameter.

Final outcome:
if sync hangs during a kernel update, the generated grub.cfg misses the initramfs option and at the first reboot after update the system panics.

It happened to me multiple times due to network file system not responding blocking the sync command.

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


How reproducible:


Steps to Reproduce:
1. Make the sync command hang (I followed these steps: https://stackoverflow.com/questions/58631215/how-to-simulate-a-hanging-filesystem/58674850#58674850)
2. Start some writes before updating the kernel (I used dd of=/tmp/hangs/file)
3. systemctl stop nfs-server
4. yum update kernel

Actual results:

yum hangs:
 Package                   Arch                      Version                                    Repository                     Size
 kernel                    x86_64                    3.10.0-1127.19.1.el7                       ce-updates                     50 M

Transaction Summary
Install  1 Package

Total size: 50 M
Installed size: 64 M
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : kernel-3.10.0-1127.19.1.el7.x86_64         
[hangs forever]

[root@ns7dis ~]# tail -f /var/log/messages 
Oct  5 14:53:49 ns7dis dracut: *** Creating initramfs image file '/boot/initramfs-3.10.0-1127.19.1.el7.x86_64.img' done ***

 1787 pts/1    Ss     0:00  |   \_ -bash
 1833 pts/1    S+     0:03  |       \_ /usr/bin/python /usr/bin/yum update kernel
 3147 pts/1    S+     0:00  |           \_ /bin/sh /var/tmp/rpm-tmp.2PUz5N 0
 3183 pts/1    S+     0:00  |               \_ /bin/bash /usr/sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --up
 3205 pts/1    S+     0:00  |                   \_ /bin/bash /sbin/dracut -f /boot/initramfs-3.10.0-1127.19.1.el7.x86_64.img 3.10.0-
 3234 pts/1    S+     0:00  |                       \_ /bin/cat
14819 pts/1    D+     0:00  |                       \_ sync /boot/initramfs-3.10.0-1127.19.1.el7.x86_64.img

### BEGIN /etc/grub.d/10_linux ###
menuentry 'NethServer (3.10.0-1127.19.1.el7.x86_64) 7.8.2003' --class centos --class gnu-linux --class gnu --class os --unrestricted
 $menuentry_id_option 'gnulinux-3.10.0-1127.el7.x86_64-advanced-c5884e4b-a86b-4e41-864c-1d204ba576f0' {
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod xfs
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1'  aba5c44f-896a-44fe-bfb7-3b1be996a8f3
          search --no-floppy --fs-uuid --set=root aba5c44f-896a-44fe-bfb7-3b1be996a8f3
        linux16 /vmlinuz-3.10.0-1127.19.1.el7.x86_64 root=/dev/mapper/VolGroup-lv_root ro crashkernel=auto spectre_v2=retpoline rd.l
vm.lv=VolGroup/lv_root rd.lvm.lv=VolGroup/lv_swap nodmraid rhgb quiet LANG=en_US.UTF-8

Expected results:

yum completes
The system reboots and starts successfully.

Additional info:
The user reboots the machine because many commands hang.
Many times, it happened during backup to a nfs or cifs share.

Comment 2 Filippo Carletti 2020-11-19 09:52:57 UTC
#1850682 should fix.

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