From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Description of problem: When installing kernel-2.4.18-19.8.0 wither via rpm -ivh or via up2date -u, the install hangs while trying to umount /dev/loop (umount is consuming 91% CPU). No amount of kill or kill -9 can get rid of this process. Only way to successfully upgrade is to use single user mode. This problem also occurred when installing 2.4.18-18.8.0. I have no idea if this could be a rpm issue. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. rpm -ivh kernel-2.4.18-19.8.0.i686.rpm 2. 3. Actual Results: Install hangs. Expected Results: Install completed successfully. Additional info: rpm-4.1-1.06 mount-2.11r-10 mkinitrd-3.4.28-1
I can replicate this readily on my home 8.0 box. It fails making the initrd after kernel installation. I can generally trigger it just by making an initrd. Here's a bit of diagnostic info from the system exhibiting this: Jan 7 23:29:16 localhost kernel: su S 00000000 0 7966 7779 7969 (NOTLB) Jan 7 23:29:16 localhost kernel: Call Trace: [<c0125b52>] sys_rt_sigaction [kernel] 0x82 (0xd587df64)) Jan 7 23:29:16 localhost kernel: [<c011e280>] sys_wait4 [kernel] 0x100 (0xd587df80)) Jan 7 23:29:16 localhost kernel: [<c0109117>] system_call [kernel] 0x33 (0xd587dfc0)) Jan 7 23:29:16 localhost kernel: Jan 7 23:29:16 localhost kernel: bash S 00000000 0 7969 7966 8010 (NOTLB) Jan 7 23:29:16 localhost kernel: Call Trace: [<c011e280>] sys_wait4 [kernel] 0x100 (0xd188ff80)) Jan 7 23:29:16 localhost kernel: [<c0109117>] system_call [kernel] 0x33 (0xd188ffc0)) Jan 7 23:29:16 localhost kernel: Jan 7 23:29:16 localhost kernel: loop0 S 00000002 0 8191 1 7949 (L-TLB) Jan 7 23:29:16 localhost kernel: Call Trace: [<c0107d31>] __down_interruptible [kernel] 0x71 (0xd1985f84)) Jan 7 23:29:16 localhost kernel: [<c0107ddf>] __down_failed_interruptible [kernel] 0x7 (0xd1985fac)) Jan 7 23:29:16 localhost kernel: [<e0ca8100>] .text.lock.loop [loop] 0x55 (0xd1985fb8)) Jan 7 23:29:16 localhost kernel: [<e0ca6bf0>] loop_thread [loop] 0x0 (0xd1985fc8)) Jan 7 23:29:16 localhost kernel: [<c010745e>] kernel_thread [kernel] 0x2e (0xd1985ff0)) Jan 7 23:29:16 localhost kernel: [<e0ca6bf0>] loop_thread [loop] 0x0 (0xd1985ff8)) Jan 7 23:29:16 localhost kernel: Jan 7 23:29:16 localhost kernel: umount R current 4 8237 8010 (NOTLB) Jan 7 23:29:16 localhost kernel: Call Trace: [<c0140fbe>] invalidate_bdev [kernel] 0x5e (0xd028ff04)) Jan 7 23:29:16 localhost kernel: [<c014585b>] kill_bdev [kernel] 0x1b (0xd028ff38)) Jan 7 23:29:16 localhost kernel: [<c01466dd>] blkdev_put [kernel] 0xad (0xd028ff4c)) Jan 7 23:29:16 localhost kernel: [<c01447aa>] remove_super [kernel] 0x6a (0xd028ff68)) Jan 7 23:29:16 localhost kernel: [<c015762f>] sys_umount [kernel] 0x3f (0xd028ff80)) Jan 7 23:29:16 localhost kernel: [<c01576a7>] sys_oldumount [kernel] 0x17 (0xd028ffb4)) Jan 7 23:29:16 localhost kernel: [<c0109117>] system_call [kernel] 0x33 (0xd028ffc0)) Jan 7 23:29:16 localhost kernel: <snip> Jan 7 23:37:08 localhost kernel: SysRq : Show Regs Jan 7 23:37:08 localhost kernel: Jan 7 23:37:08 localhost kernel: Pid: 8237, comm: umount Jan 7 23:37:08 localhost kernel: EIP: 0010:[<c0140fba>] CPU: 0 Jan 7 23:37:08 localhost kernel: EIP is at invalidate_bdev [kernel] 0x5a (2.4.18-18.8.0) Jan 7 23:37:08 localhost kernel: EFLAGS: 00000206 Tainted: P Jan 7 23:37:08 localhost kernel: EAX: 00000700 EBX: caa02140 ECX: 00000001 EDX: d028e000 Jan 7 23:37:08 localhost kernel: ESI: 0000429c EDI: caa021c0 EBP: 00000000 DS: 0018 ES: 0018 Jan 7 23:37:08 localhost kernel: CR0: 8005003b CR2: 40018000 CR3: 07901000 CR4: 000002d0 Jan 7 23:37:08 localhost kernel: Call Trace: [<c014585b>] kill_bdev [kernel] 0x1b (0xd028ff38)) Jan 7 23:37:08 localhost kernel: [<c01466dd>] blkdev_put [kernel] 0xad (0xd028ff4c)) Jan 7 23:37:08 localhost kernel: [<c01447aa>] remove_super [kernel] 0x6a (0xd028ff68)) Jan 7 23:37:08 localhost kernel: [<c015762f>] sys_umount [kernel] 0x3f (0xd028ff80)) Jan 7 23:37:08 localhost kernel: [<c01576a7>] sys_oldumount [kernel] 0x17 (0xd028ffb4)) Jan 7 23:37:08 localhost kernel: [<c0109117>] system_call [kernel] 0x33 (0xd028ffc0)) Jan 7 23:37:08 localhost kernel: root 7966 0.0 0.1 3832 1012 pts/7 S 23:17 0:00 su - root 7969 0.0 0.2 4212 1512 pts/7 S 23:17 0:00 -bash root 8191 0.0 0.0 0 0 ? SW 23:18 0:00 [loop0] root 8237 87.8 0.0 3136 484 pts/7 R 23:18 13:09 umount /tmp/initrd.mnt.qtKWbl root 8244 0.0 0.1 3832 1012 pts/6 S 23:21 0:00 su - root 8247 0.0 0.2 4212 1512 pts/6 S 23:21 0:00 -bash root 8010 0.0 0.2 3896 1156 pts/7 S 23:18 0:00 /bin/bash /sbin/mkinitrd initrd-2.4
I also get this on my home machine.
I'm also seeing this under Red Hat 7.3, but just on Dell PowerEdge 2550's. I have a number of Dell PowerEdge 4400's that I'm not seeing this on and I haven't nailed down what the exact cause of the hang is. The symptoms I'm seeing are consistent with what you're reporting (hung loop0 and umount process). All other errata are applied on these boxes.
I'm seeing this on my system too (Xeon-2.4, gdth, mirrored ultra320 drives, 1G ram, running original 2.4.18-14 kernel). To troubleshoot it, I modified /sbin/new-kernel-pkg to run mkinitrd under strace - o /tmp/mkinitrd.out -f. This caused all hell to break loose in mkinitrd: VFS: Can't find ext2 filesystem on dev loop(7,0). tune2fs: Bad magic number in super-block while trying to open /dev/loop0 Couldn't find valid filesystem superblock. mount: wrong fs type, bad option, bad superblock on /dev/loop0, or too many mounted file systems umount: /tmp/initrd.mnt.XpHPy0: not mounted Adding a 'sync' after the 'dd if=/dev/zero of=$IMAGE' line in mkinitrd seems to help considerably, but tune2fs still pukes sometimes: tune2fs: Bad magic number in super-block while trying to open /dev/loop0 Couldn't find valid filesystem superblock. So it looks like it's doing the tune2fs before the mke2fs has completed. Adding a 'sleep 5' after the mke2fs appears to make it work reliably for me.
The work around Jon Lusky describes works for me too. Thanks Jon for sorting this out. Now we can upgrade the kernel of our Dell PE 1650's.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/