grub-mkconfig hangs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
grub2 (Ubuntu) |
Expired
|
Undecided
|
Unassigned |
Bug Description
Calling "grub-mkconfig -o /boot/grub/
run-parts: executing /etc/kernel/
I ran strace on calling grub-mkconfig. I'll attach the output, but here's a summary of the output. To my untrained eye, it looks like grub-mkconfig is calling pipe() and read() on a closed handle.
vvvvvvvvvvvvvvv
... snip ...
read(3, "/dev/mapper/
read(3, "", 128) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=17818, si_status=0, si_utime=0, si_stime=0} ---
rt_sigreturn() = 0
close(3) = 0
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 17818
pipe([3, 4]) = 0
clone(child_
close(4) = 0
read(3,
^
|
NOTE: THE PROCESS HANGS THERE
NOTE: AFTER KILLING THE PROCESS, THE LINE CONTINUES THERE
|
v
read(3, 0x7ffddd6b62e0, 128) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=16554, si_uid=0} ---
+++ killed by SIGTERM +++
^^^^^^^
Here are the package versions on hand as determined by "apt-cache policy grub grub-pc grub-efi"
vvvvvvvvvvvvvvv
grub:
Installed: (none)
Candidate: 0.97-29ubuntu66
Version table:
0.
500 http://
grub-pc:
Installed: 2.02~beta2-
Candidate: 2.02~beta2-
Version table:
*** 2.02~beta2-
500 http://
500 http://
100 /var/lib/
2.02~beta2-9 0
500 http://
grub-efi:
Installed: (none)
Candidate: 2.02~beta2-
Version table:
2.
500 http://
500 http://
2.02~beta2-9 0
500 http://
^^^^^^^
This is similar to what happened to me in bug #1510563 about a month ago.
Changed in grub2 (Ubuntu): | |
status: | Incomplete → New |
Changed in grub2 (Ubuntu): | |
status: | New → Incomplete |
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 17818 stack=0, flags=CLONE_ CHILD_CLEARTID| CLONE_CHILD_ SETTID| SIGCHLD, child_tidptr= 0x7fe3556d7a10) = 17819
pipe([3, 4]) = 0
clone(child_
close(4) = 0
read(3,
This is the standard usage of pipe. pipe opens two connected file descriptors, and returns these fds in the array that's the argument to pipe. The process then forks, the parent closes one, the child closes the other, and they talk across this pipe.
Since you are only stracing the grub-mkconfig process, and not following forks ('strace -ff'), this trace doesn't show us what's actually hanging.
grub-mkconfig, btw, is a shell script, so it's probably better to debug it using 'sh -x /usr/sbin/ grub-mkconfig' instead.