Bug 669564
Summary: | installing e2fsprogs changes xvda to xvda1 at Amazon Web Services | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Brian LaMere <brianlamere> |
Component: | e2fsprogs | Assignee: | Eric Sandeen <esandeen> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 14 | CC: | esandeen, josef, kzak, oliver |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-01-21 17:48:08 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Brian LaMere
2011-01-14 00:10:56 UTC
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...) |