[Bug 186512] kernel prevents proper CD checking (mediacheck/install fails)
by Red Hat Bugzilla
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 #47 from Andre Robatino <andre(a)bwh.harvard.edu> 2010-04-08 15:02:52 EDT ---
Stephen: if you are able to read the discs properly with the rawread script,
then you're not seeing the same issue. The read errors I'm talking about
happen even when the rawread script is used (which I always do) since they
happen before the ISO file has been fully read off.
Personally, the only time I've heard of this problem on DVDs was when my father
bought a Fedora 8 DVD online. The easiest way I know to reproduce it is to
burn a CD-RW in the simplest possible way - i.e.,
wodim -v dev=/dev/cdrom blank=fast file.iso
in the default TAO mode (DAO seems to prevent the bug). Growisofs uses DAO by
default which may explain why it's so difficult to reproduce on DVDs.
--
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.
14 years, 1 month
[Bug 186512] kernel prevents proper CD checking (mediacheck/install fails)
by Red Hat Bugzilla
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
Stephen Clement <s.clement(a)sympatico.ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |s.clement(a)sympatico.ca
--- Comment #46 from Stephen Clement <s.clement(a)sympatico.ca> 2010-04-08 11:25:10 EDT ---
I can confirm what Andre said, I'm using i386 f12 with a HL-DT-ST DVDRAM
GSA-H62N and I see read failures near the end of dual layer DVDs, screwing up
hashing. Using the rawread script fixes the issue.
--
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.
14 years, 1 month
[Bug 248538] pam_mount does not unmount file system after logout - patch proposed
by Red Hat Bugzilla
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=248538
Till Maas <opensource(a)till.name> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |opensource(a)till.name
--- Comment #8 from Till Maas <opensource(a)till.name> 2010-04-08 10:57:29 EDT ---
(In reply to comment #7)
> Even though this bug is so old, I can reliably reproduce the same problem on
> current F12. In this case some applications (most frequently Akonadi's MySQL
> daemon) take some time to shutdown and since pam_mount waits *before* sending
> signals and not after, the app is still running when umount is attempted.
> Probably the killing logic in mount.c:umount_final() should be rewritten a bit
> to correctly wait until all applications shut down and not to wait
> unnecessarily (i.e. when there's nothing to kill).
Please open a new bug report, either here or even preferable at upstream,
because it is a different issue (different cause, but same effect).
--
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.
14 years, 1 month
[Bug 248538] pam_mount does not unmount file system after logout - patch proposed
by Red Hat Bugzilla
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=248538
Tomáš Trnka <TomTrnka(a)seznam.cz> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |TomTrnka(a)seznam.cz
--- Comment #7 from Tomáš Trnka <TomTrnka(a)seznam.cz> 2010-04-08 10:45:20 EDT ---
Even though this bug is so old, I can reliably reproduce the same problem on
current F12. In this case some applications (most frequently Akonadi's MySQL
daemon) take some time to shutdown and since pam_mount waits *before* sending
signals and not after, the app is still running when umount is attempted.
Probably the killing logic in mount.c:umount_final() should be rewritten a bit
to correctly wait until all applications shut down and not to wait
unnecessarily (i.e. when there's nothing to kill).
--
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.
14 years, 1 month
[Bug 173854] Bring media mountpoints up to date
by Red Hat Bugzilla
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=173854
Ondrej Vasik <ovasik(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |CLOSED
Version|12 |rawhide
Fixed In Version| |filesystem-2.4.34-1.fc14
Resolution| |RAWHIDE
--- Comment #13 from Ondrej Vasik <ovasik(a)redhat.com> 2010-04-08 04:37:56 EDT ---
Well, the bigger possible harm is strikeback of
https://bugzilla.redhat.com/show_bug.cgi?id=52046 ... after upgrade. If someone
uses /mnt/cdrom or /mnt/floppy as location for floppy/cdrom mounts points,
those empty dirs will get removed after this filesystem update. However - media
dirs are now more in use and I do plan to do that in rawhide only (and just
once). So let's see... dropped ownership in filesystem-2.4.34-1.fc14. Closing
RAWHIDE.
--
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.
14 years, 1 month
[Bug 288361] check_link_down delay of 10 to low
by Red Hat Bugzilla
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=288361
Nadav Har'El <nyh(a)math.technion.ac.il> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nyh(a)math.technion.ac.il
--- Comment #9 from Nadav Har'El <nyh(a)math.technion.ac.il> 2010-04-01 11:04:08 EDT ---
I would like to urge you to reopen this bug, and fix it. Despite it being
closed NOTABUG, it *is* a bug.
For the vast majority of today's users, a network *is* available, and giving up
after 5 seconds is non-sensical. Worse, the message you show is:
"Determining IP information for eth0... failed; no link present. Check cable?"
Which gives two confusing, false leads - the first part leads the user to
assume the problem is somehow related to DHCP, while the second part leads the
user to check the cable. The user can wiggle the cable and "service network
restart" till hell freezes over, and it won't help until he increases
LINKDELAY.
Since this is a relatively common problem (see also bug 425877 and bug 470327.
It also happens frequently in my company's network), shouldn't be the *minimal*
fix to this bug to add a short reference to LINKDELAY in the above message?
Frankly, I'm not sure why you are worried about increasing the default
LINKDELAY from 5 to something higher, say 10 or 20. Users that don't have no
network setup at all will not experience this delay. Users with a functional
network will not experience this delay (the loop stops as soon as the link
comes up). The only people who will experience the longer delay are people who
have set up the network (so they want it up) but their network link is indeed
down. The extra delay of 20 seconds is probably the least of their worries in
this case. And don't forget to balance this with all the people for whom Fedora
will just give up after 5 seconds and never connect to the Internet - while
Windows, Ubuntu, and others will not give up so quickly and eventually (say,
after 6 seconds ;-)) connect.
--
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.
14 years, 1 month