I need to be able to install CentOS 5.2 on a machine with software RAID (and LVM) setup. I discovered (the hard way!) that there is a bug in the mkinitrd package that causes it to enter an endless loop when there are /dev/mapper/ devices present during the install process. There is a patch to mkinitrd, which I applied and created a new rpm for mkinitrd with this patch applied. I'd like to now create a alternitive install CD, but I am not sure of the exact mkisofs command line to properly create a bootable CD.
I am also not sure if I need to update any of the files the installer uses to install the system -- is it enough to just drop the alternitive mkinitrd rpm? Do I need to rebuild any of the other files on the CD?
Robert Heller napsal(a):
I need to be able to install CentOS 5.2 on a machine with software RAID (and LVM) setup. I discovered (the hard way!) that there is a bug in the mkinitrd package that causes it to enter an endless loop when there are /dev/mapper/ devices present during the install process. There is a patch to mkinitrd, which I applied and created a new rpm for mkinitrd with this patch applied. I'd like to now create a alternitive install CD, but I am not sure of the exact mkisofs command line to properly create a bootable CD.
I am also not sure if I need to update any of the files the installer uses to install the system -- is it enough to just drop the alternitive mkinitrd rpm? Do I need to rebuild any of the other files on the CD?
Robert, go with Revisor http://fs12.vsb.cz/hrb33/el5/hrb/stable/i386/repodata/repoview/revisor-0-2.0... http://fs12.vsb.cz/hrb33/el5/hrb/stable/x86_64/repodata/repoview/revisor-0-2... David Hrbáč
At Fri, 06 Mar 2009 23:31:08 +0100 CentOS mailing list centos@centos.org wrote:
Robert Heller napsal(a):
I need to be able to install CentOS 5.2 on a machine with software RAID (and LVM) setup. I discovered (the hard way!) that there is a bug in the mkinitrd package that causes it to enter an endless loop when there are /dev/mapper/ devices present during the install process. There is a patch to mkinitrd, which I applied and created a new rpm for mkinitrd with this patch applied. I'd like to now create a alternitive install CD, but I am not sure of the exact mkisofs command line to properly create a bootable CD.
I am also not sure if I need to update any of the files the installer uses to install the system -- is it enough to just drop the alternitive mkinitrd rpm? Do I need to rebuild any of the other files on the CD?
Robert, go with Revisor http://fs12.vsb.cz/hrb33/el5/hrb/stable/i386/repodata/repoview/revisor-0-2.0... http://fs12.vsb.cz/hrb33/el5/hrb/stable/x86_64/repodata/repoview/revisor-0-2... David Hrbáč
This seems overly complex for my needs. I don't want (or need) to rebuild all 6 of the install CDs. I just want to *replace* one RPM on the first CD. I have copied the CD's directory tree to a writable file system and replaced the rpm in question. I now need to just make a new ISO file and all I need is the proper command line arguments to mkisofs to do this. I am *NOT* creating a new distribution. And I really don't want to mess with a complex GUI program or edit many configuration files.
I would also rather do this on my CentOS 4.7 system (revisor does not seem to be available for CentOS 4 / RHEL 4). Running it on a diskless workstation with a read-only root file system is a total pain. And will become even more painful when I then have to mount a large file system with NFS.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, 7 Mar 2009, Robert Heller wrote:
At Fri, 06 Mar 2009 23:31:08 +0100 CentOS mailing list centos@centos.org wrote:
I am also not sure if I need to update any of the files the installer uses to install the system -- is it enough to just drop the alternitive mkinitrd rpm? Do I need to rebuild any of the other files on the CD?
This seems overly complex for my needs. I don't want (or need) to rebuild all 6 of the install CDs. I just want to *replace* one RPM on the first CD.
This is the problem with people thinking a respin is just shuttling files in and out, or adding a driver to a mkinitrd.
In a post process, you can easily enough 'update' the one RPM in question with a bit of care in choosing the EVR information. Anaconda has provided for this in every CentOS release, and it usually suffices (adding install time drivers are the major exception). One can drop in anything that may be scripted -- the environment can be made Turing complete.
But then, _who_ is on the hook for maintaining and supporting such a respin? No intention for providing a yum archive for updates is stated; no attention is paid to ensure that 'authentic' SIGNED rpms would be retrieved. Who gets splashed with mud when things go wrong?
Assume there turns out to be a security hole in that package and it needs to be updated, or even worse worse if the re-spinner adds a package to drop in a "no key required" 'just a couple of files add-on' updates yum archive.
For the sake of analysis assume that the archive added then gets compromised. Or the re-spinner loses interest, and lets the domain lapse, and it gets picked up by a 'blackhat'. Or a DNS poisoning attack subverts resolution of the domain -- no signed package protection can raise the alarm. It was bypassed.
As I say, the customary bypass I have seen by minimal interest 'just change a couple of things' packagers and archives, is to wholly disable key checking for the archive they add. People regularly offer content from their personal archives. [I invite a self-audit, and would welcome a report of the last ten mentioned, to see if they are still viable (churning out updates), offering ONLY signed content with a well published signing key fingerprint, and issuing a yum.repo.d file requiring the packages used to be signed.]
So continuing the thought experiment, when so altered to trust an additional archive, the remote machines doing update through cron, or yum-updatesd will trust ANYTHING, including malicious content, placed in that compromised archive.
Game over.
Here is the fallout: The poor end user 'knows' it was CentOS, because she was told by the respinner that it is 'CentOS with just one package replaced'. Who gets the black eye here? Who bears the support load of sorting out what happened when the poor hurt user shows up in what she thinks is the correct support venue, barely able to describe her VOIP turnkey box's operation?
The answer is, of course, the main mother-ship CentOS project folks.
And it is not right that people do this to us, but it is also hard to stop. Probably the only real solution is to enforce the CentOS trademark on the art and brand packages, and prohibit respins containing such (just as the upstream does).
Sad, but true.
There is a reason the core CentOS group are skittish about respins. We'll have to discuss this seriously.
-- Russ herrold
R P Herrold wrote:
Here is the fallout: The poor end user 'knows' it was CentOS, because she was told by the respinner that it is 'CentOS with just one package replaced'. Who gets the black eye here? Who bears the support load of sorting out what happened when the poor hurt user shows up in what she thinks is the correct support venue, barely able to describe her VOIP turnkey box's operation?
The answer is, of course, the main mother-ship CentOS project folks.
And it is not right that people do this to us, but it is also hard to stop. Probably the only real solution is to enforce the CentOS trademark on the art and brand packages, and prohibit respins containing such (just as the upstream does).
Sad, but true.
There is a reason the core CentOS group are skittish about respins. We'll have to discuss this seriously.
I can see your point about the brand value you have embedded into the packages, but it also seems wrong to make everyone who wants to improve it or adapt to some additional purpose repeat all the rebranding work from scratch.
How hard would it be to generate an 'unbranded' drop in replacement package for everything specifically Centos - or a framework so others could share the work? That way everyone who needed to replace a driver wouldn't have to repeat all this work unless they wanted to create their own unique brand identity.
If you think respins containing Centos branding are wrong, make it easy to to the right thing.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Les Mikesell Sent: Saturday, March 07, 2009 17:59 To: CentOS mailing list Subject: Re: [CentOS] Creating an alternitive install CD for CentOS 5.2 (w/ patched mkinitrd)
R P Herrold wrote:
Here is the fallout: The poor end user 'knows' it was
CentOS, because
she was told by the respinner that it is 'CentOS with just
one package
replaced'. Who gets the black eye here? Who bears the support load of sorting out what happened
when the poor
hurt user shows up in what she thinks is the correct support venue, barely able to describe her VOIP turnkey box's operation?
The answer is, of course, the main mother-ship CentOS project folks.
And it is not right that people do this to us, but it is
also hard to
stop. Probably the only real solution is to enforce the CentOS trademark on the art and brand packages, and prohibit respins containing such (just as the upstream does).
Sad, but true.
There is a reason the core CentOS group are skittish about
respins.
We'll have to discuss this seriously.
I can see your point about the brand value you have embedded into the packages, but it also seems wrong to make everyone who wants to improve it or adapt to some additional purpose repeat all the rebranding work from scratch.
How hard would it be to generate an 'unbranded' drop in replacement package for everything specifically Centos - or a framework so others could share the work? That way everyone who needed to replace a driver wouldn't have to repeat all this work unless they wanted to create their own unique brand identity.
Kinky idea, I like it.
If you think respins containing Centos branding are wrong, make it easy to to the right thing.
-- Les Mikesell lesmikesell@gmail.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
At Sat, 07 Mar 2009 11:59:02 -0600 CentOS mailing list centos@centos.org wrote:
R P Herrold wrote:
Here is the fallout: The poor end user 'knows' it was CentOS, because she was told by the respinner that it is 'CentOS with just one package replaced'. Who gets the black eye here? Who bears the support load of sorting out what happened when the poor hurt user shows up in what she thinks is the correct support venue, barely able to describe her VOIP turnkey box's operation?
The answer is, of course, the main mother-ship CentOS project folks.
And it is not right that people do this to us, but it is also hard to stop. Probably the only real solution is to enforce the CentOS trademark on the art and brand packages, and prohibit respins containing such (just as the upstream does).
Sad, but true.
There is a reason the core CentOS group are skittish about respins. We'll have to discuss this seriously.
I can see your point about the brand value you have embedded into the packages, but it also seems wrong to make everyone who wants to improve it or adapt to some additional purpose repeat all the rebranding work from scratch.
Or deal with a 'show stopping bug', like the known problem with mkinitrd. I have no interest in rebranding anything or even redistributing my 'replacement' CD (I'll probably toss the replacement CD once I get the install done). I just want to install CentOS on a system with pre-existing software RAID disks -- I am migrating a server from Ubuntu to CentOS 5 and I don't want to lose prexisting data, so simply wiping the disks and installing on bare partitions is not an option (and even then I'd want to use LVM for some things, and even without RAID, LVM will also send mkinitrd off into never, never land -- basically anything the fires up /dev/mapper/... will do it: RAID, LVM, cryptfs, all seem to do this).
How hard would it be to generate an 'unbranded' drop in replacement package for everything specifically Centos - or a framework so others could share the work? That way everyone who needed to replace a driver wouldn't have to repeat all this work unless they wanted to create their own unique brand identity.
If you think respins containing Centos branding are wrong, make it easy to to the right thing.
Robert Heller wrote:
At Sat, 07 Mar 2009 11:59:02 -0600 CentOS mailing list centos@centos.org wrote:
R P Herrold wrote:
Here is the fallout: The poor end user 'knows' it was CentOS, because she was told by the respinner that it is 'CentOS with just one package replaced'. Who gets the black eye here? Who bears the support load of sorting out what happened when the poor hurt user shows up in what she thinks is the correct support venue, barely able to describe her VOIP turnkey box's operation?
The answer is, of course, the main mother-ship CentOS project folks.
And it is not right that people do this to us, but it is also hard to stop. Probably the only real solution is to enforce the CentOS trademark on the art and brand packages, and prohibit respins containing such (just as the upstream does).
Sad, but true.
There is a reason the core CentOS group are skittish about respins. We'll have to discuss this seriously.
I can see your point about the brand value you have embedded into the packages, but it also seems wrong to make everyone who wants to improve it or adapt to some additional purpose repeat all the rebranding work from scratch.
Or deal with a 'show stopping bug', like the known problem with mkinitrd. I have no interest in rebranding anything or even redistributing my 'replacement' CD (I'll probably toss the replacement CD once I get the install done). I just want to install CentOS on a system with pre-existing software RAID disks -- I am migrating a server from Ubuntu to CentOS 5 and I don't want to lose prexisting data, so simply wiping the disks and installing on bare partitions is not an option (and even then I'd want to use LVM for some things, and even without RAID, LVM will also send mkinitrd off into never, never land -- basically anything the fires up /dev/mapper/... will do it: RAID, LVM, cryptfs, all seem to do this).
How hard would it be to generate an 'unbranded' drop in replacement package for everything specifically Centos - or a framework so others could share the work? That way everyone who needed to replace a driver wouldn't have to repeat all this work unless they wanted to create their own unique brand identity.
If you think respins containing Centos branding are wrong, make it easy to to the right thing.
tried nodmraid on the kernel boot line?
At Sat, 07 Mar 2009 18:44:46 -0500 CentOS mailing list centos@centos.org wrote:
Robert Heller wrote:
At Sat, 07 Mar 2009 11:59:02 -0600 CentOS mailing list centos@centos.org wrote:
R P Herrold wrote:
Here is the fallout: The poor end user 'knows' it was CentOS, because she was told by the respinner that it is 'CentOS with just one package replaced'. Who gets the black eye here? Who bears the support load of sorting out what happened when the poor hurt user shows up in what she thinks is the correct support venue, barely able to describe her VOIP turnkey box's operation?
The answer is, of course, the main mother-ship CentOS project folks.
And it is not right that people do this to us, but it is also hard to stop. Probably the only real solution is to enforce the CentOS trademark on the art and brand packages, and prohibit respins containing such (just as the upstream does).
Sad, but true.
There is a reason the core CentOS group are skittish about respins. We'll have to discuss this seriously.
I can see your point about the brand value you have embedded into the packages, but it also seems wrong to make everyone who wants to improve it or adapt to some additional purpose repeat all the rebranding work from scratch.
Or deal with a 'show stopping bug', like the known problem with mkinitrd. I have no interest in rebranding anything or even redistributing my 'replacement' CD (I'll probably toss the replacement CD once I get the install done). I just want to install CentOS on a system with pre-existing software RAID disks -- I am migrating a server from Ubuntu to CentOS 5 and I don't want to lose prexisting data, so simply wiping the disks and installing on bare partitions is not an option (and even then I'd want to use LVM for some things, and even without RAID, LVM will also send mkinitrd off into never, never land -- basically anything the fires up /dev/mapper/... will do it: RAID, LVM, cryptfs, all seem to do this).
How hard would it be to generate an 'unbranded' drop in replacement package for everything specifically Centos - or a framework so others could share the work? That way everyone who needed to replace a driver wouldn't have to repeat all this work unless they wanted to create their own unique brand identity.
If you think respins containing Centos branding are wrong, make it easy to to the right thing.
tried nodmraid on the kernel boot line?
The problem is that I need to actually install on the raid arrays, so this isn't an option either.
begin:vcard fn:Rob Kampen n:Kampen;Rob email;internet:rkampen@kampensonline.com x-mozilla-html:TRUE version:2.1 end:vcard
MIME-Version: 1.0
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, 7 Mar 2009, Les Mikesell wrote:
If you think respins containing Centos branding are wrong, make it easy to to the right thing.
Thanks for offering to have me do work for something I don't consider a core (or really, a desireable) goal, Les --- I can always count on you to ask others to do things rather than taking a swing at them your self and documenting results.
I had you in mind writing an uppdate on the 5.3 freshening. http://orcorc.blogspot.com/2009/03/nine-pregnant-gals-in-queue.html
-- Russ herrold
R P Herrold wrote:
On Sat, 7 Mar 2009, Les Mikesell wrote:
If you think respins containing Centos branding are wrong, make it easy to to the right thing.
Thanks for offering to have me do work for something I don't consider a core (or really, a desireable) goal,
I did suggest a framework for others to help...
Les --- I can always count on you to ask others to do things rather than taking a swing at them your self and documenting results.
I just find it somewhat ironic that you would not have a product without reusing the work of others, yet you want to make it difficult for others to reuse your unique parts in the same way. People doing open source work often generalize their changes to make them reusable in other situations.
I had you in mind writing an uppdate on the 5.3 freshening. http://orcorc.blogspot.com/2009/03/nine-pregnant-gals-in-queue.html
My name might still be buried from long ago in a few of the things you redistribute.
At Sat, 7 Mar 2009 10:45:19 -0500 (EST) CentOS mailing list centos@centos.org wrote:
On Sat, 7 Mar 2009, Robert Heller wrote:
At Fri, 06 Mar 2009 23:31:08 +0100 CentOS mailing list centos@centos.org wrote:
I am also not sure if I need to update any of the files the installer uses to install the system -- is it enough to just drop the alternitive mkinitrd rpm? Do I need to rebuild any of the other files on the CD?
This seems overly complex for my needs. I don't want (or need) to rebuild all 6 of the install CDs. I just want to *replace* one RPM on the first CD.
This is the problem with people thinking a respin is just shuttling files in and out, or adding a driver to a mkinitrd.
In a post process, you can easily enough 'update' the one RPM in question with a bit of care in choosing the EVR information. Anaconda has provided for this in every CentOS release, and it usually suffices (adding install time drivers are the major exception). One can drop in anything that may be scripted -- the environment can be made Turing complete.
The problem is that the mkinitrd rpm that is shipped with CentOS 5.2 *go into an infinite loop* if one is installing a kernel on a system with software raid disks. This means that the base install process *hangs*. I suspect that killing the looping mkinitrd process kills (crashes) the install. This means it is impossible to do a base install this way. *This is a known problem* (check the bug database for both RHEL5 and CentOS5 for details).
The only other option is to patch the mkinitrd script *while* the install is in progress. I ended up doing this when I originally installed CentOS 5.2, but mis-typed the patch command and ended up with a zero length file in /sbin/mkinitrd -- this did not cause the installer to crash, it just failed to make the initrd file -- not really a problem -- I just booted with a rescue disk and manually re-made the initrd (and it was only a secondard O/S on my system and I had told the installer to not install any boot loader).
But then, _who_ is on the hook for maintaining and supporting such a respin? No intention for providing a yum archive for updates is stated; no attention is paid to ensure that 'authentic' SIGNED rpms would be retrieved. Who gets splashed with mud when things go wrong?
Assume there turns out to be a security hole in that package and it needs to be updated, or even worse worse if the re-spinner adds a package to drop in a "no key required" 'just a couple of files add-on' updates yum archive.
For the sake of analysis assume that the archive added then gets compromised. Or the re-spinner loses interest, and lets the domain lapse, and it gets picked up by a 'blackhat'. Or a DNS poisoning attack subverts resolution of the domain -- no signed package protection can raise the alarm. It was bypassed.
As I say, the customary bypass I have seen by minimal interest 'just change a couple of things' packagers and archives, is to wholly disable key checking for the archive they add. People regularly offer content from their personal archives. [I invite a self-audit, and would welcome a report of the last ten mentioned, to see if they are still viable (churning out updates), offering ONLY signed content with a well published signing key fingerprint, and issuing a yum.repo.d file requiring the packages used to be signed.]
So continuing the thought experiment, when so altered to trust an additional archive, the remote machines doing update through cron, or yum-updatesd will trust ANYTHING, including malicious content, placed in that compromised archive.
Game over.
Here is the fallout: The poor end user 'knows' it was CentOS, because she was told by the respinner that it is 'CentOS with just one package replaced'. Who gets the black eye here? Who bears the support load of sorting out what happened when the poor hurt user shows up in what she thinks is the correct support venue, barely able to describe her VOIP turnkey box's operation?
The answer is, of course, the main mother-ship CentOS project folks.
And it is not right that people do this to us, but it is also hard to stop. Probably the only real solution is to enforce the CentOS trademark on the art and brand packages, and prohibit respins containing such (just as the upstream does).
Sad, but true.
There is a reason the core CentOS group are skittish about respins. We'll have to discuss this seriously.
-- Russ herrold _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, Mar 7, 2009 at 10:08 AM, Robert Heller heller@deepsoft.com wrote
This seems overly complex for my needs. I don't want (or need) to rebuild all 6 of the install CDs. I just want to *replace* one RPM on the first CD. I have copied the CD's directory tree to a writable file system and replaced the rpm in question. I now need to just make a new ISO file and all I need is the proper command line arguments to mkisofs to do this. I am *NOT* creating a new distribution. And I really don't want to mess with a complex GUI program or edit many configuration files.
I would also rather do this on my CentOS 4.7 system (revisor does not seem to be available for CentOS 4 / RHEL 4). Running it on a diskless workstation with a read-only root file system is a total pain. And will become even more painful when I then have to mount a large file system with NFS.
First of all, if you replace an RPM, you'll need to do createrepro.
disc_info=`head -1 $BASE/$ARCH/.discinfo` createrepo -v --baseurl="$disc_info" -g repodata/comps.xml $ARCH
If the RPM is a "system RPM", then you probably want to do a buildinstall first to get it into the anaconda system (and get a new disc_info), a la:
$BASE/buildinstall --debug \ --version 5 --product 'CentOS' --release "CentOS 5" \ --prodpath CentOS $BASE/$ARCH 2>&1
If all you want is a mkisofs, what's wrong with the "man" command??
Maybe something like:
mkisofs -q -r -R -J -T -no-emul-boot -boot-load-size 4 -pad \ -b isolinux/isolinux.bin -c isolinux/boot.cat -boot-info-table \ -V "$VER ($date)" \ -A "$REL - $VER - $firmware" \ -publisher "$PUB" -p "$PUB" -x lost+found \ -o "CentOS-$VER-$date.iso" $ARCH 2>&1
... reboot, lather, rinse and repeat .... :-) :=)
You may find "re-generating" the CentOS CDs/DVD quite easy at times and very frustrating and complex at others ......
HTH
-rak-
At Sat, 7 Mar 2009 10:48:29 -0500 CentOS mailing list centos@centos.org wrote:
On Sat, Mar 7, 2009 at 10:08 AM, Robert Heller heller@deepsoft.com wrote
This seems overly complex for my needs. I don't want (or need) to rebuild all 6 of the install CDs. I just want to *replace* one RPM on the first CD. I have copied the CD's directory tree to a writable file system and replaced the rpm in question. I now need to just make a new ISO file and all I need is the proper command line arguments to mkisofs to do this. I am *NOT* creating a new distribution. And I really don't want to mess with a complex GUI program or edit many configuration files.
I would also rather do this on my CentOS 4.7 system (revisor does not seem to be available for CentOS 4 / RHEL 4). Running it on a diskless workstation with a read-only root file system is a total pain. And will become even more painful when I then have to mount a large file system with NFS.
First of all, if you replace an RPM, you'll need to do createrepro.
disc_info=`head -1 $BASE/$ARCH/.discinfo` createrepo -v --baseurl="$disc_info" -g repodata/comps.xml $ARCH
OK, it looks like I need to do this (see below).
If the RPM is a "system RPM", then you probably want to do a buildinstall first to get it into the anaconda system (and get a new disc_info), a la:
$BASE/buildinstall --debug \--version 5 --product 'CentOS' --release "CentOS 5" \ --prodpath CentOS $BASE/$ARCH 2>&1
If all you want is a mkisofs, what's wrong with the "man" command??
Maybe something like:
mkisofs -q -r -R -J -T -no-emul-boot -boot-load-size 4 -pad \ -b isolinux/isolinux.bin -c isolinux/boot.cat -boot-info-table \ -V "$VER ($date)" \ -A "$REL - $VER - $firmware" \ -publisher "$PUB" -p "$PUB" -x lost+found \ -o "CentOS-$VER-$date.iso" $ARCH 2>&1
I was unsure of the specific options above -- After installing revisor and poked around in the source code and found what I needed, but my test install failed -- it complained that there was a problem with mkinitrd -- could not open it or find it -- guessing I need to rebuild the repro database.
... reboot, lather, rinse and repeat .... :-) :=)
You may find "re-generating" the CentOS CDs/DVD quite easy at times and very frustrating and complex at others ......
Yeah, it appears so. I just hope I don't have to rebuild all 6 CDs, since I don't have the DVD nor do I have a DVD-R drive either, so doing things with a single DVD is not an option.
HTH
-rak- _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, Mar 7, 2009 at 2:34 PM, Robert Heller heller@deepsoft.com wrote: .....
I was unsure of the specific options above -- After installing revisor and poked around in the source code and found what I needed, but my test install failed -- it complained that there was a problem with mkinitrd -- could not open it or find it -- guessing I need to rebuild the repro database.
... reboot, lather, rinse and repeat .... :-) :=)
You may find "re-generating" the CentOS CDs/DVD quite easy at times and very frustrating and complex at others ......
Yeah, it appears so. I just hope I don't have to rebuild all 6 CDs, since I don't have the DVD nor do I have a DVD-R drive either, so doing things with a single DVD is not an option.
Last time I added a DVD burner to my Build system, it cost $29 (USD) and this was for a very good, reliable unit. Not worth my time and immense hassle to do otherwise ....
As for ...
could not open it or find it -- guessing I need to rebuild the repro database.
What about:
First of all, if you replace an RPM, you'll need to do createrepro.
What isn't clear?? As "need to" means **MUST**.... <hmmmm>. Why did you even make an attempt without the createrepro command?? Two to three minutes of your time wasn't worth it (but taking our time is, of course) :-):-) ...
While I believe your bug reports, I install CentOS on RAID + LVM everyday without any problems, private kernel patches, etc. -- as a counter-example.
Now, let's see if we understand the situation clearly:
1. This is a "one-time" conversion (will "throw the CD away when done") ...
2. You're migrating a system from Ubuntu to CentOS (e.g., a different version / patch level of LVM + RAID) and *hope* to keep data consistency and reliability ...
3. You have a backup of this precious data, yes / no?? If no, eegaddss....
4. So, why not just do a wipe + fresh install and reload the data???
Now how much time have you spent on this "project" so far?? I believe the above would be done 2 to 3x times over by now ....
Plus, you've found out that it is a lot more than "just a mkisofs command with a few arguments" (and that you have to follow instructions precisely or things just don't WORK(tm)).
Hmmmm....
-rak-
Richard Karhuse wrote:
Last time I added a DVD burner to my Build system, it cost $29 (USD) and this was for a very good, reliable unit. Not worth my time and immense hassle to do otherwise ....
indeed. Samsung 22X DVD-R burner, SATA for $25 http://www.newegg.com/Product/Product.aspx?Item=N82E16827151173
IDE for $23 http://www.newegg.com/Product/Product.aspx?Item=N82E16827151175
those are very reliable, fast, and good drives. My previous DVD burners, including a Lite-On, a TDK, and a Pioneer, took much longer to 'recognize' a new disk, whether it was blank, factory recorded, or dvd-r, the samsung picks it up in a second. The burns I've made from this drive read reliably on a wide range of equipment, even if I burn at CAV (16X) instead of CLV (<= 8x).
Note my experience has been that the average life expectancy of a dvd burner is about 400-500 full disk burns, after that they seem to get increasingly flakey. my current Samsung is on its third tub of 100 blanks.
On 3/8/09, John R Pierce pierce@hogranch.com wrote:
Richard Karhuse wrote:
Last time I added a DVD burner to my Build system, it cost $29 (USD) and this was for a very good, reliable unit. Not worth my time and immense hassle to do otherwise ....
indeed. Samsung 22X DVD-R burner, SATA for $25 http://www.newegg.com/Product/Product.aspx?Item=N82E16827151173
IDE for $23 http://www.newegg.com/Product/Product.aspx?Item=N82E16827151175
those are very reliable, fast, and good drives. My previous DVD burners, including a Lite-On, a TDK, and a Pioneer, took much longer to 'recognize' a new disk, whether it was blank, factory recorded, or dvd-r, the samsung picks it up in a second. The burns I've made from this drive read reliably on a wide range of equipment, even if I burn at CAV (16X) instead of CLV (<= 8x).
Note my experience has been that the average life expectancy of a dvd burner is about 400-500 full disk burns, after that they seem to get increasingly flakey. my current Samsung is on its third tub of 100 blanks.
In December and January, I bought 2 LG (IDE) DVD burners, in Cali, Colombia, for less than USD$35 each, which includes tax. They both work well. Previously bought TEAC drives, but someone on the list suggested LG instead. John, do you have any experience with the reliability of LG drives, in addition to your experience with the Samsung drives?
Lanny Marcus wrote:
In December and January, I bought 2 LG (IDE) DVD burners, in Cali, Colombia, for less than USD$35 each, which includes tax. They both work well. Previously bought TEAC drives, but someone on the list suggested LG instead. John, do you have any experience with the reliability of LG drives, in addition to your experience with the Samsung drives?
I don't have any personal experience, but the buzz I've heard indicates LG stuff has generally been quite good. A few years ago, Lite-On was considered a very good brand, but of late their QC has slipped per various anecdotal reports.
At Sun, 8 Mar 2009 08:47:50 -0400 CentOS mailing list centos@centos.org wrote:
On Sat, Mar 7, 2009 at 2:34 PM, Robert Heller heller@deepsoft.com wrote: .....
I was unsure of the specific options above -- After installing revisor and poked around in the source code and found what I needed, but my test install failed -- it complained that there was a problem with mkinitrd -- could not open it or find it -- guessing I need to rebuild the repro database.
... reboot, lather, rinse and repeat .... :-) :=)
You may find "re-generating" the CentOS CDs/DVD quite easy at times and very frustrating and complex at others ......
Yeah, it appears so. I just hope I don't have to rebuild all 6 CDs, since I don't have the DVD nor do I have a DVD-R drive either, so doing things with a single DVD is not an option.
Last time I added a DVD burner to my Build system, it cost $29 (USD) and this was for a very good, reliable unit. Not worth my time and immense hassle to do otherwise ....
As for ...
could not open it or find it -- guessing I need to rebuild the repro database.
What about:
First of all, if you replace an RPM, you'll need to do createrepro.
What isn't clear?? As "need to" means **MUST**.... <hmmmm>. Why did you even make an attempt without the createrepro command?? Two to three minutes of your time wasn't worth it (but taking our time is, of course) :-):-) ...
I did not even know about the createrepro command!
While I believe your bug reports, I install CentOS on RAID + LVM everyday without any problems, private kernel patches, etc. -- as a counter-example.
Did you *specificly* install CentOS 5.2 (as opposed to 5.1 or 4.7? Do you want the URLs of of the CentOS 5.2 & RHEL 5.2 bug reports? Did you install onto bare partitions and then migrate to RAID and/or LVM later? Note this is *software RAID*, not hardware RAID.
Now, let's see if we understand the situation clearly:
This is a "one-time" conversion (will "throw the CD away when done") ...
You're migrating a system from Ubuntu to CentOS (e.g., a different version / patch level of LVM + RAID) and *hope* to keep data consistency and reliability ...
You have a backup of this precious data, yes / no?? If no, eegaddss....
So, why not just do a wipe + fresh install and reload the data???
I want the option of falling back to the existing (working) Ubuntu system, in case there are problems with the CentOS setup. Right now, this is for a small (and relatively impoverished) small town library. The original setup (done by someone else who does not have the time, etc. to deal with it) uses LTSP and diskless thin clients. While this works, there are some performance issues. Because the LTSP uses the 'PC's as pretty much bare X Terminals, this means all of the real 'work' is done on the server itself. With several people working, often kids and teens playing Flash games and maybe one or two people using Open Office, the server litterally runs out of RAM and starts swapping, which slows everything down. I want to set up a slighter thicker clients using NFS mounted file systems in hopes that this will work better.
There is a backup process in place, but it has not been working lately, since there seems to be a problem with sshd on the external server. Even if it was working it might be problematical to restore it anyway because of the rather funcky internet connection we have (HughesNet satelite dishes -- nothing better is available here in the wilds of Western Mass).
The main reason for moving from Ubuntu to CentOS is that I am much more familar / confortable with RedHat flavored systems. Ubuntu seems to have more 'magical' things going on, which I could not figure out. I think Ubuntu tries to be overly 'helpful', which might be nice for some users and probably makes more sense for home desktop users, but was just frustating for someone trying to do some 'outside of the box' things.
Now how much time have you spent on this "project" so far?? I believe the above would be done 2 to 3x times over by now ....
Plus, you've found out that it is a lot more than "just a mkisofs command with a few arguments" (and that you have to follow instructions precisely or things just don't WORK(tm)).
Hmmmm....
-rak- _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Robert Heller wrote:
I don't want (or need) to rebuild all 6 of the install CDs. I just want to *replace* one RPM on the first CD.
the installer supports external repo's - at install time. All you then need is to provide a new repo, with a higher EVR for mkinitrd.
At Sat, 07 Mar 2009 19:39:00 +0000 CentOS mailing list centos@centos.org wrote:
Robert Heller wrote:
I don't want (or need) to rebuild all 6 of the install CDs. I just want to *replace* one RPM on the first CD.
the installer supports external repo's - at install time. All you then need is to provide a new repo, with a higher EVR for mkinitrd.
I am not sure how to do this and did not know it was possible -- there is nothing obvious in the install menus that suggest this. I do prefer the 'text' based install. Also, in the case of my home system, the external repo would *have* be on the local disk somewhere, since I don't have any other machines available on my LAN and the the only external Internet option is dialup.
On Sat, Mar 7, 2009 at 5:16 AM, Robert Heller heller@deepsoft.com wrote:
I need to be able to install CentOS 5.2 on a machine with software RAID (and LVM) setup. I discovered (the hard way!) that there is a bug in the mkinitrd package that causes it to enter an endless loop when there are /dev/mapper/ devices present during the install process. There is a patch to mkinitrd, which I applied and created a new rpm for mkinitrd with this patch applied. I'd like to now create a alternitive install CD, but I am not sure of the exact mkisofs command line to properly create a bootable CD.
I am also not sure if I need to update any of the files the installer uses to install the system -- is it enough to just drop the alternitive mkinitrd rpm? Do I need to rebuild any of the other files on the CD?
Dumb suggestion: Can't you use isomaster or any of those iso editor tools to replace that one file? :)
-
David Hrbáč -
Fajar Priyanto -
Jason Pyeron -
John R Pierce -
Karanbir Singh -
Lanny Marcus -
Les Mikesell -
R P Herrold -
Richard Karhuse -
Rob Kampen -
Robert Heller