Description of problem: I got a shock recently when one of my main instances at Amazon Web Services (AWS) didn't come back after a reboot, so I spent time determining what was causing it. I've now found that a working, reboot-able instance will work absolutely fine until e2fsprogs is installed, at which point the system fails once trying to leave runlevel S. Version-Release number of selected component (if applicable): Fedora 14, e2fsprogs 1.41.12-6.fc14 How reproducible: 100% Steps to Reproduce: 1. Create minimal install EBS-backed Fedora14 x86_64 instance (have not tested on i386, as I do not have an i386 EBS-backed instance) 2. "yum install e2fsprogs" (e2fsprogs-libs is added for dependencies) 3. Actual results: [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/xvda fsck.ext4: No such file or directory while trying to open /dev/xvda /dev/xvda: Expected results: System boots, I'm able to use e2fsprogs Additional info: I am somewhat involved in Fedora Cloud SIG; I wrote https://fedoraproject.org/wiki/Publishing_image_to_EC2 The AMI I use was built using the steps described there. Fedora doesn't have an official EBS-backed AMI yet, only S3. I can make my AMI available upon request, though I'd rather not make it public (due to how it is stored, I get charged for usage of that image).
The line that works on multiple reboots without e2fsprogs: /dev/xvda / ext4 relatime 1 1 After installing e2fsprogs, I need to change it to: /dev/xvda1 / ext4 relatime 1 1 Meaning, somehow installing e2fsprogs makes me need to add that character? I'm not certain this is a flaw in the setup of the AMI itself, though if it is then I am happy to change the AMI and any instructions I've given out. Seems like an odd behavior on the part of e2fsprogs. I could, for instance, install e2fsprogs by default and then just construct the original fstab with xvda1.
Additional note: I noted while uninstalling e2fsprogs and e2fsprogs-libs that e2fsprogs-libs was actually a dependency of things that are part of the minimal install; dump, readahead, quota, and rmt. I'm confused as to why e2fsprogs wasn't already installed then during the initial build; note the notes above for how I built the system, but the shortcut to the info is that I did a chroot install with this: yum -c /tmp/yumec2.conf --installroot=/mnt/chroot -y install grub grubby yum -c /tmp/yumec2.conf --installroot=/mnt/chroot -y groupinstall Base yum -c /tmp/yumec2.conf --installroot=/mnt/chroot -y install openssh-server kernel-headers kernel-PAE yum -c /tmp/yumec2.conf --installroot=/mnt/chroot -y clean packages No other packages were installed, just those. Why did e2fsprogs not get installed during this, since it is a dependency of other things that /did/ get installed? Any ideas?
final note: if I create an instance and reboot it, leaving / as xvda, everything works fine to work after installing e2fsprogs, I have to change / to xvda1 If I then uninstall e2fsprogs again (and e2fsprogs-libs) then / has to stay at the new location of xvda1
I have no idea why e2fsprogs wasn't installed, that seems like an installer problem of some sort; usually it is in the core set. When you boot your system happily, prior to installing e2fsprogs, what does /proc/mounts show? And the output of "blkid?" My guess is that you have a mismatch between /etc/fstab and what's in your initrd, and fstab shows /dev/xvda while root is really on /dev/xvda1. Once you install e2fsprogs, you have fsck.ext4 available, initscripts try to invoke it against /dev/xvda, and it fails. IOW, not an e2fsprogs bug but a configuration and/or installation problem. -Eric
grub.conf does have "root=/dev/xvda1" in both situations. /proc/mounts also has: /dev/xvda1 / ext4 rw,relatime,barrier=1,data=ordered 0 0 That said, when I originally built the image, I used /dev/xvda1 - and it wouldn't boot (as it couldn't find /dev/xvda1, just /dev/xvda). I can reboot it over and over prior to installing e2fsprogs, and it will continue to work with fstab pointing at /dev/xvda, grub pointing at /dev/xvda1, and mounts showing xvda1. Why? Dunno. I'm somewhat amused/confused that installing e2fsprogs changes this behavior. As far as why e2fsprogs isn't there....group Base has reiserfs-utils, squashfs-tools, hfsutils, xfsprogs, and jfsutils as optional - and it has ntfsprogs and dosfstools as default. Somewhere in there should be e2fsprogs, but...it's not there. Run "yum groupinfo Base|grep -i e2fs" yourself to see. I assume it should be...should I report that? Should an e2fsprogs person pipe up that they should be part of the default install? Seems really odd to have dosfstools and ntfsprogs as default, but not have e2fsprogs in the group at all...
(In reply to comment #1) > The line that works on multiple reboots without e2fsprogs: > > /dev/xvda / ext4 relatime 1 1 > > After installing e2fsprogs, I need to change it to: > > /dev/xvda1 / ext4 relatime 1 1 (In reply to comment #5) > grub.conf does have "root=/dev/xvda1" in both situations. /proc/mounts also > has: > > /dev/xvda1 / ext4 rw,relatime,barrier=1,data=ordered 0 0 Then /dev/xvda1 is the real root fs, and everything should refer to that. If e2fsprogs can't find an extN filesystem on /dev/xvda because it's on /dev/xvda1 instead, that's not e2fsprogs' fault :) IOW, /etc/fstab is wrong, but that didn't matter because you've specified root=/dev/xvda1 on the kernel cmdline. It's only when initscripts try to fsck filesystems listed in /etc/fstab that things go wrong. Before, you had no ext4 fsck utility to invoke, so it could not fail. You installed it, initscripts read in fstab that there was an ext4 fs on /dev/xvda, invoked it, and failed. The real bug/question here is how did /dev/xvda get into /etc/fstab when the root fs is xvda1? > That said, when I originally built the image, I used /dev/xvda1 - and it > wouldn't boot (as it couldn't find /dev/xvda1, just /dev/xvda). somewhere in there lies the real problem. > I can reboot > it over and over prior to installing e2fsprogs, and it will continue to work > with fstab pointing at /dev/xvda, grub pointing at /dev/xvda1, and mounts > showing xvda1. Why? Dunno. I'm somewhat amused/confused that installing > e2fsprogs changes this behavior. Again - the only thing e2fsprogs has to do with this failure is that when the boot process reads /etc/fstab and learns that it should invoke fsck.ext4 on /dev/xvda, it is able to invoke fsck.ext4 (before it could not; it was not there) and it fails, because /dev/xvda does not contain an ext4 filesystem. This is not an e2fsprogs bug. /etc/fstab does not reflect reality, and causes failures. > As far as why e2fsprogs isn't there....group Base has reiserfs-utils, > squashfs-tools, hfsutils, xfsprogs, and jfsutils as optional - and it has > ntfsprogs and dosfstools as default. Somewhere in there should be e2fsprogs, > but...it's not there. > > Run "yum groupinfo Base|grep -i e2fs" yourself to see. I assume it should > be...should I report that? Should an e2fsprogs person pipe up that they should > be part of the default install? Seems really odd to have dosfstools and > ntfsprogs as default, but not have e2fsprogs in the group at all... Perhaps you can file a bug against the distribution component if this isn't coming out right ...
I'm going to close this NOTABUG - it's not an e2fsprogs bug. If you can determine what else went wrong, causing the xvda vs. xvda1 mismatch on your system, you should probably re-open this bug against that component (and fix the summary...)