The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2004:634-01 Updated zip package fixes security issue Files available: zip-2.3-10.1.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin - Computer Systems Officer School of Information Technology Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2004:650-01 Updated libxml package fixes security vulnerabilities Files available: libxml-1.8.14-3.i386.rpm libxml-devel-1.8.14-3.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin - Computer Systems Officer School of Information Technology Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2004:600-01 Updated apache and mod_ssl packages fix security vulnerabilities Files available: mod_ssl-2.8.12-7.i386.rpm apache-1.3.27-9.ent.c2.1.i386.rpm apache-devel-1.3.27-9.ent.c2.1.i386.rpm apache-manual-1.3.27-9.ent.c2.1.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin - Computer Systems Officer School of Information Technology Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2004:638-01 Updated gd packages fix security issues Files available: gd-1.8.4-4.21.1.i386.rpm gd-devel-1.8.4-4.21.1.i386.rpm gd-progs-1.8.4-4.21.1.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin - Computer Systems Officer School of Information Technology Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2004:610-01 Updated XFree86 packages fix security issues Files available: XFree86-100dpi-fonts-4.1.0-64.EL.i386.rpm XFree86-4.1.0-64.EL.i386.rpm XFree86-75dpi-fonts-4.1.0-64.EL.i386.rpm XFree86-ISO8859-15-100dpi-fonts-4.1.0-64.EL.i386.rpm XFree86-ISO8859-15-75dpi-fonts-4.1.0-64.EL.i386.rpm XFree86-ISO8859-2-100dpi-fonts-4.1.0-64.EL.i386.rpm XFree86-ISO8859-2-75dpi-fonts-4.1.0-64.EL.i386.rpm XFree86-ISO8859-9-100dpi-fonts-4.1.0-64.EL.i386.rpm XFree86-ISO8859-9-75dpi-fonts-4.1.0-64.EL.i386.rpm XFree86-Xnest-4.1.0-64.EL.i386.rpm XFree86-Xvfb-4.1.0-64.EL.i386.rpm XFree86-cyrillic-fonts-4.1.0-64.EL.i386.rpm XFree86-devel-4.1.0-64.EL.i386.rpm XFree86-doc-4.1.0-64.EL.i386.rpm XFree86-libs-4.1.0-64.EL.i386.rpm XFree86-tools-4.1.0-64.EL.i386.rpm XFree86-twm-4.1.0-64.EL.i386.rpm XFree86-xdm-4.1.0-64.EL.i386.rpm XFree86-xf86cfg-4.1.0-64.EL.i386.rpm XFree86-xfs-4.1.0-64.EL.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin - Computer Systems Officer School of Information Technology Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2004:681-01 Updated samba packages fix security issue Files available: samba-2.2.12-1.21as.3.i386.rpm samba-client-2.2.12-1.21as.3.i386.rpm samba-common-2.2.12-1.21as.3.i386.rpm samba-swat-2.2.12-1.21as.3.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin - Computer Systems Officer School of Information Technology Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2005:012-01 Updated krb5 packages fix security vulnerabilities Files available: krb5-devel-1.2.2-32.i386.rpm krb5-libs-1.2.2-32.i386.rpm krb5-server-1.2.2-32.i386.rpm krb5-workstation-1.2.2-32.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin - Computer Systems Officer School of Information Technology Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2005:031-01 Updated php packages fix security issues Files available: php-4.1.2-2.2.i386.rpm php-devel-4.1.2-2.2.i386.rpm php-imap-4.1.2-2.2.i386.rpm php-ldap-4.1.2-2.2.i386.rpm php-manual-4.1.2-2.2.i386.rpm php-mysql-4.1.2-2.2.i386.rpm php-odbc-4.1.2-2.2.i386.rpm php-pgsql-4.1.2-2.2.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin - Computer Systems Officer School of Information Technology Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2005:150-01 Important: postgresql security update Files available: postgresql-7.1.3-6.rhel2.1AS.i386.rpm postgresql-contrib-7.1.3-6.rhel2.1AS.i386.rpm postgresql-devel-7.1.3-6.rhel2.1AS.i386.rpm postgresql-docs-7.1.3-6.rhel2.1AS.i386.rpm postgresql-jdbc-7.1.3-6.rhel2.1AS.i386.rpm postgresql-libs-7.1.3-6.rhel2.1AS.i386.rpm postgresql-odbc-7.1.3-6.rhel2.1AS.i386.rpm postgresql-perl-7.1.3-6.rhel2.1AS.i386.rpm postgresql-python-7.1.3-6.rhel2.1AS.i386.rpm postgresql-server-7.1.3-6.rhel2.1AS.i386.rpm postgresql-tcl-7.1.3-6.rhel2.1AS.i386.rpm postgresql-test-7.1.3-6.rhel2.1AS.i386.rpm postgresql-tk-7.1.3-6.rhel2.1AS.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2005:175-01 Low: kdenetwork security update Files available: kdenetwork-2.2.2-3.1.i386.rpm kdenetwork-ppp-2.2.2-3.1.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2005:173-01 Moderate: squid security update Files available: squid-2.4.STABLE7-1.21as.5.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2005:213-01 Important: xpdf security update Files available: xpdf-0.92-15.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the centos mirror: RHSA-2005:217-01 Moderate: mc security update Files available: gmc-4.5.51-36.6.i386.rpm mc-4.5.51-36.6.i386.rpm mcserv-4.5.51-36.6.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
Hello there, Is there a simple way to create (or modify) an ISO image of CentOS Discs, with the updates ? What I plan to do, is to gather the updates, include it into my new Iso file and burn another CD... Is there some tricks ??? :-) Thanks Stephane
On Mon, 2005-03-07 at 00:42 +0000, Stephane Magnier wrote:> Hello there, > > Is there a simple way to create (or modify) an ISO image of CentOS Discs, > with the updates ? > What I plan to do, is to gather the updates, include it into my new Iso file > and burn another CD... > > Is there some tricks ??? :-) > > Thanks > > Stephane >Here is the build file I used on the tree to get just binary ISOs: http://centos.hughesjr.com/testing/build.sh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.caosity.org/pipermail/centos/attachments/20050306/2c084c93/attachment.bin
On Mon, 2005-03-07 at 00:42 +0000, Stephane Magnier wrote:> Hello there, > > Is there a simple way to create (or modify) an ISO image of CentOS Discs, > with the updates ? > What I plan to do, is to gather the updates, include it into my new Iso file > and burn another CD... > > Is there some tricks ??? :-) > > Thanks > > Stephane >Here is the build file I used on the tree to get just binary ISOs: http://centos.hughesjr.com/testing/build.sh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.caosity.org/pipermail/centos/attachments/20050306/3796a47d/attachment.bin
And don''t forget to edit mkisopts and add -pad Johnny Hughes wrote:> On Mon, 2005-03-07 at 00:42 +0000, Stephane Magnier wrote: > >>Hello there, >> >>Is there a simple way to create (or modify) an ISO image of CentOS Discs, >>with the updates ? >>What I plan to do, is to gather the updates, include it into my new Iso file >>and burn another CD... >> >>Is there some tricks ??? :-) >> >>Thanks >> >>Stephane >> > > > Here is the build file I used on the tree to get just binary ISOs: > http://centos.hughesjr.com/testing/build.sh > > > ------------------------------------------------------------------------ > > _______________________________________________ > CentOS mailing list > CentOS@caosity.org > http://lists.caosity.org/mailman/listinfo/centos-- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
On Mon, 2005-03-07 at 14:15 +1100, John Newbigin wrote:> And don''t forget to edit mkisopts and add -pad
Have you confirmed it is still the default on your build host? If the default has changed then that would explain why there are lots of people having problems creating CDs. (See the "Getting burned ISO''s to pass mediacheck." thread). Maciej ?enczykowski wrote: > I beg to differ: > > man cdrecord (FC2): > -nopad Do not pad the following tracks - the default. John. Johnny Hughes wrote:> On Mon, 2005-03-07 at 14:15 +1100, John Newbigin wrote: > >>And don''t forget to edit mkisopts and add -pad > > > From rom the mkisofs man page: > ---------------------------- > The padding is needed as many operating systems (e.g. Linux) > implement read ahead bugs in their filesystem I/O. These bugs > result in read errors on one or more files that are located at > the end of a track. They are usually present when the CD is > written in Track at Once mode or when the disk is written as > mixed mode CD where an audio track follows the data track. > > To avoid problems with I/O error on the last file on the > filesystem, the -pad option has been made the default. > ---------------------------- > > So whatever problem they have, adding -pad should not solve it ... that > is the default for mkisofs unless you specify "-no-pad" > > > ------------------------------------------------------------------------ > > _______________________________________________ > CentOS mailing list > CentOS@caosity.org > http://lists.caosity.org/mailman/listinfo/centos-- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin
Referring back to the many threads on CD''s failing to burn...
But posting with a new topic to make more (''important'') people
to notice
this and actually maybe read through it and take action (it''s one
trivial line for goodness sake).
Actually, the problem isn''t with padding in mkisofs - whether
it''s enable
in mkisofs or not doesn''t actually make a difference - because the
md5sum
of the file which is burned into the beginning sectors is calculated from
the whole file mkisofs creates (ie. if mkisofs includes padding then this
padding will be included in the md5sum that anaconda creates and thus this
padding will need to be readable in order for mediacheck to pass). What
needs to be done is padding needs to be added _after_ the anaconda
mediacheck md5sum is calculated and added into the image. This can be
done in two ways:
1) run mkisofs
run anaconda-md5sum-implantation
append 30-300KB worth of zeroes to the image
md5sum the image and distribute it
burn image with cdrecord with or without padding (doesn''t matter)
this way the distributed image has padding at the end which isn''t
included
in the mediacheck checksum, but the padding is included in the md5sum
which is distributed alongside the file (so the file will pass both
mediacheck after burning even if the last few KB is unreadable, and will
pass manual md5sum before burning)
2) run mkisofs
run anaconda-md5sum-implantation
md5sum the image and distribute it
burn image with cdrecord with padding
this is the current way it is done - on bad burners (yes, it _is_ a
hardware issue, but it is a _very_ common hardware issue) this works since
the padding is done by cdrecord. Unfortunately cdrecord doesn''t pad by
default and hence what you normally get is:
3) run mkisofs
run anaconda-md5sum-implantation
md5sum the image and distribute it
burn image with cdrecord (default of no padding)
which often fails mediacheck since the last 30KB or so might come out
unreadable, and even though they are only padding (from the default 300KB
padding of mkisofs) they are still included in the mediacheck checksum,
and thus being unable to read this padding causes mediacheck to fail (the
CD will likely work though it''ll fail mediacheck...)
Now situation (3) is what we have.
Situation (2) is the current solution to get good mediacheck passing
iso''s. But it requires all users burning CD''s to remember to
pad in
cdrecord.
It would be better for this to be done once by the image creator - ie.
situation (1).
There are actually a few other solutions:
a) the best IMHO - is situation (1) - repad after md5sum implantation
b) modify cdrecord to burn with pad by default (will take _a long_ time to
spread into the wild)))
c) modify anaconda mediacheck to skip the zeroed out sectors at the end
(effectively calculating the md5sum of only the part of the iso before
padding) - but this is a little dangerous (there might be zeroes out
sectors before the padding which actually have meaning)
Option (a) can be performed immediately by just adding a single line
(dd if=/dev/zero bs=2048 count=150 >> file.iso) to the scripts used to
create the iso/dvd images right after the anaconda implantation.
Option (b) is nice and should probably be done anyway (making -pad
cdrecord option the default) but will take ages to spread and in the
meantime cd burning problems will continue to plague us.
Option (c) is also nice and should possibly be done, once we figure out
how to determine how much padding the file contains (or just assume
it''s
always 300KB since that''s how much mkisofs adds?)
Still, option (a) is best for now at least and would solve this problem
once and for all.
Cheers,
MaZe.
On Thu, 2005-03-10 at 15:37 +0100, Maciej ?enczykowski wrote:> Option (a) can be performed immediately by just adding a single line > (dd if=/dev/zero bs=2048 count=150 >> file.iso) to the scripts used to > create the iso/dvd images right after the anaconda implantation. >But this is a problem with cdrecord and not with iso generation. How does this solution impact people who do not use cdrecord to make ISOs. There are many people who burn the ISOs with other programs (growfs, nero, roxio ezcd, and a dozen other windows or mac ISO recording programs.) I''m not sure that we should put the extra items on the end of the file if it will adversely impact the other burning programs. Any comments...> Option (b) is nice and should probably be done anyway (making -pad > cdrecord option the default) but will take ages to spread and in the > meantime cd burning problems will continue to plague us. >This option only impacts the user that uses cdrecord and doesn''t impact other burning software.> Option (c) is also nice and should possibly be done, once we figure out > how to determine how much padding the file contains (or just assume it''s > always 300KB since that''s how much mkisofs adds?) > > Still, option (a) is best for now at least and would solve this problem > once and for all.-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.caosity.org/pipermail/centos/attachments/20050310/22e321d2/attachment-0001.bin
I''ve never had a problem burning ISO''s on Windows, but this time I had to transfer the ISO''s to another linux machine with a burner and use the cdrecord instructions w/ padding. I used to use Nero, now I use Sonic''s Record Now which I thought was the problem. -- Matt Shields http://masnetworks.biz http://sexydates4u.com http://shieldslinux.com http://shieldsproductions.com On Thu, 10 Mar 2005 20:15:32 -0600, Johnny Hughes <mailing-lists@hughesjr.com> wrote:> On Thu, 2005-03-10 at 15:37 +0100, Maciej ?enczykowski wrote: > > > Option (a) can be performed immediately by just adding a single line > > (dd if=/dev/zero bs=2048 count=150 >> file.iso) to the scripts used to > > create the iso/dvd images right after the anaconda implantation. > > > > But this is a problem with cdrecord and not with iso generation. How > does this solution impact people who do not use cdrecord to make ISOs. > There are many people who burn the ISOs with other programs (growfs, > nero, roxio ezcd, and a dozen other windows or mac ISO recording > programs.) > > I''m not sure that we should put the extra items on the end of the file > if it will adversely impact the other burning programs. > > Any comments... > > > Option (b) is nice and should probably be done anyway (making -pad > > cdrecord option the default) but will take ages to spread and in the > > meantime cd burning problems will continue to plague us. > > > > This option only impacts the user that uses cdrecord and doesn''t impact > other burning software. > > > Option (c) is also nice and should possibly be done, once we figure out > > how to determine how much padding the file contains (or just assume it''s > > always 300KB since that''s how much mkisofs adds?) > > > > Still, option (a) is best for now at least and would solve this problem > > once and for all. > > > _______________________________________________ > CentOS mailing list > CentOS@caosity.org > http://lists.caosity.org/mailman/listinfo/centos > > > >
> But this is a problem with cdrecord and not with iso generation. How > does this solution impact people who do not use cdrecord to make ISOs. > There are many people who burn the ISOs with other programs (growfs, > nero, roxio ezcd, and a dozen other windows or mac ISO recording > programs.)not really, this is a problem with the HW, it can potentially affect many burning programs (cdrecord included, basically all those which don''t pad by default), and most (all?) linux burning programs do make use of cdrecord, so... it is a big problem. Furthermore this solution doesn''t break it for anyone (except for having to download 300KB more worth of zeroes... but 300KB on a 700MB file is pretty much nothing anyway (0.042%)...)> I''m not sure that we should put the extra items on the end of the file > if it will adversely impact the other burning programs. > > Any comments...It won''t affect anything adversly, it will just make stuff work better for all those for whom it used to not work...> > Option (b) is nice and should probably be done anyway (making -pad > > cdrecord option the default) but will take ages to spread and in the > > meantime cd burning problems will continue to plague us. > > This option only impacts the user that uses cdrecord and doesn''t impact > other burning software.True, but cdrecord encompasses all of Linux :) Cheers, MaZe.
agreed Johnny Hughes wrote:> On Thu, 2005-03-10 at 15:37 +0100, Maciej ?enczykowski wrote: > > >>Option (a) can be performed immediately by just adding a single line >>(dd if=/dev/zero bs=2048 count=150 >> file.iso) to the scripts used to >>create the iso/dvd images right after the anaconda implantation. >> > > > But this is a problem with cdrecord and not with iso generation. How > does this solution impact people who do not use cdrecord to make ISOs. > There are many people who burn the ISOs with other programs (growfs, > nero, roxio ezcd, and a dozen other windows or mac ISO recording > programs.) > > I''m not sure that we should put the extra items on the end of the file > if it will adversely impact the other burning programs. > > Any comments... > > >>Option (b) is nice and should probably be done anyway (making -pad >>cdrecord option the default) but will take ages to spread and in the >>meantime cd burning problems will continue to plague us. >> > > > This option only impacts the user that uses cdrecord and doesn''t impact > other burning software. > > >>Option (c) is also nice and should possibly be done, once we figure out >>how to determine how much padding the file contains (or just assume it''s >>always 300KB since that''s how much mkisofs adds?) >> >>Still, option (a) is best for now at least and would solve this problem >>once and for all. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > CentOS mailing list > CentOS@caosity.org > http://lists.caosity.org/mailman/listinfo/centos-- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician) Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/
On Fri, 2005-03-11 at 11:03 +0100, Maciej ?enczykowski wrote:> > But this is a problem with cdrecord and not with iso generation. How > > does this solution impact people who do not use cdrecord to make ISOs. > > There are many people who burn the ISOs with other programs (growfs, > > nero, roxio ezcd, and a dozen other windows or mac ISO recording > > programs.) > > not really, this is a problem with the HW, it can potentially affect many > burning programs (cdrecord included, basically all those which don''t pad > by default), and most (all?) linux burning programs do make use of > cdrecord, so... it is a big problem. Furthermore this solution doesn''t > break it for anyone (except for having to download 300KB more worth of > zeroes... but 300KB on a 700MB file is pretty much nothing anyway > (0.042%)...) > > > I''m not sure that we should put the extra items on the end of the file > > if it will adversely impact the other burning programs. > > > > Any comments... > > It won''t affect anything adversly, it will just make stuff work better for > all those for whom it used to not work... >Some comments and tests: 1. The media check worked on my hardware as the script was written, and as burned on a Windows XP machine with nero and ezcd ... and as burned on CentOS-4 via cdrecord and k3b. Obviously it does not work for everyone, so more testing is in order :) 2. I added this code and re-made the ISOs dd if=/dev/zero bs=2048 count=150 >> file.iso The MD5 sums are different on the ISOs now (as you would expect) 3. I made a CD ISO via cdrecord and k3b ... It passed the media check. (My original passed the media check for me as well). 4. I made a CD ISO via Windows XP and Nero 6 and EZCD Creator... It passed the media check as well. (my original mad this way also passed the media check for me as well). I am not going to change the ISO now ... it is already downloaded 5200+ times just from BT, not including any mirror iso downloads. Since it seems that this method continues to work with current working hardware, and might fix the media checks non working burns, I will use the above code when we release the CentOS-4.1 respin (when RHEL 4 Update 1 is released). That way, we don''t have different ISOs floating around for 4.0 final. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.caosity.org/pipermail/centos/attachments/20050311/3c6d5a0e/attachment.bin
> Since it seems that this method continues to work with current working > hardware, and might fix the media checks non working burns, I will use > the above code when we release the CentOS-4.1 respin (when RHEL 4 Update > 1 is released). > > That way, we don''t have different ISOs floating around for 4.0 final.Thank you, that''s exactly what I was hoping for, making a backchange is of course pointless now (that it''s everywhere and everyone has it anyway), but including this in the future would be nice. [You did put the dd command after the anaconda implantisomd5, didn''t you? :)] Cheers, MaZe.
The following errata for CentOS-2 have been built and uploaded to the centos mirror: RHSA-2005:354-01 Moderate: tetex security update Files available: tetex-1.0.7-38.5E.8.i386.rpm tetex-afm-1.0.7-38.5E.8.i386.rpm tetex-doc-1.0.7-38.5E.8.i386.rpm tetex-dvilj-1.0.7-38.5E.8.i386.rpm tetex-dvips-1.0.7-38.5E.8.i386.rpm tetex-fonts-1.0.7-38.5E.8.i386.rpm tetex-latex-1.0.7-38.5E.8.i386.rpm tetex-xdvi-1.0.7-38.5E.8.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.ict.swin.edu.au/staff/jnewbigin