Bug 676551

Leaving notes on proposed blockers as I won't be at the meeting tomorrow most
likely:

We have no criterion for this. It feels like something we should have a criterion for, but for me it's Final rather than Alpha. It's a convenience function, not vital; you can always check the image manually. -1 blocker, +1 NTH.

First, it's best if you stop thinking in terms of stage1/stage2.  There is no more initrd.img followed by install.img.  Now, everything is in the initrd.  The reason that's important is I don't think mediacheck of the netinst.iso makes sense anymore.  I think that by the time the loader is running, everything we ever would have read off the CD has been loaded into memory by the bootloader.

I'm still looking into media check with the full DVD, though.

Per 2011-02-11 Blocker meeting - 
#agreed 676551 - Does not impact Alpha criteria, move to F15Blocker to track netinst.iso mediacheck prompt, ensure release notes are planned for updates about initrd.img changes.

Setting release notes flag - need to ensure docs team can document initrd changes.

This should be fixed in the next build of anaconda following F15 alpha, and is not testable via an updates.img.

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

JMHO, not more.

While it may be a convenience function from the viewpoint of developers, it is a necessary function from the viewpoint of testers/users.

Readability on the target machine (where the rubber meets the road) is the issue.

Further, it would seem that developers would want to decimate the number of bugs filed due to bad media (as seen by the target machine).

e.g., if the .iso checksums after download and the burn verifies the image on the CD/DVD and the target machine can't read it, then one can focus on the target machine and determine the cause.

I imagine that is why there is a memtest on the menu ...

kind regards/vaden

With 15 Beta TC1, both i386 and x86_64, the mediacheck is back for DVD but not netinst. Using VirtualBox 4.04 running using known good TC1 ISO files, the mediacheck fails for the i386 DVD ISO but succeeds for the x86_64 DVD ISO. External checks on the ISO files afterwards using the checkisomd5 command all pass, as do the sha256 checksums.

There's no point to having media check on the netinst.iso anymore - please see comment #2.

(In reply to comment #9)
> There's no point to having media check on the netinst.iso anymore - please see
> comment #2.

OK, so this bug appears to be fixed then (and the Final Release Criterion should mention that mediacheck is not expected for netinst). I'll file a new bug for the failure of the i386 DVD mediacheck - which Component should it be under?

Filed bug 692272 against anaconda.

Marking this bug as VERIFIED

(In reply to comment #2)
> First, it's best if you stop thinking in terms of stage1/stage2.  There is no
> more initrd.img followed by install.img.  Now, everything is in the initrd. 
> The reason that's important is I don't think mediacheck of the netinst.iso
> makes sense anymore.  I think that by the time the loader is running,
> everything we ever would have read off the CD has been loaded into memory by
> the bootloader.
> 
> I'm still looking into media check with the full DVD, though.

There are several files on the CD not in initrd.img. The media check verifies the *entire* disc, not just the files the installer cares about.

Could booting the installer always detect a one-character change to isolinux.cfg, say?

For reference (F15-Beta-RC2):
$ ls -RF cdrom
cdrom:
images/  isolinux/

cdrom/images:
pxeboot/  TRANS.TBL

cdrom/images/pxeboot:
initrd.img  initrd-PAE.img  TRANS.TBL  vmlinuz*  vmlinuz-PAE*

cdrom/isolinux:
boot.cat  boot.msg  grub.conf  initrd.img  isolinux.bin  isolinux.cfg  memtest  splash.jpg  TRANS.TBL  vesamenu.c32  vmlinuz*

(In reply to comment #13)
...
> Could booting the installer always detect a one-character change to
> isolinux.cfg, say?
...

I have verified that booting to the installer cannot detect a one-byte change to the net installer CD ISO image. It boots fine in qemu, but fails checkisomd5.

General method:
Make a copy of an ISO image.
Use a hex editor to change a byte.
Run checkisomd5.
Boot with qemu-kvm.

Details:
$ cp -ip Fedora-15-Beta-i386-netinst.iso Fedora-15-Beta-i386-netinst-korrupt.iso

$ checkisomd5 Fedora-15-Beta-i386-netinst-korrupt.iso # PASS

$ shed Fedora-15-Beta-i386-netinst-korrupt.iso

# I changed "corrupt" to "korrupt" in the isolinux header.

$ hexdump -C -n 512 Fedora-15-Beta-i386-netinst-korrupt.iso
...
00000090  00 e8 83 00 69 73 6f 6c  69 6e 75 78 2e 62 69 6e  |....isolinux.bin|
000000a0  20 6d 69 73 73 69 6e 67  20 6f 72 20 6b 6f 72 72  | missing or korr|
000000b0  75 70 74 2e 0d 0a 66 60  66 31 d2 66 03 06 f8 7b  |upt...f`f1.f...{|
...

$ checkisomd5 Fedora-15-Beta-i386-netinst-korrupt.iso # FAIL

$ qemu-kvm -m 1024 Fedora-15-Beta-i386-netinst-korrupt.iso # BOOTS

(In reply to comment #14)
> $ qemu-kvm -m 1024 Fedora-15-Beta-i386-netinst-korrupt.iso # BOOTS

This corrupt image also boots when burned to a CDRW.

$ hexdump -C -n 512 /dev/sr0
...
00000090  00 e8 83 00 69 73 6f 6c  69 6e 75 78 2e 62 69 6e  |....isolinux.bin|
000000a0  20 6d 69 73 73 69 6e 67  20 6f 72 20 6b 6f 72 72  | missing or korr|
000000b0  75 70 74 2e 0d 0a 66 60  66 31 d2 66 03 06 f8 7b  |upt...f`f1.f...{|
...

$ checkisomd5 -v /dev/sr0
/dev/sr0:   2b4c4d8ff350e392b291c8bf645b6ee5
Fragment sums: 456e7e661e54e7ebca82fdb2acb297cff356156c7f657a847198b47e8893
Fragment count: 20
Press [Esc] to abort check.
Checking: 004.8%

The media check is complete, the result is: FAIL.

It is not recommended to use this media.

$ rpm -q isomd5sum
isomd5sum-1.0.6-2.fc14.x86_64

Discussed at 2011/04/15 blocker review meeting. The initial bug reported here is fixed, and the lack of mediacheck on netinst is a design decision - a request to change it should be tracked separately from this bug. Steve, if you're still worried about the lack of mediacheck on netinst, please file a separate bug for that, but don't mark it as a release blocker, we do not accept it as such (since it's an intentional design choice, not an accidental omission).



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers