Bug 398281

The link to the report about the fix that seems causing the problem is
https://bugzilla.redhat.com/show_bug.cgi?id=290951

Well, crud. Will look into this tomorrow.  Upstream fix for #290951 is slightly
different, too, FWIW.  Thanks for filing the bug!

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

(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!

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.

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.

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

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.

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

Created attachment 269571 [details]
hexdump -b -n 4096 /dev/ad4s1 > ad4s1.hex

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!

Created attachment 269581 [details]
dd if=/dev/ad4s1 of=ad4s1.raw count=1 bs=4096

Maybe the output of dd could be helpful too.

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!

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.

I take that back, F7 doesn't have the problematic patch...

Thank you for your quick and effective response!

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'

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.

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.

It works!

Great! I *think* you can go to
https://admin.fedoraproject.org/updates/F8/FEDORA-2007-3853 and vote for it :)

done

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.

*** Bug 415901 has been marked as a duplicate of this bug. ***

*** Bug 374521 has been marked as a duplicate of this bug. ***

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?

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

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?

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? :)

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.

Great, glad it's working for you :)

*** Bug 415991 has been marked as a duplicate of this bug. ***