Excuse in advance for the long post....<br>Some time ago, during f5-testx phase, I asked why, after an unclean shutdown (crash or poweroff, ecc), it was no more proposed to do an fsck (with default of no if no answer in a due interval for example...). I found it at:
<br>
<a href="https://www.redhat.com/archives/fedora-devel-list/2005-December/msg01165.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://www.redhat.com/archives/fedora-devel-list/2005-December/msg01165.html
</a><br><br>Now I come again, during test phase of upcoming f8, explaining a problem I intercepted.
<br>My system is x86_64 with a quad core cpu and both a rawhide and a f7 on different partitions<br>Yesterday, while inside rawhide updated at 2-3 October, I was downloading 7.92 dvd iso but in the meanwhile I found screen apparently frozen (f bubbles stopped) without no option to give input...
<br>So I was forced to keep power off button pressed until stop.
<br>At restart, always in rawhide, I got automatically recovery of journal for the fs that were mounted:<br><br>/dev/sda4 my current rawhide / filesystem<br><br>/dev/sda3 my fc7 x86_64 / filesystem<br><br>No particular message; in /var/log/messages I got:
<br>Oct 4 23:00:15 tekkaman kernel: EXT3-fs: INFO: recovery required on readonly filesystem.<br>Oct 4 23:00:15 tekkaman kernel: EXT3-fs: write access will be enabled during recovery.<br>Oct 4 23:00:15 tekkaman kernel: kjournald starting. Commit interval 5 seconds
<br>Oct 4 23:00:15 tekkaman kernel: EXT3-fs: sda4: orphan cleanup on readonly fs<br>Oct 4 23:00:15 tekkaman kernel: EXT3-fs: sda4: 1 orphan inode deleted<br>Oct 4 23:00:15 tekkaman kernel: EXT3-fs: recovery complete.<br>
Oct 4 23:00:15 tekkaman kernel: EXT3-fs: mounted filesystem with ordered data mode.<br>...<br>Oct 4 23:00:15 tekkaman kernel: kjournald starting. Commit interval 5 seconds<br>Oct 4 23:00:15 tekkaman kernel: EXT3 FS on sda3, internal journal
<br>Oct 4 23:00:15 tekkaman kernel: EXT3-fs: mounted filesystem with ordered data mode.<br><br>I deleted the firefox .part file and restarted the download from the beginning.<br>sha1sum of the file was ok<br>I then copied the
3.5Gb file to the fc7 partition to be able to do a hard disk installation of f8-t3, but for three times the resulting file was not the same as the target, even if cp command exited normally......<br>both sha1sum and cksum gave different results:
<br>[root@tekkaman testuser2]# cp -p Fedora-7.92-x86_64-DVD.iso /fc7_x86_64/home/gcecchi/<br>[root@tekkaman testuser2]# sha1sum /fc7_x86_64/home/gcecchi/Fedora-7.92-x86_64-DVD.iso <br>6e5ba85f7b0f48ae0a2ccbd206a6979426818ad0 /fc7_x86_64/home/gcecchi/Fedora-
7.92-x86_64-DVD.iso<br>[root@tekkaman testuser2]# cksum Fedora-7.92-x86_64-DVD.iso <br>1026324974 3543584768 Fedora-7.92-x86_64-DVD.iso<br>[root@tekkaman testuser2]# cksum /fc7_x86_64/home/gcecchi/Fedora-7.92-x86_64-DVD.iso
<br>3095081338 3543584768 /fc7_x86_64/home/gcecchi/Fedora-7.92-x86_64-DVD.iso<br><br>dmesg gave nothing particular<br>I tried with dd: also this command completed correctly but generating a wrong file....<br>[root@tekkaman
testuser2]# dd if=Fedora-7.92-x86_64-DVD.iso of=/fc7_x86_64/home/gcecchi/Fedora-7.92-x86<br>_64-DVD.iso bs=1024k<br>3379+1 records in<br>3379+1 records out<br>3543584768 bytes (3.5 GB) copied, 181.017 s, 19.6 MB/s<br><br>
This time with dmesg I found this output (I have nvidia proprietary, so it is tainted):<br><br>BUG journal_head (Tainted: P ): Object padding overwritten<br>-----------------------------------------------------------------------------
<br><br>INFO: 0xffff81007961ffbd-0xffff81007961ffbd. First byte 0x1a instead of 0x5a<br>INFO: Allocated in journal_add_journal_head+0x27/0x15b [jbd] age=15635 cpu=0 pid=7223<br>INFO: Slab 0xffff810003a85ba0 used=1 fp=0xffff81007961fe70 flags=0x78080000000083
<br>INFO: Object 0xffff81007961ff18 @offset=3864 fp=0x0000000000000000<br><br>Bytes b4 0xffff81007961ff08: c4 2f 93 01 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a �/......ZZZZZZZZ<br> Object 0xffff81007961ff18: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
<br> Object 0xffff81007961ff28: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br> Object 0xffff81007961ff38: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br> Object 0xffff81007961ff48: 00 00 00 00 00 00 00 00 00 90 8f 20 00 81 ff ff ..............��
<br> Object 0xffff81007961ff58: d8 b9 c9 45 00 81 ff ff 00 00 00 00 00 00 00 00 ع�E..��........<br> Object 0xffff81007961ff68: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br> Redzone 0xffff81007961ff78: cc cc cc cc cc cc cc cc ��������
<br> Padding 0xffff81007961ffb8: 5a 5a 5a 5a 5a 1a 5a 5a ZZZZZ.ZZ <br><br>Call Trace:<br> [<ffffffff8109c4c4>] check_bytes_and_report+0xa3/0xc9<br> [<ffffffff88029ae5>] :jbd:journal_remove_journal_head+0x24/0x38
<br> [<ffffffff8109c819>] check_object+0x156/0x23a<br> [<ffffffff8109d695>] __slab_free+0x1ca/0x2e6<br> [<ffffffff88029ae5>] :jbd:journal_remove_journal_head+0x24/0x38<br> [<ffffffff8109dee1>] kmem_cache_free+0xb9/0xe0
<br> [<ffffffff88029ae5>] :jbd:journal_remove_journal_head+0x24/0x38<br> [<ffffffff88025827>] :jbd:journal_commit_transaction+0x4ef/0x10c0<br> [<ffffffff88029920>] :jbd:kjournald+0xba/0x21d<br> [<ffffffff8104a1ea>] autoremove_wake_function+0x0/0x2e
<br> [<ffffffff88029866>] :jbd:kjournald+0x0/0x21d<br> [<ffffffff8104a0a8>] kthread+0x47/0x73<br> [<ffffffff812692eb>] trace_hardirqs_on_thunk+0x35/0x37<br> [<ffffffff8100ca88>] child_rip+0xa/0x12<br>
[<ffffffff81033bd2>] schedule_tail+0x6c/0xd4<br> [<ffffffff8100c19c>] restore_args+0x0/0x30<br> [<ffffffff8101bfda>] lapic_next_event+0x0/0xa<br> [<ffffffff81049f31>] kthreadd+0x117/0x13c<br> [<ffffffff8104a061>] kthread+0x0/0x73
<br> [<ffffffff8100ca7e>] child_rip+0x0/0x12<br><br>FIX journal_head: Restoring 0xffff81007961ffbd-0xffff81007961ffbd=0x5a<br><br>I don't know if this was related to source or target problems...<br>I tried to fsck the target:
<br><br>[root@tekkaman testuser2]# fsck -fy /dev/sda3<br>fsck 1.40.2 (12-Jul-2007)<br>e2fsck 1.40.2 (12-Jul-2007)<br>Pass 1: Checking inodes, blocks, and sizes<br>Pass 2: Checking directory structure<br>Pass 3: Checking directory connectivity
<br>Pass 4: Checking reference counts<br>Pass 5: Checking group summary information<br>/1: 326714/9768928 files (6.4% non-contiguous), 8406328/9767520 blocks<br><br>But nothing changed trying to do a copy.<br>So I did a <br>
touch /forcefsck<br>and rebooted again in rawhide<br><br>The rawhide / filesystem was checked with no particular message....<br>Finally I was able to correctly copy the file....<br><br>So, if you had the patience:<br>wouldn't it be better to at least ask if one want to force a fsck after a crash, with a timeout eventually, as in the old days?
<br>Otherwise one is in need to touch the /forcefsck file and reboot again without choice....<br>Or is this "only" a bug and these kind of things should never happen at all?<br><br>Thanks<br>Gianluca<br><br> <br>