From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 Description of problem: When installing RedHat 7.3 from verified CDs, the install crashed when checking the partitions for bad blocks. System is pc pentiumII with separate partitions for / /var /usr /home swap, all on second hard drive. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.select defaults upto disk partitioning 2.partition second disk hdb1=/boot hdb2=swap hdb3=/var hdb4=extended partition hdb5=/ hdb6=/home hdb7=/usr 3.in diskdruid, select to format all non swap partitions to ext3 and check blocks 4. select custom install and a bunch of packages 5. install Actual Results: installation crashes when checking /dev/hdb7 for bad blocks, see info below. Expected Results: System should have installed successfully. Additional info: Bug is similar to # 64847 but crashes one line earlier with different error.
Created attachment 59804 [details] Anaconda dump file
This has been reported - assigning to an engineer. If you skip the bad block check it should work ok.
Created attachment 60164 [details] anaconda dump file
*** Bug 66714 has been marked as a duplicate of this bug. ***
This error occurs when the badblocks command detects bad blocks on the system. The traceback occurred because the output from the badblocks command has changed, fooling our parser. If you get this traceback it means you have bad blocks on the drive it was testing. In the future an error dialog will be presented saying bad blocks have been detected.
*** Bug 64711 has been marked as a duplicate of this bug. ***
*** Bug 66135 has been marked as a duplicate of this bug. ***
*** Bug 66199 has been marked as a duplicate of this bug. ***
*** Bug 66568 has been marked as a duplicate of this bug. ***
*** Bug 66757 has been marked as a duplicate of this bug. ***
*** Bug 66812 has been marked as a duplicate of this bug. ***
*** Bug 66817 has been marked as a duplicate of this bug. ***
*** Bug 66922 has been marked as a duplicate of this bug. ***
*** Bug 66925 has been marked as a duplicate of this bug. ***
*** Bug 67393 has been marked as a duplicate of this bug. ***
*** Bug 67019 has been marked as a duplicate of this bug. ***
I am also experiencing this problem, though I am sceptical that the badblocks causing the error are "real". I am creating software RAID 1 mounts, and for each mount point if I include a badblocks check one of the drives fails on its constituent partition (a Seagate Barracuda IV 40GB). Each time a badblock is reported on the <F5> console, an "attempt to access beyond end of device" error is reported on the <F4> console. It always the last block in the partition (which doesn't seem to trigger the anaconda bug) or last two blocks in the partition (which does). Note that it's always the last few blocks even if I change the partition sizes in the partition table! (I would have presumed that physical bad blocks would map to different parts of (different) partitions in this case). This might tie in with problems I've seen before with these sorts of errors and related ext3 errors on the old 7.2 install on the same machine. Indeed these errors were the reason I opted to go with a complete repartition and reinstall rather than an upgrade to 7.3. For these reasons I am _very_ unhappy about just turning the badblock check off - I'm suspicious that the partition sizes are being incorrectly assigned - and I feal that if I skip the check it'll come back later to bite me. If you can give me instructions on how to set the partitions sizes to be a few blocks smaller than wanted, I could see if this cures the problem.
Created attachment 62924 [details] Anaconda dump
*** Bug 67556 has been marked as a duplicate of this bug. ***
ok, I think I now know why I was getting bad blocks - see bug #67949 - I don't believe it was due to bad discs. Doesn't solve this particular bug, but may be useful as a pointer if you encounter bad blocks consistently at the end of a partition typed raid autodetect.
*** Bug 68337 has been marked as a duplicate of this bug. ***
I've also had anaconda abort on me doing a RH 7.3 install, however I did NOT get the same error message as listed in the dumps here. Unfortunately, the system this has happened on has no floppy drive, so getting a copy of the entire dump is a bit hellacious. Scenario: Rave intel 2U box, two 40gig IDE drives. Partionined for software raid with the following scheme: /boot - 256megs swap - 256megs / - 1 gig /tmp - 1 gig /home - 4 gig /usr - 6 gig /usr/local - 6 gig /var - remaining space (about 20 gig) I setup the same partitions on both IDE drives (as software raid type), then setup the RAID partitions as level 1. In all cases I indicated to check for bad blocks. I'm not sure which partition the error occured on but it was after succesfully checking at leas the first 2 partitions. The dump had an error message about "Integer lital too long". I suspect that in my case, the problem was the partition it was supposed to bad-block check was bigger than allowed for. the crash may have even just been in the code for rendering the progress display.
I copied down the most relevant bits of the crash I got mentioned above. On the F4 virtual screen this was the last error messag elisted: <6>Attempt to access beyond end of device <6>03:45: rw=0, want=4096544, limit=4096543 In the primary display, the innermost error from the installation script was listed as so: File "/usr/lib/anaconda/fsset.py" line 211, in badblocksDevice ValueError: invalid literal too long(): 4096540 4096541 Which at least to me looks like a case of a scripting error, ie. not allowing for badblock checks of very large partitions. At a guess, anyways, i'm not at all familiar with Python. Skipping the badblock test did allow me to install with no problem. However, that's a poor solution, :(
*** Bug 70075 has been marked as a duplicate of this bug. ***
*** Bug 70012 has been marked as a duplicate of this bug. ***
*** Bug 70519 has been marked as a duplicate of this bug. ***
*** Bug 70092 has been marked as a duplicate of this bug. ***
*** Bug 70044 has been marked as a duplicate of this bug. ***
*** Bug 70037 has been marked as a duplicate of this bug. ***
*** Bug 70015 has been marked as a duplicate of this bug. ***
*** Bug 69941 has been marked as a duplicate of this bug. ***
*** Bug 69757 has been marked as a duplicate of this bug. ***
*** Bug 69748 has been marked as a duplicate of this bug. ***
*** Bug 70742 has been marked as a duplicate of this bug. ***
*** Bug 70664 has been marked as a duplicate of this bug. ***
*** Bug 71321 has been marked as a duplicate of this bug. ***
*** Bug 71049 has been marked as a duplicate of this bug. ***
*** Bug 70823 has been marked as a duplicate of this bug. ***
*** Bug 71591 has been marked as a duplicate of this bug. ***
*** Bug 71597 has been marked as a duplicate of this bug. ***
*** Bug 71753 has been marked as a duplicate of this bug. ***
*** Bug 71883 has been marked as a duplicate of this bug. ***
*** Bug 72365 has been marked as a duplicate of this bug. ***
*** Bug 72830 has been marked as a duplicate of this bug. ***
*** Bug 72796 has been marked as a duplicate of this bug. ***
*** Bug 72945 has been marked as a duplicate of this bug. ***
I'm not having any problems using the badblocks check with latest trees CLOSED->RAWHIDE
*** Bug 73182 has been marked as a duplicate of this bug. ***
*** Bug 74082 has been marked as a duplicate of this bug. ***
*** Bug 73798 has been marked as a duplicate of this bug. ***
*** Bug 73725 has been marked as a duplicate of this bug. ***
*** Bug 73666 has been marked as a duplicate of this bug. ***
*** Bug 73541 has been marked as a duplicate of this bug. ***
*** Bug 74495 has been marked as a duplicate of this bug. ***
*** Bug 74642 has been marked as a duplicate of this bug. ***
*** Bug 74768 has been marked as a duplicate of this bug. ***
*** Bug 75445 has been marked as a duplicate of this bug. ***
*** Bug 75545 has been marked as a duplicate of this bug. ***
*** Bug 76398 has been marked as a duplicate of this bug. ***
*** Bug 74216 has been marked as a duplicate of this bug. ***
*** Bug 76679 has been marked as a duplicate of this bug. ***
*** Bug 74966 has been marked as a duplicate of this bug. ***
*** Bug 77046 has been marked as a duplicate of this bug. ***
*** Bug 78062 has been marked as a duplicate of this bug. ***
*** Bug 77982 has been marked as a duplicate of this bug. ***
*** Bug 78595 has been marked as a duplicate of this bug. ***
*** Bug 78798 has been marked as a duplicate of this bug. ***
*** Bug 78918 has been marked as a duplicate of this bug. ***
*** Bug 79051 has been marked as a duplicate of this bug. ***
Time tracking values updated
*** Bug 86160 has been marked as a duplicate of this bug. ***
Additional Comment #47 (dated last August) states that this bug has been closed, and yet this bug is still very active. I was unable to install RedHat 7.3 using images downloaded last month, so what does "resolved" mean if the bug is still veryt much alive and well (bug #86160)?
*** Bug 103827 has been marked as a duplicate of this bug. ***