Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=186512
David Tonhofer <d.tonhofer(a)m-plify.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |d.tonhofer(a)m-plify.com
--- Comment #40 from David Tonhofer <d.tonhofer(a)m-plify.com> 2009-01-03 19:15:39 EDT ---
I seem to have hit this bug on Fedora 10. I thought the SCSI/SATA drivers had a
bug until I found this report. Here we go:
With an LG GDRH20N SATA DVD-ROM:
-- Media Check fails 100% (tested DVDs, (live) CDs, several burns...)
-- "Independent Media Check" using another system works (dump the ISO
image, see below, then check the SHA1 sum against the official sum)
-- Installation fails in a totally weird manner
(e.g. at the very end, anaconda says "no kernel images installed" or
arbitrary packages are not found)
-- Starting the same system from a PATA drive found in the attic with
the same media works nicely (installation not yet tried, will try)
-- Media check passes if "ide=nodma" kernel option is given. Yowza!
Additionally:
-- Booting the system to Fedora 10 Live CD using aforementioned PATA
drive, then dumping an ISO image (in this case, F10-x86_64-Live.iso)
off the DVD-ROM if "ide=nodma" has NOT been set results in a:
-- correctly-sized
-- but slightly corrupted image
The dump was done with "dd if=/dev/sr0 of=/tmp/corrupted.iso"
It is probably not of big interest to know the exact differences,
but a little perl program to cut the dump into 10K blocks and hash
these, applied tp both original ISO and dumped ISO reveals 61 10K
blocks with differences, *spread throughout the image* (not only the
end affected).
Now going to have drink or two.
How to hash 10K blocks:
#!/usr/bin/perl
use Digest::MD5 qw(md5 md5_hex md5_base64);
$file = $ARGV[0];
open(FILE,$file) or die "Could not open $file: $!\n";
binmode FILE;
my $buffer;
my $size = 1024*10;
my $read;
my $pos = 0;
while (($read = read(FILE, $buffer, $size)) > 0) {
my $digest = md5_hex($buffer);
my $end = $pos + $size - 1;
print "$digest [$pos,$end] $size\n";
$pos += $size;
}
close(FILE);
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=194249
--- Comment #19 from Mike <mike.cloaked(a)gmail.com> 2009-01-03 17:02:41 EDT ---
Ahh OK - with pam_mount installed then mount.crypt and umount.crypt do work as
per #14 - however I get a request for the passphrase when the CD is loaded into
the drive and again another request for the passphrase when I issue the
mount.crypt command.
Also going to the device list in the "computer" gui browser, and right clicking
to eject the disk fails, but doing "eject /dev/cdrom" in the CLI does work.
It would be nice if this could be cleaned up so it works in a smoother fashion.
I know I could make a small script to mount and umount/eject but it would be
nice to have this available by default, and it would also be nice to have this
work such that on loading the CD, that the passphrase is requested, then at the
same time a mount point entered so that the pam_mount is then executed "under
the hood" - or is this a difficult facility to get working? I guess it would
fail if an inappropriate mount point was specified but there could be a default
such as /media/cdrom_crypt or somesuch?
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=194249
Till Maas <opensource(a)till.name> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|8 |10
--- Comment #18 from Till Maas <opensource(a)till.name> 2009-01-03 15:45:38 EDT ---
(In reply to comment #16)
> The mount works as per #13, but the suggestion from #14 does not as the command
> line does not recognise mount.crypt
You need to install pam_mount to get mount.crypt
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=194249
--- Comment #17 from Mike <mike.cloaked(a)gmail.com> 2009-01-03 14:55:04 EDT ---
Please can this be re-assigned to F10?
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=194249
--- Comment #16 from Mike <mike.cloaked(a)gmail.com> 2009-01-03 14:53:41 EDT ---
Tested in F10
The mount works as per #13, but the suggestion from #14 does not as the command
line does not recognise mount.crypt
The file browser in gnome sees the encrypted volume and clicking it requests a
passphrase but then fails to mount anything. Places in gnome again sees the
encrypted drive and requests a passphrase but again fails to mount saying there
is no mount point specified.
There are no messages in /var/log/messages indicating any connection to the
mount for the CDROM.
This needs to be remedied for F10/F11
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=186512
--- Comment #39 from Andre Robatino <andre(a)bwh.harvard.edu> 2009-01-02 16:57:36 EDT ---
This has been seen by someone else in bug #448291.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=162774
--- Comment #13 from Roland McGrath <roland(a)redhat.com> 2009-01-02 14:58:42 EDT ---
Since we are upstream maintainers, for Fedora strace I have always used fresh
upstream releases. Neither this nor other bugs are so urgent they can't wait
for that.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=162774
--- Comment #12 from Denys Vlasenko <dvlasenk(a)redhat.com> 2009-01-02 08:43:22 EDT ---
The fix is in upstream CVS now. Taking into account that this isn't a hot
potato (strace users were coping with inability to handle SIGTRAPs for many
years), I am contemplating just waiting till upstream code will trickle into
Fedora updates / new Fedora release.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=441073
--- Comment #22 from Stefan Richter <stefan-r-rhbz(a)s5r6.in-berlin.de> 2009-01-02 07:09:26 EDT ---
Re comment 17:
See http://marc.info/?l=linux1394-devel&m=123089504900333 --- David Moore
pointed out that libraw1394 accesses the local node(s) in order to determine
how many controllers are present. Furthermore, the local node is used as the
default node for several operations which many libraw1394 clients need, even
though a different node (e.g. camcorder) could be used for their purposes. We
should be able to fix most of these issues by modifications to libraw1394.
Remaining issues require kernel driver changes, but these don't affect dvgrab,
kino, and similar high-level applications.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=242386
Brian Mury <brianmury(a)alumni.uvic.ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |brianmury(a)alumni.uvic.ca
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.