Red Hat Bugzilla – Bug 502286
Kickstart induced error
Last modified: 2009-06-30 17:45:04 EDT
The following was filed automatically by anaconda:
anaconda 220.127.116.11 exception report
Traceback (most recent call first):
File "/usr/lib/anaconda/booty/x86.py", line 154, in writeGrub
f = open(cf, "w+")
File "/usr/lib/anaconda/booty/x86.py", line 534, in write
justConfig | (not self.useGrubVal))
File "/usr/lib/anaconda/bootloader.py", line 204, in writeBootloader
File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep
rc = stepFunc(self.anaconda)
File "/usr/lib/anaconda/dispatch.py", line 128, in gotoNext
File "/usr/lib/anaconda/text.py", line 712, in run
File "/usr/bin/anaconda", line 965, in <module>
IOError: [Errno 2] No such file or directory: '/mnt/sysimage/boot/grub/grub.conf'
Created attachment 345180 [details]
Attached traceback automatically from anaconda.
How were you installing?
Let me rephrase - can you attach the kickstart you were using?
# Kickstart file Digifarma BV
url --url http://<server>/fedora/development/i386/os
# Network configuration.
network --device eth0 --bootproto static --ip <IP> --netmask <MASK> --gateway <GW> --nameserver <NS> --hostname host.digifarma.nl
authconfig --enableshadow --passalgo=sha512
timezone --utc Europe/Amsterdam
bootloader --location=mbr --timeout=20 --append="nomodeset"
clearpart --all --initlabel
#part /boot --fstype ext3 --size=512 --grow --maxsize=1024
#part / --fstype ext3 --size=1024 --grow
part /boot --fstype ext3 --size=512
part pv.7 --size=10 --grow --ondisk=sda
volgroup VolGroup00 --pesize=32768 pv.7
logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=1000 --grow --maxsize=1984
logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow
#part swap --size=512 --grow --maxsize=1024
repo --name="Fedora rawhide - i386" --baseurl=http://<server>/fedora/development/i386/os
The underlying problem is a filesystem error:
<6>sda1: rw=0, want=1311256, limit=1048576
<2>EXT3-fs error (device sda1): read_inode_bitmap: Cannot read inode bitmap - block_group = 5, inode_bitmap = 163906
<2>EXT3-fs error (device sda1) in ext3_new_inode: IO failure
<6>attempt to access beyond end of device
that is preventing the grub package from being installed:
error: unpacking of archive failed on file /boot/grub: cpio: mkdir failed - Input/output error
my guess here is some kind of hardware problem. Eric ?
Looks like another case of the device being smaller than the filesystem, something which anaconda was happily doing up until recently... dlehman? :)
On second (parallel) thought - A.J. is this /dev/sda1 still intact so we can do some inspection of it?
device limit is: 1073741824 (262144 blocks)
mkfs'd: 1069252608 (261048 blocks)
tried to read: 1342726144 (327814 blocks)
dunno what may have gone on in between. Looking at /dev/sda1 would help.
I have this system intakt, as far as hardware is concerned. I use it as a testing machine, so the harddisks have been altered a lot since I ran into this bug.
But tell me what you want to know, what you want me to test.
A.J. if /dev/sda1 has been altered since the bug was filed then not so interesting, I guess. If it's the same size, and un-mkfs'd since then, then I guess as a start I'd like to see what "e2fsck -fn" says about it.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
I have blank the disk after this bug a few times, so I can't garanty this information covers the situation that led to the bug. But I tried to reproduce the situation. I see block coutn errors, but don't know if this is relevant to this bug.
My "e2fsck -fn /dev/sda1" output is as follows:
Warning! /dev/sda1 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (239641, counted=234257).
Free inodes count wrong (65237, counted=65235).
/boot: ********** WARNING: Filesystem still has errors **********
/boot: 43/65280 files (0.0% non-contiguous), 21407/261048 blocks
Well, checking live filesystems is expected to find some inconsistencies.
If you can recreate the problem from kickstart as originally reported, when things fail due to IO errors, -then- I'd like to be able to take a look at the filesystem, starting with an e2fsck -fn, as well as dumpe2fs -h output and the partition's size in /proc/partitions.
But if you've since had a successful install which overwrote the problematic filesystem, then I'm afraid the state of the filesystem is no longer interesting.
I'm going to close this, not sure we can get further info. If you see it again, or can reproduce at will, please re-open and we'll keep diggging.