I am interested in generating a spin of CentOS 7, but I'm having trouble identifying the correct tool to compose an ISO image.
I've done some searching, and tried a number of different tools, such as livemedia-creator, livecd-tools, pungi, and so on, but it is not obvious which is the preferred tool.
What tool should I use to compose a spin of CentOS 7?
Also, I'm curious if the official images (such as CentOS-7.0-1406-x86_64-NetInstall.iso) are composed with the same tool, or if there is a different tool that I would use to compose that type of image.
In other words, is everything essentially a live image today or are there different tools to compose a live image versus the official installation DVDs?
Steve
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
On 10/28/2014 10:49 AM, Steven Falco wrote:
I am interested in generating a spin of CentOS 7, but I'm having trouble identifying the correct tool to compose an ISO image.
For what reason? Is this something that would benefit others (could/Should it be a sig?)
I've done some searching, and tried a number of different tools, such as livemedia-creator, livecd-tools, pungi, and so on, but it is not obvious which is the preferred tool.
What tool should I use to compose a spin of CentOS 7?
Depends on what you're doing.
Also, I'm curious if the official images (such as CentOS-7.0-1406-x86_64-NetInstall.iso) are composed with the same tool, or if there is a different tool that I would use to compose that type of image.
In other words, is everything essentially a live image today or are there different tools to compose a live image versus the official installation DVDs?
The live images are done with livecd-tools. The install images are done the old way with mkisofs I believe. We're in the process of adding imagefactory to the community builders, so if you wanted to do this as a SIG, you'd be able to crank out images in a semi-automated fashion.
On 10/30/2014 10:59 AM, Jim Perrin wrote:
On 10/28/2014 10:49 AM, Steven Falco wrote:
I am interested in generating a spin of CentOS 7, but I'm having trouble identifying the correct tool to compose an ISO image.
For what reason? Is this something that would benefit others (could/Should it be a sig?)
I have been asked to create a customized install DVD that would automatically install - i.e. use a custom kickstart file. To do that, I would add the ks file to the isolinux directory, and patch isolinux.cfg to pass my ks file to anaconda via the kernel cmd line.
I can do that manually by manipulating the official iso file. It is a lengthy series of steps, extracting the squashfs.img file, then the rootfs.img, then making my changes, and finally putting everything back together. In short, a total kludge. :-)
Instead, I'd like to be able to reproduce the method by which the official iso file is constructed. I'd want to be able to do that on my local machine rather than using any CentOS resources, because I don't think this particular spin would be of any interest to the community. However, the method of generating a custom DVD probably would be of interest to a lot of people.
I've actually made a fair amount of progress in the last few days. First, I used pungi to reconstruct a Fedora 20 iso which taught me how that process works. It also gave me a good log file of a successful pungi build.
Then, I tried making that same process work on CentOS 7. I ran into some issues, because the c7 kernel doesn't include HFSPLUS support (which is needed by isohybrid - long story).
I hacked around that by modifying some parts of pungi and lorax to remove the HFSPLUS requirement. I am also exploring building the HFSPLUS kernel module, so I don't have to hack up pungi / lorax.
But back to my question to this list. Are the pungi and lorax tools part of the official CentOS build process? If so, then I assume there must be customized version of them, given the problems I saw with HFSPLUS.
If different tools are used instead of pungi / lorax, then what are those tools? Are they documented? Can I help with the documentation of them?
Steve
On 10/30/2014 10:28 AM, Steven Falco wrote:
On 10/30/2014 10:59 AM, Jim Perrin wrote:
On 10/28/2014 10:49 AM, Steven Falco wrote:
I am interested in generating a spin of CentOS 7, but I'm having trouble identifying the correct tool to compose an ISO image.
For what reason? Is this something that would benefit others (could/Should it be a sig?)
I have been asked to create a customized install DVD that would automatically install - i.e. use a custom kickstart file. To do that, I would add the ks file to the isolinux directory, and patch isolinux.cfg to pass my ks file to anaconda via the kernel cmd line.
I can do that manually by manipulating the official iso file. It is a lengthy series of steps, extracting the squashfs.img file, then the rootfs.img, then making my changes, and finally putting everything back together. In short, a total kludge. :-)
Sounds mostly like the officially documented procedure from 4/5/6 that's been in place for a while. In my opinion it's a terrible way to do things, and I much prefer pxe and networked installs as you get updates, avoid rebuilding media, etc.
Instead, I'd like to be able to reproduce the method by which the official iso file is constructed. I'd want to be able to do that on my local machine rather than using any CentOS resources, because I don't think this particular spin would be of any interest to the community. However, the method of generating a custom DVD probably would be of interest to a lot of people.
I've actually made a fair amount of progress in the last few days. First, I used pungi to reconstruct a Fedora 20 iso which taught me how that process works. It also gave me a good log file of a successful pungi build.
Then, I tried making that same process work on CentOS 7. I ran into some issues, because the c7 kernel doesn't include HFSPLUS support (which is needed by isohybrid - long story).
I hacked around that by modifying some parts of pungi and lorax to remove the HFSPLUS requirement. I am also exploring building the HFSPLUS kernel module, so I don't have to hack up pungi / lorax.
But back to my question to this list. Are the pungi and lorax tools part of the official CentOS build process? If so, then I assume there must be customized version of them, given the problems I saw with HFSPLUS.
As I said, no. They're not used for the install isos currently.
If different tools are used instead of pungi / lorax, then what are those tools? Are they documented? Can I help with the documentation of them?
As I said, the install media is currently done via mkisofs. I don't believe it's currently documented. The comps data is on git.centos.org, along with the kickstarts for the live media.
You're certainly welcome to create documentation. If you request access on the -docs list with your proposal, the people who oversee wiki access will work with you.
On 10/30/2014 11:51 AM, Jim Perrin wrote:
On 10/30/2014 10:28 AM, Steven Falco wrote:
On 10/30/2014 10:59 AM, Jim Perrin wrote:
On 10/28/2014 10:49 AM, Steven Falco wrote:
I am interested in generating a spin of CentOS 7, but I'm having trouble identifying the correct tool to compose an ISO image.
For what reason? Is this something that would benefit others (could/Should it be a sig?)
I have been asked to create a customized install DVD that would automatically install - i.e. use a custom kickstart file. To do that, I would add the ks file to the isolinux directory, and patch isolinux.cfg to pass my ks file to anaconda via the kernel cmd line.
I can do that manually by manipulating the official iso file. It is a lengthy series of steps, extracting the squashfs.img file, then the rootfs.img, then making my changes, and finally putting everything back together. In short, a total kludge. :-)
Sounds mostly like the officially documented procedure from 4/5/6 that's been in place for a while. In my opinion it's a terrible way to do things, and I much prefer pxe and networked installs as you get updates, avoid rebuilding media, etc.
You mention 4/5/6, but I'm trying to do this with 7, which I gather has not been documented yet, based on your comments below. I'll follow your suggestion and get in touch with the folks on the docs list to see if there is a way I can help out.
As to pxe / network, I agree that that is better in most cases, and while I can do that locally, it would be impossible with remote sites that lack decent connectivity. They will need physical media.
Regarding mkisofs, I think there has to be more to it than that. For example, something has to create the LiveOS filesystem, before the DVD image can be created by mkisofs. That is the part I'm hunting for.
Instead, I'd like to be able to reproduce the method by which the official iso file is constructed. I'd want to be able to do that on my local machine rather than using any CentOS resources, because I don't think this particular spin would be of any interest to the community. However, the method of generating a custom DVD probably would be of interest to a lot of people.
I've actually made a fair amount of progress in the last few days. First, I used pungi to reconstruct a Fedora 20 iso which taught me how that process works. It also gave me a good log file of a successful pungi build.
Then, I tried making that same process work on CentOS 7. I ran into some issues, because the c7 kernel doesn't include HFSPLUS support (which is needed by isohybrid - long story).
I hacked around that by modifying some parts of pungi and lorax to remove the HFSPLUS requirement. I am also exploring building the HFSPLUS kernel module, so I don't have to hack up pungi / lorax.
But back to my question to this list. Are the pungi and lorax tools part of the official CentOS build process? If so, then I assume there must be customized version of them, given the problems I saw with HFSPLUS.
As I said, no. They're not used for the install isos currently.
If different tools are used instead of pungi / lorax, then what are those tools? Are they documented? Can I help with the documentation of them?
As I said, the install media is currently done via mkisofs. I don't believe it's currently documented. The comps data is on git.centos.org, along with the kickstarts for the live media.
You're certainly welcome to create documentation. If you request access on the -docs list with your proposal, the people who oversee wiki access will work with you.
Previously:
I have been asked to create a customized install DVD that would automatically install - i.e. use a custom kickstart file. To do that, I would add the ks file to the isolinux directory, and patch isolinux.cfg to pass my ks file to anaconda via the kernel cmd line.
And:
As to pxe / network, I agree that that is better in most cases, and while I can do that locally, it would be impossible with remote sites that lack decent connectivity. They will need physical media.
I too am working on a custom install. I need to be able to send a self-contained disc to a site that has no Internet connection and limited technical support. I want the local person to be able to boot from the disc and select the install from a menu.
In this case, I don't care about making a custom kernel; I'm looking for an easier way to manage the RPM repository and the comps.xml file. Why? Well, I need to make as much room on the installer disc as I can for our custom applications, while still including everything needed for a functioning system.
I've tried the "minimal" install disc, but it just doesn't have everything we need, so I have been copying RPMs from the full install and manually editing the comps.xml, then running repoclosure, verifytree, etc. Is there an easier way?
Regards, Doug
On Thu, Oct 30, 2014 at 1:41 PM, Doug Wellington ddw@rincon.com wrote:
Previously:
I have been asked to create a customized install DVD that would automatically install - i.e. use a custom kickstart file. To do that, I would add the ks file to the isolinux directory, and patch isolinux.cfg to pass my ks file to anaconda via the kernel cmd line.
And:
As to pxe / network, I agree that that is better in most cases, and while I can do that locally, it would be impossible with remote sites that lack decent connectivity. They will need physical media.
I too am working on a custom install. I need to be able to send a self-contained disc to a site that has no Internet connection and limited technical support. I want the local person to be able to boot from the disc and select the install from a menu.
In this case, I don't care about making a custom kernel; I'm looking for an easier way to manage the RPM repository and the comps.xml file. Why? Well, I need to make as much room on the installer disc as I can for our custom applications, while still including everything needed for a functioning system.
I've tried the "minimal" install disc, but it just doesn't have everything we need, so I have been copying RPMs from the full install and manually editing the comps.xml, then running repoclosure, verifytree, etc. Is there an easier way?
Might be simpler in the long run to make it a 2-step process. That is, do a minimal OS install, then have a 2nd DVD or USB key that they install after the base system with a script that upgrades any existing rpms and installs the rest of what you need. The 2nd step can then be repeated as necessary for os and application updates.
Previously:
Might be simpler in the long run to make it a 2-step process. That is, do a minimal OS install, then have a 2nd DVD or USB key that they install after the base system with a script that upgrades any existing rpms and installs the rest of what you need.
That adds an interesting set of questions. Do I somehow try to get the postinstall script to prompt for it? Do I try to create something similar to firstboot that would prompt for the second disc after the reboot? Do I just list it in the install docs? Right now the install docs are "1) Boot from DVD; 2) Choose system from menu." I'd like to keep it that simple.
Seems like I'd still have to create an appropriate comps.xml file for whatever was on the second disc anyway, so why not just create everything on the first/only disc to begin with? Also, I always copy all of the RPMs into a local repository (e.g. /opt/repos/centos6u4) and run createrepo on it. Having one comps.xml file that works for both the installation disc and the installed repository keeps things clean...
Regards, Doug
On Thu, Oct 30, 2014 at 7:06 PM, Doug Wellington ddw@rincon.com wrote:
Previously:
Might be simpler in the long run to make it a 2-step process. That is, do a minimal OS install, then have a 2nd DVD or USB key that they install after the base system with a script that upgrades any existing rpms and installs the rest of what you need.
That adds an interesting set of questions. Do I somehow try to get the postinstall script to prompt for it? Do I try to create something similar to firstboot that would prompt for the second disc after the reboot? Do I just list it in the install docs? Right now the install docs are "1) Boot from DVD; 2) Choose system from menu." I'd like to keep it that simple.
Seems like I'd still have to create an appropriate comps.xml file for whatever was on the second disc anyway, so why not just create everything on the first/only disc to begin with? Also, I always copy all of the RPMs into a local repository (e.g. /opt/repos/centos6u4) and run createrepo on it. Having one comps.xml file that works for both the installation disc and the installed repository keeps things clean...
Is it really too complicated for the 'hands-on' guy to log in as root, cd to the mount point (or click on it if you run a GUI) and execute a command? If they can do that, the command can be as simple as a script that says something like 'yum localinstall list_of_packages' with the rpms just sitting there.
On 10/31/2014 03:08 AM, Les Mikesell wrote:
On Thu, Oct 30, 2014 at 7:06 PM, Doug Wellingtonddw@rincon.com wrote:
Previously:
Might be simpler in the long run to make it a 2-step process. That is, do a minimal OS install, then have a 2nd DVD or USB key that they install after the base system with a script that upgrades any existing rpms and installs the rest of what you need.
That adds an interesting set of questions. Do I somehow try to get the postinstall script to prompt for it? Do I try to create something similar to firstboot that would prompt for the second disc after the reboot? Do I just list it in the install docs? Right now the install docs are "1) Boot from DVD; 2) Choose system from menu." I'd like to keep it that simple.
Seems like I'd still have to create an appropriate comps.xml file for whatever was on the second disc anyway, so why not just create everything on the first/only disc to begin with? Also, I always copy all of the RPMs into a local repository (e.g. /opt/repos/centos6u4) and run createrepo on it. Having one comps.xml file that works for both the installation disc and the installed repository keeps things clean...
Is it really too complicated for the 'hands-on' guy to log in as root,
You'd be surprised. There might not exist a "hands-on guy" able to do anything more advanced than "insert disc in cd-drive, boot system". Been there, had to deal with that. I even had to deal with the question "What does boot mean ?'
cd to the mount point (or click on it if you run a GUI) and execute a command? If they can do that, the command can be as simple as a script that says something like 'yum localinstall list_of_packages' with the rpms just sitting there.
"IF" being the keyword.
On 10/31/2014 03:44 AM, Manuel Wolfshant wrote:
On 10/31/2014 03:08 AM, Les Mikesell wrote:
On Thu, Oct 30, 2014 at 7:06 PM, Doug Wellingtonddw@rincon.com wrote:
Previously:
Might be simpler in the long run to make it a 2-step process. That is, do a minimal OS install, then have a 2nd DVD or USB key that they install after the base system with a script that upgrades any existing rpms and installs the rest of what you need.
That adds an interesting set of questions. Do I somehow try to get the postinstall script to prompt for it? Do I try to create something similar to firstboot that would prompt for the second disc after the reboot? Do I just list it in the install docs? Right now the install docs are "1) Boot from DVD; 2) Choose system from menu." I'd like to keep it that simple.
Seems like I'd still have to create an appropriate comps.xml file for whatever was on the second disc anyway, so why not just create everything on the first/only disc to begin with? Also, I always copy all of the RPMs into a local repository (e.g. /opt/repos/centos6u4) and run createrepo on it. Having one comps.xml file that works for both the installation disc and the installed repository keeps things clean...
Is it really too complicated for the 'hands-on' guy to log in as root,
You'd be surprised. There might not exist a "hands-on guy" able to do anything more advanced than "insert disc in cd-drive, boot system". Been there, had to deal with that. I even had to deal with the question "What does boot mean ?'
This thread has taken an interesting turn, but I'd like to try to bring it back to my original question:
How can I build a variation on the official DVD, including generating the embedded LiveOS image; i.e., the rootfs.img file?
If I can be allowed access to the scripts that prepare the DVD, I can then document the process on the CentOS wiki.
Steve
cd to the mount point (or click on it if you run a GUI) and execute a command? If they can do that, the command can be as simple as a script that says something like 'yum localinstall list_of_packages' with the rpms just sitting there.
"IF" being the keyword. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 31/10/14 14:21, Steven Falco wrote:
On 10/31/2014 03:44 AM, Manuel Wolfshant wrote:
On 10/31/2014 03:08 AM, Les Mikesell wrote:
On Thu, Oct 30, 2014 at 7:06 PM, Doug Wellingtonddw@rincon.com wrote:
Previously:
> Might be simpler in the long run to make it a 2-step > process. That is, do a minimal OS install, then have a > 2nd DVD or USB key that they install after the base > system with a script that upgrades any existing rpms > and installs the rest of what you need.
That adds an interesting set of questions. Do I somehow try to get the postinstall script to prompt for it? Do I try to create something similar to firstboot that would prompt for the second disc after the reboot? Do I just list it in the install docs? Right now the install docs are "1) Boot from DVD; 2) Choose system from menu." I'd like to keep it that simple.
Seems like I'd still have to create an appropriate comps.xml file for whatever was on the second disc anyway, so why not just create everything on the first/only disc to begin with? Also, I always copy all of the RPMs into a local repository (e.g. /opt/repos/centos6u4) and run createrepo on it. Having one comps.xml file that works for both the installation disc and the installed repository keeps things clean...
Is it really too complicated for the 'hands-on' guy to log in as root,
You'd be surprised. There might not exist a "hands-on guy" able to do anything more advanced than "insert disc in cd-drive, boot system". Been there, had to deal with that. I even had to deal with the question "What does boot mean ?'
This thread has taken an interesting turn, but I'd like to try to bring it back to my original question:
How can I build a variation on the official DVD, including generating the embedded LiveOS image; i.e., the rootfs.img file?
Well, I haven't read the whole requirements list you probably described earlier, but have you already had a look at lorax ? It was written for such particular case normally : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On 10/31/2014 09:43 AM, Fabian Arrotin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 31/10/14 14:21, Steven Falco wrote:
On 10/31/2014 03:44 AM, Manuel Wolfshant wrote:
On 10/31/2014 03:08 AM, Les Mikesell wrote:
On Thu, Oct 30, 2014 at 7:06 PM, Doug Wellingtonddw@rincon.com wrote:
Previously: >> Might be simpler in the long run to make it a 2-step >> process. That is, do a minimal OS install, then have a >> 2nd DVD or USB key that they install after the base >> system with a script that upgrades any existing rpms >> and installs the rest of what you need.
That adds an interesting set of questions. Do I somehow try to get the postinstall script to prompt for it? Do I try to create something similar to firstboot that would prompt for the second disc after the reboot? Do I just list it in the install docs? Right now the install docs are "1) Boot from DVD; 2) Choose system from menu." I'd like to keep it that simple.
Seems like I'd still have to create an appropriate comps.xml file for whatever was on the second disc anyway, so why not just create everything on the first/only disc to begin with? Also, I always copy all of the RPMs into a local repository (e.g. /opt/repos/centos6u4) and run createrepo on it. Having one comps.xml file that works for both the installation disc and the installed repository keeps things clean...
Is it really too complicated for the 'hands-on' guy to log in as root,
You'd be surprised. There might not exist a "hands-on guy" able to do anything more advanced than "insert disc in cd-drive, boot system". Been there, had to deal with that. I even had to deal with the question "What does boot mean ?'
This thread has taken an interesting turn, but I'd like to try to bring it back to my original question:
How can I build a variation on the official DVD, including generating the embedded LiveOS image; i.e., the rootfs.img file?
Well, I haven't read the whole requirements list you probably described earlier, but have you already had a look at lorax ? It was written for such particular case normally : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Thank you! I will give that procedure a try and report my results.
Can you confirm whether this is the procedure used by the official CentOS build scripts?
Steve
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlRTkgAACgkQnVkHo1a+xU7EjQCfV0vrVSDcaf0Pohuxqp8i/MOd 1U4AnisVlXGibu2Od5d3Es4x6Efx8Q6Y =q6tM -----END PGP SIGNATURE----- _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 31/10/14 14:56, Steven Falco wrote:
On 10/31/2014 09:43 AM, Fabian Arrotin wrote: On 31/10/14 14:21, Steven Falco wrote:
On 10/31/2014 03:44 AM, Manuel Wolfshant wrote:
On 10/31/2014 03:08 AM, Les Mikesell wrote:
On Thu, Oct 30, 2014 at 7:06 PM, Doug Wellingtonddw@rincon.com wrote: >> Previously: >>>> Might be simpler in the long run to make it a >>>> 2-step process. That is, do a minimal OS >>>> install, then have a 2nd DVD or USB key that they >>>> install after the base system with a script that >>>> upgrades any existing rpms and installs the rest >>>> of what you need. >> >> That adds an interesting set of questions. Do I >> somehow try to get the postinstall script to prompt >> for it? Do I try to create something similar to >> firstboot that would prompt for the second disc after >> the reboot? Do I just list it in the install docs? >> Right now the install docs are "1) Boot from DVD; 2) >> Choose system from menu." I'd like to keep it that >> simple. >> >> Seems like I'd still have to create an appropriate >> comps.xml file for whatever was on the second disc >> anyway, so why not just create everything on the >> first/only disc to begin with? Also, I always copy >> all of the RPMs into a local repository (e.g. >> /opt/repos/centos6u4) and run createrepo on it. >> Having one comps.xml file that works for both the >> installation disc and the installed repository keeps >> things clean... >> Is it really too complicated for the 'hands-on' guy to log in as root,
You'd be surprised. There might not exist a "hands-on guy" able to do anything more advanced than "insert disc in cd-drive, boot system". Been there, had to deal with that. I even had to deal with the question "What does boot mean ?'
This thread has taken an interesting turn, but I'd like to try to bring it back to my original question:
How can I build a variation on the official DVD, including generating the embedded LiveOS image; i.e., the rootfs.img file?
Well, I haven't read the whole requirements list you probably described earlier, but have you already had a look at lorax ? It was written for such particular case normally : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Thank you! I will give that procedure a try and report my results.
Can you confirm whether this is the procedure used by the official CentOS build scripts?
No, I don't think so, as one has to buid the vmlinuz/initrd.img and other bits before being able to respin such variant .. but that's not what you asked for iirc :-)
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On 10/31/2014 02:10 PM, Fabian Arrotin wrote:
Can you confirm whether this is the procedure used by the official CentOS build scripts?
No, I don't think so, as one has to buid the vmlinuz/initrd.img and other bits before being able to respin such variant .. but that's not what you asked for iirc :-)
Also, worth noting that if you are building the entire installer and environment, you should not be calling your end result 'CentOS', you've effectively built a fork of CentOS.
On Fri, Oct 31, 2014 at 9:24 AM, Karanbir Singh mail-lists@karan.org wrote:
On 10/31/2014 02:10 PM, Fabian Arrotin wrote:
Can you confirm whether this is the procedure used by the official CentOS build scripts?
No, I don't think so, as one has to buid the vmlinuz/initrd.img and other bits before being able to respin such variant .. but that's not what you asked for iirc :-)
Also, worth noting that if you are building the entire installer and environment, you should not be calling your end result 'CentOS', you've effectively built a fork of CentOS.
That's, ummm, interesting... when the end result is going to be exactly the same as a stock install plus some other stuff and the only difference is the automation of adding the other stuff. Do the rest of us have to rename our systems too?
On 10/31/2014 02:35 PM, Les Mikesell wrote:
Also, worth noting that if you are building the entire installer and environment, you should not be calling your end result 'CentOS', you've effectively built a fork of CentOS.
That's, ummm, interesting... when the end result is going to be exactly the same as a stock install plus some other stuff and the only difference is the automation of adding the other stuff. Do the rest of us have to rename our systems too?
you might want to reread what I wrote and try parsing it ....
if you rebuild the installer, its not an official CentOS build, hasent been tested or released as one;
adding a kickstart and rebuilding the iso with mkisofs does not rebuild the installer; but you know that already.
On Fri, Oct 31, 2014 at 9:38 AM, Karanbir Singh mail-lists@karan.org wrote:
On 10/31/2014 02:35 PM, Les Mikesell wrote:
Also, worth noting that if you are building the entire installer and environment, you should not be calling your end result 'CentOS', you've effectively built a fork of CentOS.
That's, ummm, interesting... when the end result is going to be exactly the same as a stock install plus some other stuff and the only difference is the automation of adding the other stuff. Do the rest of us have to rename our systems too?
you might want to reread what I wrote and try parsing it ....
It is not at all clear how that maps into reality. I install a lot of different ways, including clonezilla, ReaR, and cloning VM images.
if you rebuild the installer, its not an official CentOS build, hasent been tested or released as one;
adding a kickstart and rebuilding the iso with mkisofs does not rebuild the installer; but you know that already.
OK. so how does ReaR or clonezilla fit into that scheme? ReaR builds its own boot iso with the system tools, Clonezilla boots with something else entirely. Cloning a VMware image does some of its own magic tweaks. But the result of all of these things, including a specifically rebuilt iso and installer may be a copy of a perfectly stock system - the same thing you would have if you did an install step first, then the customizations. The latter is becoming my preferred approach but I always have network access. I can see situations where a self-contained one-step install would be better. Maybe the minimal install build could look for a 2nd partition on the iso or a mounted usb for a continuation script.
On 10/31/2014 10:00 AM, Les Mikesell wrote:
On Fri, Oct 31, 2014 at 9:38 AM, Karanbir Singh mail-lists@karan.org wrote:
On 10/31/2014 02:35 PM, Les Mikesell wrote:
Also, worth noting that if you are building the entire installer and environment, you should not be calling your end result 'CentOS', you've effectively built a fork of CentOS.
That's, ummm, interesting... when the end result is going to be exactly the same as a stock install plus some other stuff and the only difference is the automation of adding the other stuff. Do the rest of us have to rename our systems too?
you might want to reread what I wrote and try parsing it ....
It is not at all clear how that maps into reality. I install a lot of different ways, including clonezilla, ReaR, and cloning VM images.
if you rebuild the installer, its not an official CentOS build, hasent been tested or released as one;
adding a kickstart and rebuilding the iso with mkisofs does not rebuild the installer; but you know that already.
OK. so how does ReaR or clonezilla fit into that scheme? ReaR builds its own boot iso with the system tools, Clonezilla boots with something else entirely. Cloning a VMware image does some of its own magic tweaks. But the result of all of these things, including a specifically rebuilt iso and installer may be a copy of a perfectly stock system - the same thing you would have if you did an install step first, then the customizations. The latter is becoming my preferred approach but I always have network access. I can see situations where a self-contained one-step install would be better. Maybe the minimal install build could look for a 2nd partition on the iso or a mounted usb for a continuation script.
Yes, that is called a kickstart and anaconda is designed specifically to allow you to pass one in .. either locally or on the web, etc. You original install and be additive.
You can do whatever you want on YOUR OWN systems and call it whatever you want. Anything you are smart enough to do.
If you tried to redistribute that as CentOS (your clonezilla images, for exampel), and say that it is official CentOS, well it is not. Official CentOS is in the form that we release it, not some other form. Especially not some other form where things are modified.
You can't modify Ubuntu or Debian or OpenSUSE either, and then distribute it and call it either of those things either. This is why Linux Mint is not Ubuntu and Ubuntu is not Debian ... but Linux mint is 'based on Ubuntu' and Ubyntu is 'based on Debain'. This is not rocket science.
On Fri, Oct 31, 2014 at 10:10 AM, Johnny Hughes johnny@centos.org wrote:
I can see situations where a self-contained one-step install would be better. Maybe the minimal install build could look for a 2nd partition on the iso or a mounted usb for a continuation script.
Yes, that is called a kickstart and anaconda is designed specifically to allow you to pass one in .. either locally or on the web, etc. You original install and be additive.
I meant adding a standard place to look for the optional kickstart or post-install script to the stock minimal install. A person who would have trouble logging in and running a script after a base install would not find typing the kickstart command line much easier.
You can do whatever you want on YOUR OWN systems and call it whatever you want. Anything you are smart enough to do.
I thought that was the original context here. Someone needing a remote install of a customized system - by a person who shouldn't be making any of the choices the installer offers.
If you tried to redistribute that as CentOS (your clonezilla images, for exampel), and say that it is official CentOS, well it is not. Official CentOS is in the form that we release it, not some other form. Especially not some other form where things are modified.
You can't modify Ubuntu or Debian or OpenSUSE either, and then distribute it and call it either of those things either. This is why Linux Mint is not Ubuntu and Ubuntu is not Debian ... but Linux mint is 'based on Ubuntu' and Ubyntu is 'based on Debain'. This is not rocket science.
Legalese is much worse than rocket science. Where does a VM image fit in this scheme? Can people build a VM image with an application installed for distribution and still identify the base system name? And if so, how/why is that different from any other copy?
On 10/31/2014 10:29 AM, Les Mikesell wrote:
On Fri, Oct 31, 2014 at 10:10 AM, Johnny Hughes johnny@centos.org wrote:
I can see situations where a self-contained one-step install would be better. Maybe the minimal install build could look for a 2nd partition on the iso or a mounted usb for a continuation script.
Yes, that is called a kickstart and anaconda is designed specifically to allow you to pass one in .. either locally or on the web, etc. You original install and be additive.
I meant adding a standard place to look for the optional kickstart or post-install script to the stock minimal install. A person who would have trouble logging in and running a script after a base install would not find typing the kickstart command line much easier.
You can do whatever you want on YOUR OWN systems and call it whatever you want. Anything you are smart enough to do.
I thought that was the original context here. Someone needing a remote install of a customized system - by a person who shouldn't be making any of the choices the installer offers.
If you tried to redistribute that as CentOS (your clonezilla images, for exampel), and say that it is official CentOS, well it is not. Official CentOS is in the form that we release it, not some other form. Especially not some other form where things are modified.
You can't modify Ubuntu or Debian or OpenSUSE either, and then distribute it and call it either of those things either. This is why Linux Mint is not Ubuntu and Ubuntu is not Debian ... but Linux mint is 'based on Ubuntu' and Ubyntu is 'based on Debain'. This is not rocket science.
Legalese is much worse than rocket science. Where does a VM image fit in this scheme? Can people build a VM image with an application installed for distribution and still identify the base system name? And if so, how/why is that different from any other copy?
No, The CentOS team creates VMs and cloud images and distributes them. Those are official. Things created by someone else are not official. This is for YOUR protection.
Again, its simple. And it is the same for any distro, not just CentOS.
You can't create a Ubuntu VM, especially one that is modified and call it Ubuntu and distribute it. Canonical can, you/we can't.
You can do anything you want on your local network though. (Create gold images, deploy them, etc.) It is redistributing (and that means outside your organization to the public) those that would be a problem.
Take Stella and Nux Dextop repo. Basically, Stella is CentOS with Nux Dextop installed. He does not distribute that as CentOS, he distributes it as Stella. It is based on CentOS. The Dextop repo is also available to be installed on CentOS, if you want. Both result in similar packages and work the same way. Both of those are perfectly fine.
It would not be fine for Nux to add the things onto a CentOS ISO and rebuild that ISO and call it CentOS and redistribute that, because it is not CentOS. He therefore calls it Stella and changes logos, etc.
You can give people CentOS ISOs and call that CentOS, you can use CentOS to create 'Your Thing' and give that to people as 'Your Thing'. You can't call 'Your Thing' CentOS. Why, because 'Your Thing' is not actually CentOS. You can say 'Your Thing' is based on CentOS (if you modified CentOS) .. or you can say 'Your Thing' runs on CentOS if you distribute 'Your Thing' and an unmodified CentOS on the same media and install it via a kickstart.
On Fri, Oct 31, 2014 at 11:44 AM, Johnny Hughes johnny@centos.org wrote:
Legalese is much worse than rocket science. Where does a VM image fit in this scheme? Can people build a VM image with an application installed for distribution and still identify the base system name? And if so, how/why is that different from any other copy?
No, The CentOS team creates VMs and cloud images and distributes them. Those are official. Things created by someone else are not official. This is for YOUR protection.
So all of the VMs out there with apps pre-installed should _not_ mention the name of the base OS they use?
You can give people CentOS ISOs and call that CentOS, you can use CentOS to create 'Your Thing' and give that to people as 'Your Thing'. You can't call 'Your Thing' CentOS. Why, because 'Your Thing' is not actually CentOS. You can say 'Your Thing' is based on CentOS (if you modified CentOS) .. or you can say 'Your Thing' runs on CentOS if you distribute 'Your Thing' and an unmodified CentOS on the same media and install it via a kickstart.
So even if the resulting copy is identical, there is a difference in what it should be called? Or can you call it the same once it is done, just not the piece that does the installing?
Why does this feel like you're intentionally attempting to be difficult?
This has been posted for months at http://www.centos.org/legal/trademarks/
This is both for community protection (so that people using hosted instances get what they think they're getting for example) and for our protection as we've worked hard to establish the project.
This is bog-standard and not at all specific to centos. Our terms are fairly comparable to pretty much every other large distribution. We're not looking to interfere with normal sys-admin uses or even hosting companies. We actively *want* people using our stuff.
What we don't want is some shady hosting company creating a terrible knock-off copy and calling it CentOS, harming both their customers AND our reputation with their modifications. This is entirely too common, and has to be explained so frequently during any given week on irc that the channel bot has triggers in place so the regulars like Manuel don't have to type it out constantly.
On 10/31/2014 11:59 AM, Les Mikesell wrote:
On Fri, Oct 31, 2014 at 11:44 AM, Johnny Hughes johnny@centos.org wrote:
Legalese is much worse than rocket science. Where does a VM image fit in this scheme? Can people build a VM image with an application installed for distribution and still identify the base system name? And if so, how/why is that different from any other copy?
No, The CentOS team creates VMs and cloud images and distributes them. Those are official. Things created by someone else are not official. This is for YOUR protection.
So all of the VMs out there with apps pre-installed should _not_ mention the name of the base OS they use?
You can give people CentOS ISOs and call that CentOS, you can use CentOS to create 'Your Thing' and give that to people as 'Your Thing'. You can't call 'Your Thing' CentOS. Why, because 'Your Thing' is not actually CentOS. You can say 'Your Thing' is based on CentOS (if you modified CentOS) .. or you can say 'Your Thing' runs on CentOS if you distribute 'Your Thing' and an unmodified CentOS on the same media and install it via a kickstart.
So even if the resulting copy is identical, there is a difference in what it should be called? Or can you call it the same once it is done, just not the piece that does the installing?
On Fri, Oct 31, 2014 at 12:13 PM, Jim Perrin jperrin@centos.org wrote:
Why does this feel like you're intentionally attempting to be difficult?
Because legalese is always difficult - and there are a bazillion VM images available with preinstalled apps and it would be very confusing if they can't mention the underlying OS name.
This is bog-standard and not at all specific to centos. Our terms are fairly comparable to pretty much every other large distribution. We're not looking to interfere with normal sys-admin uses or even hosting companies. We actively *want* people using our stuff.
Also I think my old favorite respin from Centos5 days (K12LTSP) would technically not be permitted, even though it basically just added stuff (very useful stuff at that, back in the day when getting a working java was painful). And that would have been a big loss.
On 31 October 2014 12:08, Les Mikesell lesmikesell@gmail.com wrote:
On Fri, Oct 31, 2014 at 12:13 PM, Jim Perrin jperrin@centos.org wrote:
Why does this feel like you're intentionally attempting to be difficult?
Because legalese is always difficult - and there are a bazillion VM images available with preinstalled apps and it would be very confusing if they can't mention the underlying OS name.
1. Get a lawyer. That doesn't mean asking a lawyer at some bar. That means setting up a legal agreement with them that they are willing to be disbarred for malpractice on the advise they give you. 2. Ask them the question. If they are a real lawyer, expect them to not answer immediately but have to go and research exactly what you are asking and then come up with a lot of questions that you need to answer. 3. The lawyer will make the formal inquiries needed with the trademark holder on what licenses are needed and how to comply with any existing trademark rules.
Or you can keep hitting your head against the wall by asking non-lawyers to give you 'binding' legal advise that you finally will like to hear.
On 10/31/2014 01:08 PM, Les Mikesell wrote:
On Fri, Oct 31, 2014 at 12:13 PM, Jim Perrin jperrin@centos.org wrote:
Why does this feel like you're intentionally attempting to be difficult?
Because legalese is always difficult - and there are a bazillion VM images available with preinstalled apps and it would be very confusing if they can't mention the underlying OS name.
If you read the TM guidelines [1] you'll see that you can "mention" CentOS - you can't call the resulting product CentOS.
Specifically:
"You may use the Word Mark, but not the Logos, to truthfully describe the origin of the software that you are providing but not the software itself, where what you are distributing is modified official CentOS source code or is a build compiled from modified official CentOS source code. You may say, for example: “This software is derived from the source code for the CentOS distribution.” However, you may not say that the software is CentOS."
It's really not difficult.
Best,
jzb
[1] http://www.centos.org/legal/trademarks/
On 10/31/2014 09:35 AM, Les Mikesell wrote:
On Fri, Oct 31, 2014 at 9:24 AM, Karanbir Singh mail-lists@karan.org wrote:
On 10/31/2014 02:10 PM, Fabian Arrotin wrote:
Can you confirm whether this is the procedure used by the official CentOS build scripts?
No, I don't think so, as one has to buid the vmlinuz/initrd.img and other bits before being able to respin such variant .. but that's not what you asked for iirc :-)
Also, worth noting that if you are building the entire installer and environment, you should not be calling your end result 'CentOS', you've effectively built a fork of CentOS.
That's, ummm, interesting... when the end result is going to be exactly the same as a stock install plus some other stuff and the only difference is the automation of adding the other stuff. Do the rest of us have to rename our systems too?
Rebuilding the installer would then modify the .discinfo and .treeinfo of the install and it would make that ISO not work against any normal CentOS tree. It then is no longer CentOS and you can't distribute that as CentOS. Fairly simple.
If you want to rebuild an installer and redistribute something, that is what SIGs are for. Community reviewed and agreed upon process, produced on the official CentOS Community Build System. It can be called CentOS and the entire process will be completely open and available to all SIGs that need them. It will also be approved by the CentOS Board.
So, yes, if you change the directories that make it CentOS, respin those parts of the ISO (ie, change the installer parts, the treeinfo and discinfo), and try to redistribute that then it is not CentOS.
If, on the other hand, you take a minimal install ISO, leave all the original pieces alone, add other stuff to it that is additive only, then it is your thing on top of CentOS as a kickstart to happen after the CentOS install .. and you can call it 'Your Thing' on CentOS. But you can't call that just CentOS .. it is 'Your Thing' on CentOS.
On 10/31/2014 10:10 AM, Fabian Arrotin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
This thread has taken an interesting turn, but I'd like to try to bring it back to my original question:
How can I build a variation on the official DVD, including generating the embedded LiveOS image; i.e., the rootfs.img file?
Well, I haven't read the whole requirements list you probably described earlier, but have you already had a look at lorax ? It was written for such particular case normally : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Thank you! I will give that procedure a try and report my results.
I've tried the above procedure, and can confirm that it built a good iso file, using the RedHat minimal ks as input. The resulting iso booted properly on VirtualBox.
In a completely separate experiment, I was able to use pungi (rebuilt from the Fedora 20 SRPM) to generate an installation disk.
The only issue I ran into in that experiment was that I needed to first build and install a custom kernel with HFS+ support, because the Fedora 20 version of pungi apparently needs HFS+ to create the EFI boot mechanism on the DVD.
Can you confirm whether this is the procedure used by the official CentOS build scripts?
No, I don't think so, as one has to buid the vmlinuz/initrd.img and other bits before being able to respin such variant .. but that's not what you asked for iirc :-)
Ok - understood. If at some point in the future the official build tools can be made available (read-only of course), I'd still be interested in seeing them, and in helping to document them, but for now, I have a path to build what I need.
Thanks, Steve
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlRTmGYACgkQnVkHo1a+xU5HPgCfXNJCGtCaDeXhm2PYjhEjbEqX wH8AoIeY4hR4wsHvPZoeOcxJWCQLvCEW =ysqs -----END PGP SIGNATURE----- _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
On Thu, Oct 30, 2014 at 10:51 AM, Jim Perrin jperrin@centos.org wrote:
Sounds mostly like the officially documented procedure from 4/5/6 that's been in place for a while. In my opinion it's a terrible way to do things, and I much prefer pxe and networked installs as you get updates, avoid rebuilding media, etc.
PXE - or even DHCP infrastructure isn't practical everywhere. Is there a simple way to make a USB boot media that allows manual network setup but then does a network/kickstart install? And/or has a VNCCONNECT baked in for where you need remote hands-on support but want to minimize what they have to do?
On 10/30/2014 01:15 PM, Les Mikesell wrote:
On Thu, Oct 30, 2014 at 10:51 AM, Jim Perrin jperrin@centos.org wrote:
Sounds mostly like the officially documented procedure from 4/5/6 that's been in place for a while. In my opinion it's a terrible way to do things, and I much prefer pxe and networked installs as you get updates, avoid rebuilding media, etc.
PXE - or even DHCP infrastructure isn't practical everywhere. Is there a simple way to make a USB boot media that allows manual network setup but then does a network/kickstart install? And/or has a VNCCONNECT baked in for where you need remote hands-on support but want to minimize what they have to do?
That is an interesting thought, but it doesn't fit the use-case I am trying to address.
I've posted my original question on the -docs list. Hopefully, that will yield some info, or at least a path to get more info.
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
-
Doug Wellington -
Fabian Arrotin -
Jim Perrin -
Joe Brockmeier -
Johnny Hughes -
Karanbir Singh -
Les Mikesell -
Manuel Wolfshant -
Stephen John Smoogen -
Steven Falco