Bug 398281 - Fix for #290951 cause F8 fails booting when BSD partitions are present
Fix for #290951 cause F8 fails booting when BSD partitions are present
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
8
All Linux
low Severity urgent
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
https://bugzilla.redhat.com/show_bug....
:
: 374521 415991 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-25 05:55 EST by gnazio
Modified: 2008-06-08 17:36 EDT (History)
8 users (show)

See Also:
Fixed In Version: 1.40.2-11.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-06 15:46:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
hexdump -b -n 4096 /dev/ad4s1 > ad4s1.hex (17.80 KB, application/octet-stream)
2007-11-27 05:13 EST, gnazio
no flags Details
dd if=/dev/ad4s1 of=ad4s1.raw count=1 bs=4096 (4.00 KB, application/octet-stream)
2007-11-27 05:18 EST, gnazio
no flags Details

  None (edit)
Description gnazio 2007-11-25 05:55:18 EST
Description of problem:
If a FreeBSD partition is present in any hard disk, F8 install fine but refuses
to boot with this error:
    init[1] trap divide error rip:2aaaab5638a4 rsp:............ error:0

There are at least 3 bug reports here in bugzilla and 2 threads on fedoraforum
about this problem.
On a long thread on fedoraforum, there are two interesting posts:
http://forums.fedoraforum.org/forum/showpost.php?p=908312&postcount=118
http://forums.fedoraforum.org/forum/showpost.php?p=908958&postcount=120

I can confirm that replacing just libblkid.so.1.0 (as unsure, I tried with both
/lib and /lib64 and disabled selinux too) with the ones from F7.90 I can
successfully boot.
Before replacing the file, the only way to boot into F8 was to unplug the HDs
with FreeBSD partitions.

Version-Release number of selected component (if applicable):
e2fsprogs >= 1.40.2-7.fc8

How reproducible:
It seems that lot of people is having problem with this.
Maybe there are a lot more because the default is to boot in quiet mode so
people don't see the same error message and just wonder why the boot process
hand on Red Hat Nash.

Steps to Reproduce:
1. Install/upgrade to F8 (or 7.92) on a pc...
  a. where a FreeBSD partition is present on same/other disk 
  b. create a FreeBSD partition on same/other disk
  c. plug in a disk with FreeBSD

Actual results:
F8 boot process stop and the error described above is printed in a loop.

Expected results:
F8 boots regularly

Additional info:
Comment 1 gnazio 2007-11-25 05:58:38 EST
The link to the report about the fix that seems causing the problem is
https://bugzilla.redhat.com/show_bug.cgi?id=290951
Comment 2 Eric Sandeen 2007-11-25 22:00:08 EST
Well, crud. Will look into this tomorrow.  Upstream fix for #290951 is slightly
different, too, FWIW.  Thanks for filing the bug!

Comment 3 Eric Sandeen 2007-11-25 23:14:25 EST
Until I get a real chance to look at this, I've rebuilt the F8 rpms (scratch
build only) with the "upstream" fix for bug #290951 if anyone would like to give
it a whirl:

http://koji.fedoraproject.org/scratch/sandeen/task_258089/

Thanks,
-Eric
Comment 4 gnazio 2007-11-26 03:19:36 EST
(In reply to comment #3)
> Until I get a real chance to look at this, I've rebuilt the F8 rpms (scratch
> build only) with the "upstream" fix for bug #290951 if anyone would like to give
> it a whirl:
> 
> http://koji.fedoraproject.org/scratch/sandeen/task_258089/
> 
> Thanks,
> -Eric

They work!

Comment 5 Eric Sandeen 2007-11-26 10:13:40 EST
Excellent... that was just a guess.  :)  I'll get this pushed out ASAP, then. 
If you're still on the fedoraforums thread, you might post that same
scratch-build URL there, to make sure others have success as well?  They can
chime in on this bug...

The problems you encountered may point to a lack of robustness in libblkid, too,
though.  Hmm.
Comment 6 gnazio 2007-11-26 12:46:50 EST
If you don't mind, I would like to do a test using again the e2fsprogs rpms
shipped with F8, as I want to be sure that it's not booting just because of my
tests with files from 7.90.
I'm telling this because I can still see the line pointed as offending by Konoha
on fedoraforum ( { "vfat", 0, 0x1fe, 2, "\125\252", probe_fat } ) in one of the
patches in the new rpm (it's the only different file on the two src rpms).
So I'll put the original rpms again hoping that the boot fails, then reapply the
ones you have rebuilt.
As soon as I'll have a result (about next 4h) I will post it here and eventually
on fedoraforum.
Comment 7 Eric Sandeen 2007-11-26 12:57:13 EST
Sure thing, I'll let you do more testing.  I haven't had time to look into this
yet but I figured testing the upstream patch, which differs from our patch in
fedora, is a good place to start.  Let me know what you find, thanks!

-Eric
Comment 8 gnazio 2007-11-26 16:25:08 EST
I did the test I told you and things went as expected!


These are the steps I've done (on x86_64) after downloading your rpms:

rpm -Uvh --force e2fsprogs-1.40.2-10.bz398281.1.fc8.x86_64.rpm
e2fsprogs-libs-1.40.2-10.bz398281.1.fc8.x86_64.rpm
e2fsprogs-libs-1.40.2-10.bz398281.1.fc8.i386.rpm
cd /boot && mkinitrd initrd-2.6.23.1-49.fc8.img.test 2.6.23.1-49.fc8

Then I added an entry for F8 with the new initrd image in  /boot/grub/grub.conf.
Comment 9 Eric Sandeen 2007-11-26 22:41:10 EST
It's probably picking up some random byte string that causes it to check, and
then dying on a divide by zero:

        cluster_count /= ms->ms_cluster_size;

        if (cluster_count > FAT32_MAX)
                return 1;

the new/upstream patch calls probe_fat_nomagic rather than probe_fat on this
bytestring, which has a few other checks that are probably just luckily causing
it to exit earlier.

For now I'll probably just put the upstream patch in place, but we should make
the probe routine more robust in the face of this sort of situation.

If anyone could provide (i.e. attach)  the first few kilobytes of a problematic
BSD partition, just for a sanity check, I'd appreciate it.

Thanks,
-Eric
Comment 10 gnazio 2007-11-27 05:13:37 EST
Created attachment 269571 [details]
hexdump -b -n 4096 /dev/ad4s1 > ad4s1.hex
Comment 11 gnazio 2007-11-27 05:15:57 EST
Oh! Yesterday I was thinking about the same thing and I was wondering if
attaching an hexdump could help.

In fact I was comparing the only file changed
(e2fsprogs-1.40.2-blkid-FAT-magic-not-on-strict-position.patch.) the src.rpm
from F8 and your.
They both add a line and the 2nd changes one.
So I was wondering if the change line on the 2nd is just "masking" the breaking one.

In all my FreeBSD partitions (I should say slice here) I can find the same magic
numbers at the same offset reported in both the lines added/changes in the patch.

I've attached the output of (first BSD slice of first SATA disk)
hexdump -b -n 4096 /dev/ad4s1 > ad4s1.hex

Tell me if you need something more!
Comment 12 gnazio 2007-11-27 05:18:54 EST
Created attachment 269581 [details]
dd if=/dev/ad4s1 of=ad4s1.raw count=1 bs=4096

Maybe the output of dd could be helpful too.
Comment 13 Eric Sandeen 2007-11-27 10:27:30 EST
Thanks, was good to confirm what I thought was happening, basically what I said
in comment #9 - upstream calls probe_fat_nomagic which has a couple other tests
ahead of it, and safely exits before probe_fat.

I also checked the upstream patch against the original bug, it's fine too, so
I'll get this pushed out soon.

Thanks for the good report & the image!
Comment 14 Eric Sandeen 2007-11-27 13:19:24 EST
Committed in e2fsprogs-1.40.2-11.fc8, requested push to testing repo

https://admin.fedoraproject.org/updates/F8/pending/e2fsprogs-1.40.2-11.fc8

I'll need to fix this in F7 too.
Comment 15 Eric Sandeen 2007-11-27 13:20:56 EST
I take that back, F7 doesn't have the problematic patch...
Comment 16 gnazio 2007-11-27 19:27:54 EST
Thank you for your quick and effective response!
Comment 17 Fedora Update System 2007-11-28 20:35:18 EST
e2fsprogs-1.40.2-11.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update e2fsprogs'
Comment 18 gnazio 2007-11-28 21:45:50 EST
Yum is still offering the version shipped with F8.
I guess that I've just have to wait that the mirrors get populated with the new
version. Am I correct?
I'll be back as soon as I will be able to get the new rpms.
Comment 19 gnazio 2007-11-29 18:29:43 EST
I had to run your command with an '*' at the end of 'e2fsprogs', else yum was
not asking me to upgrade the i386 version (installed by default so supposedly
needed).
Now I'm upgrading the other packages, and rebuilding a new initrd.
After a reboot I'll post the results.
Comment 20 gnazio 2007-11-29 18:59:24 EST
It works!
Comment 21 Eric Sandeen 2007-11-29 22:40:27 EST
Great! I *think* you can go to
https://admin.fedoraproject.org/updates/F8/FEDORA-2007-3853 and vote for it :)
Comment 22 gnazio 2007-11-30 03:24:21 EST
done
Comment 23 Fedora Update System 2007-12-06 15:46:18 EST
e2fsprogs-1.40.2-11.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 24 Chuck Ebbert 2007-12-07 13:38:54 EST
*** Bug 415901 has been marked as a duplicate of this bug. ***
Comment 25 Chuck Ebbert 2007-12-07 13:39:07 EST
*** Bug 374521 has been marked as a duplicate of this bug. ***
Comment 26 Paul Lipps 2007-12-07 20:19:36 EST
I updated using yum and e2fsprogs-1.40.2-11.fc8 is installed. But my problem
still persists. As soon as I install PC-BSD, Fedora 8 refuses to boot as before.
I noticed in the earlier comments, someone did something like:

cd /boot && mkinitrd initrd-2.6.23.1-49.fc8.img.test 2.6.23.1-49.fc8

Is this something I need to do? Are there other steps other then simply updating
that I need to perform?
Comment 27 Eric Sandeen 2007-12-07 20:29:45 EST
Yes, I believe you will need to remake any existing initrds you wish to boot from.

(no need to cd to /boot, and if you literally mkinitrd a file called
something.test you'll need to point grub at that initrd name)

-Eric
Comment 28 Paul Lipps 2007-12-07 20:38:13 EST
I appreciate your comments but I'm sorry, they are a little over my head. If you
Eric, or someone could help me I would appreciate it.

I currently have my two stock installed initrd files:

initrd-2.6.23.8-63.fc8.img
initrd-2.6.23.1-49.fc8.img

How would I go about correcting these to be able to continue to boot Fedora 8
with BSD installed? Will I need to perform these steps with each future kernel
upgrade?
Comment 29 Eric Sandeen 2007-12-07 20:46:09 EST
no need to do this for future kernel upgrades, the kernel package upgrade
creates the mkinitrd at install time.

for the older kernels try this, for example for the 2.6.23.8-63.fc8 kernel:

# mkinitrd -f /boot/initrd-2.6.23.8-63.fc8.img 2.6.23.8-63.fc8

that will (-f force) remake the initrd for the 2.6.23.8-63.fc8 kernel.

Of course you'll need to boot fedora one way or another to do this; perhaps with
a rescue disk?  I assume you've gotten yourself out of the non-booting quandry
before and can do it again, at least long enough to remake the initrd as above? :)
Comment 30 Paul Lipps 2007-12-07 21:09:50 EST
Fedora 8 is now booting with PC-BSD installed, and I've learned a tiny bit more
about this stuff. Good Times. Thanks again Eric.
Comment 31 Eric Sandeen 2007-12-07 21:16:35 EST
Great, glad it's working for you :)
Comment 32 Chuck Ebbert 2007-12-10 14:57:35 EST
*** Bug 415991 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.