I've been talking with Andrew Brown from NCSU, and we have some ideas on how to implement a cobbler imaging solution utilizing livecd's and partimage. He's going to be taking a crack at implementing this for a future cobbler release. I've included basic details here so others could see what we are thinking and weigh in. The use case is for the Virtual Compute Lab (http://vcl.ncsu.edu/) though this should be extensible to any other place that needs to clone images and might have mixed Linux/other deployments. Naturally, if you can do kickstart (or preseed, or autoyast, or ...), it's always preferable to do kickstart (or equivalents) -- maintaining security updates on images and so forth and dealing with hardware differences is an additional layer of complexity.
This is somewhat based around some capabilities of IBM's xcat, though we're going to rework it to make it work idiomatically in cobbler where there is much less setup involved.
The following instructions assume pxe_just_once is turned on in /etc/cobbler/settings and the systems PXE first in BIOS order. That makes some things simpler as the live images can simply reboot when done.
The idea/syntax is as follows:
# from a base of the imported RHEL5 distro, use livecd-tools to create a livecd and convert it to a PXE-able image. # this livecd image will contain a post script that uses partimage to export partitions to a configured NFS share (in cobbler) # and/or load the image based on kernel arguments configured via flags below. cobbler distro make-cloner --name=RHEL5-cloner --distro=RHEL5
# here we make a profile for what is being cloned. For example, "RHEL5-image-myclassproject37", this name will be used # by the NFS share, and because it is parented by a cloner image, it will have special symantics in terms of what kernel # arguments get fed to it, such that our special live image (or modified initrd, TBD) knows what to do. cobbler profile add --name=RHEL5-image-projectX --distro=RHEL5-cloner
# now we assign a system via PXE boot to be cloned. Note that we are assigning it to a live image not to be installed, but to # be netbooted and then cloned. cobbler system edit --name=foo --profile=RHEL5-image-projectX --save-clone [--netboot-enabled=1]
# to clone the image, we assign another system to the cloner profile, like so, and reboot it once finished cobbler system edit --name=bar --profile=RHEL5-image-projectX --load-clone [--netboot-enabled=1]
This should cover all partition types supported by partimage but not the "weird stuff".
This also seems to imply that we would have a settting in /etc/cobbler/settings to configure the address info of the NFS server to save things to.
Comments? Questions?
--Michael
This sounds too complicated, at least at first glance. I have been able to get head around it yet. Maybe another example or so can help us better understand what it does and how.
-Georgi
-----Original Message----- From: cobbler-bounces@lists.fedorahosted.org [mailto:cobbler-bounces@lists.fedorahosted.org] On Behalf Of Michael DeHaan Sent: Wednesday, July 30, 2008 11:03 To: cobbler@lists.fedorahosted.org Subject: More details on system imaging -- livecd based proposal
I've been talking with Andrew Brown from NCSU, and we have some ideas on
how to implement a cobbler imaging solution utilizing livecd's and partimage. He's going to be taking a crack at implementing this for a future cobbler release. I've included basic details here so others could see what we are thinking and weigh in. The use case is for the Virtual Compute Lab (http://vcl.ncsu.edu/) though this should be extensible to any other place that needs to clone images and might have mixed Linux/other deployments. Naturally, if you can do kickstart (or
preseed, or autoyast, or ...), it's always preferable to do kickstart (or equivalents) -- maintaining security updates on images and so forth and dealing with hardware differences is an additional layer of complexity.
This is somewhat based around some capabilities of IBM's xcat, though we're going to rework it to make it work idiomatically in cobbler where there is much less setup involved.
The following instructions assume pxe_just_once is turned on in /etc/cobbler/settings and the systems PXE first in BIOS order. That makes some things simpler as the live images can simply reboot when done.
The idea/syntax is as follows:
# from a base of the imported RHEL5 distro, use livecd-tools to create a
livecd and convert it to a PXE-able image. # this livecd image will contain a post script that uses partimage to export partitions to a configured NFS share (in cobbler) # and/or load the image based on kernel arguments configured via flags below. cobbler distro make-cloner --name=RHEL5-cloner --distro=RHEL5
# here we make a profile for what is being cloned. For example, "RHEL5-image-myclassproject37", this name will be used # by the NFS share, and because it is parented by a cloner image, it will have special symantics in terms of what kernel # arguments get fed to it, such that our special live image (or modified
initrd, TBD) knows what to do. cobbler profile add --name=RHEL5-image-projectX --distro=RHEL5-cloner
# now we assign a system via PXE boot to be cloned. Note that we are assigning it to a live image not to be installed, but to # be netbooted and then cloned. cobbler system edit --name=foo --profile=RHEL5-image-projectX --save-clone [--netboot-enabled=1]
# to clone the image, we assign another system to the cloner profile, like so, and reboot it once finished cobbler system edit --name=bar --profile=RHEL5-image-projectX --load-clone [--netboot-enabled=1]
This should cover all partition types supported by partimage but not the
"weird stuff".
This also seems to imply that we would have a settting in /etc/cobbler/settings to configure the address info of the NFS server to save things to.
Comments? Questions?
--Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________
On Wed, Jul 30, 2008 at 12:02:36PM -0400, Michael DeHaan wrote:
Comments? Questions?
Well I agree with the previous commenter, who considered it complicated.
What I've done for one of my customer's imaging needs is to create an image of a system using tar (which isn't perfect, I know) plus the partitioning information. I would then load a special cobbler profile which involved a "stub" OS image, which contained a script to run at boot which would find the stored image, tar it onto the disk, fix up the grub so that it booted the correct partitions in the right way, and then rebooted.
This was limited to restoring images that were previously taken from the same system due to what could be charitably called a wide variety of hardware, but I don't doubt that someone clever could make the post-install (or firstboot) more flexible to make it deal with different hardware.
I always thought that a better way to do it would be to put all that into a specially crafted %PRE script and not bother with the stub, but never found the time to get it done myself. And since we have an already working PXE-based installer environment, why bother with the LiveCD?
I implemented a variation of this for my Sun Solaris systems -- a special Jumpstart profile which instead of running the installer would partition the disk and install a (ufsdump-sourced) image and made the disk bootable; Solaris' built-in flexibility and relative hardware homogenity made this easier to make work across different machine types.
All that said, I am perhaps not the target for cobbler; the increasing power of cobbler et al is far beyond my needs, as I've not really changed how I've been doing things since 0.3.3 when I started using it.
this sounds alot like flar archives for use in jumpstart.
It's been a while since I've messed with solaris (thank god!) but jumpstart with flar archives used to work really well.
Cheers, Harry
David Mackintosh wrote:
On Wed, Jul 30, 2008 at 12:02:36PM -0400, Michael DeHaan wrote:
Comments? Questions?
Well I agree with the previous commenter, who considered it complicated.
What I've done for one of my customer's imaging needs is to create an image of a system using tar (which isn't perfect, I know) plus the partitioning information. I would then load a special cobbler profile which involved a "stub" OS image, which contained a script to run at boot which would find the stored image, tar it onto the disk, fix up the grub so that it booted the correct partitions in the right way, and then rebooted.
This was limited to restoring images that were previously taken from the same system due to what could be charitably called a wide variety of hardware, but I don't doubt that someone clever could make the post-install (or firstboot) more flexible to make it deal with different hardware.
I always thought that a better way to do it would be to put all that into a specially crafted %PRE script and not bother with the stub, but never found the time to get it done myself. And since we have an already working PXE-based installer environment, why bother with the LiveCD?
I implemented a variation of this for my Sun Solaris systems -- a special Jumpstart profile which instead of running the installer would partition the disk and install a (ufsdump-sourced) image and made the disk bootable; Solaris' built-in flexibility and relative hardware homogenity made this easier to make work across different machine types.
All that said, I am perhaps not the target for cobbler; the increasing power of cobbler et al is far beyond my needs, as I've not really changed how I've been doing things since 0.3.3 when I started using it.
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
All that said, I am perhaps not the target for cobbler; the increasing power of cobbler et al is far beyond my needs, as I've not really changed how I've been doing things since 0.3.3 when I started using it.
It seems as you are talking about tar you really don't understand the use case we are trying to solve.
Think about arbitrary cloning of arbitrary operating systems, at the filesystem level, not "tar".
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
The problem with doing a clone on the file-system level is that it takes way too much space. You might have a system that has 300G file system and has only 5G of useful data. Even compressing the file system image will not save you that much space (unless you write zeros to the unused space on the file system before you archive and compress it).
Doing cloning via tar or cpio on the file level is much more economical. Only space that is used will need to be archived and compressed. This kind of approach will let you restore to not exactly the same system. Let's say that the new system has two smaller drives instead of one big one. This approach can work around that. Or maybe the destination drive is a bit smaller than the source drive but all data will fit, this approach can work with that too.
Doing things on the file system level has quite a few restrictions? Maybe there is a way to shrink down the file system before it was archived and expand it to needed size during the restore process.
-Georgi
-----Original Message----- From: cobbler-bounces@lists.fedorahosted.org [mailto:cobbler-bounces@lists.fedorahosted.org] On Behalf Of Michael DeHaan Sent: Thursday, July 31, 2008 6:56 To: cobbler mailing list Subject: Re: More details on system imaging -- livecd based proposal
All that said, I am perhaps not the target for cobbler; the increasing power of cobbler et al is far beyond my needs, as I've not really changed how I've been doing things since 0.3.3 when I started using it.
It seems as you are talking about tar you really don't understand the use case we are trying to solve.
Think about arbitrary cloning of arbitrary operating systems, at the filesystem level, not "tar".
------------------------------------------------------------------------
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
_______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________
cobbler-bounces@lists.fedorahosted.org wrote on 08/01/2008 11:45:36 AM:
"Hristov, Georgi" Georgi.Hristov@fnis.com Sent by: cobbler-bounces@lists.fedorahosted.org
08/01/2008 11:45 AM
Subject
RE: More details on system imaging -- livecd based proposal
The problem with doing a clone on the file-system level is that it takes way too much space. You might have a system that has 300G file system and has only 5G of useful data. Even compressing the file system image will not save you that much space (unless you write zeros to the unused space on the file system before you archive and compress it).
-snip
Perhaps you need to read about partimage, which is the proposed tool do the the cloning. From partimage.org:
"Partimage will only copy data from the used portions of the partition. For speed and efficiency, free blocks are not written to the image file. This is unlike the 'dd' command, which also copies empty blocks. Partimage also works for large, very full partitions. For example, a full 1 GB partition can be compressed with gzip down to 400MB. "
James S. Martin, RHCE Contractor Administrative Office of the United States Courts Washington, DC (202) 502-2394
Thanks James,
That's very good info.
-Georgi
-----Original Message----- From: cobbler-bounces@lists.fedorahosted.org [mailto:cobbler-bounces@lists.fedorahosted.org] On Behalf Of James_Martin@ao.uscourts.gov Sent: Friday, August 01, 2008 11:07 To: cobbler mailing list Subject: RE: More details on system imaging -- livecd based proposal
cobbler-bounces@lists.fedorahosted.org wrote on 08/01/2008 11:45:36 AM:
"Hristov, Georgi" Georgi.Hristov@fnis.com Sent by: cobbler-bounces@lists.fedorahosted.org
08/01/2008 11:45 AM
Subject
RE: More details on system imaging -- livecd based proposal
The problem with doing a clone on the file-system level is that it
takes
way too much space. You might have a system that has 300G file system and has only 5G of useful data. Even compressing the file system image will not save you that much space (unless you write zeros to the
unused
space on the file system before you archive and compress it).
-snip
Perhaps you need to read about partimage, which is the proposed tool do the the cloning. From partimage.org:
"Partimage will only copy data from the used portions of the partition. For speed and efficiency, free blocks are not written to the image file. This is unlike the 'dd' command, which also copies empty blocks. Partimage also works for large, very full partitions. For example, a full 1 GB partition can be compressed with gzip down to 400MB. "
James S. Martin, RHCE Contractor Administrative Office of the United States Courts Washington, DC (202) 502-2394
_______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________
We're open to suggestions on how the interface should look for this.
Right now, to elaborate on what Michael described, we'll have a "cloner" distro installed. This will be generated from an actual distro, but modified to be a live environment with scripts to save off or load the hard drive over nfs. Hence the "cobbler distro make-cloner command. Specifically, this command could use the utilities in the livecd-tools package to create an iso or a pxeboot kernel/initrd that's purpose will be to save and load images. This is what I'm currently looking into, any suggestions on this step are welcome.
The next step is to associate profiles with a cloner distro. You'd create a profile for each image you want to save; profiles that are assigned to a cloner distro represent one image (but that image could go to several systems). Systems that are assigned to the same "cloner" profile are intended to have the same image on them (or at least have the ability to reload the image from time to time). In my use case, we'd equate profiles with projects, so we could save off an image related to a project and load another onto a particular machine as needed.
And the final step is to associate a system with a "cloner" profile. When a system is assigned to a cloner profile and set to netboot enabled, its pxeboot file will point to the cloner distro kernel and initrd. Additionally, kernel parameters will be passed to it to tell it to save or load, and where it should save/load to/from (nfs path), and the image name. The computer boots, goes through the imaging process, and reboots back to the local hard drive when finished.
I thought this was relatively simple (compared to some of our initial ideas at least), and I like it since it follows the model for distro -> profile -> system pretty well. This business of a cloner distro was chosen (over just including a pre-made kernel/initrd with the package like xcat does) for portability and compatability with all environments and arcitetures.
The theory behind this feature is to be able to take a snapshot of a customized system. Kickstarts are usually preferred, but in some environments it is desirable to be able to save a machine's current state off to an image. Then perhaps something experimental can be tried, and the original image restored afterwards. This is somewhat common situation in our lab. The second useful situation is where we need to set up a machine in a very specific way: customize packages, configs, files, and such, and then need to duplicate this to many other machines. The customizations aren't always easy to compress down into a kickstart, and especially when the hardware is identical, imaging them is often easier and faster. I know a lot of you probably don't need convincing that this is a useful feature, I just thought I'd share some of the more useful cases that I've come across for this kind of feature.
-Andrew
On Wed, Jul 30, 2008 at 12:02 PM, Michael DeHaan mdehaan@redhat.com wrote:
I've been talking with Andrew Brown from NCSU, and we have some ideas on how to implement a cobbler imaging solution utilizing livecd's and partimage. He's going to be taking a crack at implementing this for a future cobbler release. I've included basic details here so others could see what we are thinking and weigh in. The use case is for the Virtual Compute Lab (http://vcl.ncsu.edu/) though this should be extensible to any other place that needs to clone images and might have mixed Linux/other deployments. Naturally, if you can do kickstart (or preseed, or autoyast, or ...), it's always preferable to do kickstart (or equivalents) -- maintaining security updates on images and so forth and dealing with hardware differences is an additional layer of complexity.
This is somewhat based around some capabilities of IBM's xcat, though we're going to rework it to make it work idiomatically in cobbler where there is much less setup involved.
The following instructions assume pxe_just_once is turned on in /etc/cobbler/settings and the systems PXE first in BIOS order. That makes some things simpler as the live images can simply reboot when done.
The idea/syntax is as follows:
# from a base of the imported RHEL5 distro, use livecd-tools to create a livecd and convert it to a PXE-able image. # this livecd image will contain a post script that uses partimage to export partitions to a configured NFS share (in cobbler) # and/or load the image based on kernel arguments configured via flags below. cobbler distro make-cloner --name=RHEL5-cloner --distro=RHEL5
# here we make a profile for what is being cloned. For example, "RHEL5-image-myclassproject37", this name will be used # by the NFS share, and because it is parented by a cloner image, it will have special symantics in terms of what kernel # arguments get fed to it, such that our special live image (or modified initrd, TBD) knows what to do. cobbler profile add --name=RHEL5-image-projectX --distro=RHEL5-cloner
# now we assign a system via PXE boot to be cloned. Note that we are assigning it to a live image not to be installed, but to # be netbooted and then cloned. cobbler system edit --name=foo --profile=RHEL5-image-projectX --save-clone [--netboot-enabled=1]
# to clone the image, we assign another system to the cloner profile, like so, and reboot it once finished cobbler system edit --name=bar --profile=RHEL5-image-projectX --load-clone [--netboot-enabled=1]
This should cover all partition types supported by partimage but not the "weird stuff".
This also seems to imply that we would have a settting in /etc/cobbler/settings to configure the address info of the NFS server to save things to.
Comments? Questions?
--Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
On Wed, 30 Jul 2008, Andrew Brown wrote:
The theory behind this feature is to be able to take a snapshot of a customized system. Kickstarts are usually preferred, but in some environments it is desirable to be able to save a machine's current state off to an image. Then perhaps something experimental can be tried, and the original image restored afterwards. This is somewhat common
Now this is interesting. I don't care how you get there, but being able to make a restorable copy before an update would be great. Disk space will be a big issue for our production images though.
------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine
Andrew Brown wrote:
We're open to suggestions on how the interface should look for this.
Right now, to elaborate on what Michael described, we'll have a "cloner" distro installed. This will be generated from an actual distro, but modified to be a live environment with scripts to save off or load the hard drive over nfs. Hence the "cobbler distro make-cloner command. Specifically, this command could use the utilities in the livecd-tools package to create an iso or a pxeboot kernel/initrd that's purpose will be to save and load images. This is what I'm currently looking into, any suggestions on this step are welcome.
The next step is to associate profiles with a cloner distro. You'd create a profile for each image you want to save; profiles that are assigned to a cloner distro represent one image (but that image could go to several systems). Systems that are assigned to the same "cloner" profile are intended to have the same image on them (or at least have the ability to reload the image from time to time). In my use case, we'd equate profiles with projects, so we could save off an image related to a project and load another onto a particular machine as needed.
And the final step is to associate a system with a "cloner" profile. When a system is assigned to a cloner profile and set to netboot enabled, its pxeboot file will point to the cloner distro kernel and initrd. Additionally, kernel parameters will be passed to it to tell it to save or load, and where it should save/load to/from (nfs path), and the image name. The computer boots, goes through the imaging process, and reboots back to the local hard drive when finished.
I thought this was relatively simple (compared to some of our initial ideas at least), and I like it since it follows the model for distro -> profile -> system pretty well. This business of a cloner distro was chosen (over just including a pre-made kernel/initrd with the package like xcat does) for portability and compatability with all environments and arcitetures.
I also agree that usability wise this is going to be rather simple. That's the point of cobbler, in automating what's going on behind the scenes and making more manual technologies and processes very consumable and fast. Rather than hear that the implementation "sounds complicated" (it really isn't -- we have thought this out a good bit), I was more interested in hearing what folks thought of the feature and syntax.
The theory behind this feature is to be able to take a snapshot of a customized system. Kickstarts are usually preferred, but in some environments it is desirable to be able to save a machine's current state off to an image. Then perhaps something experimental can be tried, and the original image restored afterwards. This is somewhat common situation in our lab. The second useful situation is where we need to set up a machine in a very specific way: customize packages, configs, files, and such, and then need to duplicate this to many other machines. The customizations aren't always easy to compress down into a kickstart, and especially when the hardware is identical, imaging them is often easier and faster. I know a lot of you probably don't need convincing that this is a useful feature, I just thought I'd share some of the more useful cases that I've come across for this kind of feature.
Right, images are a completely different workflow from kickstart based systems. There are several use cases here -- restoring backups of existing images, cloning existing systems that got into a state in a way that is not reproducable, Windows cloning, and even finding ways to support other operating systems that Cobbler doesn't support as long as we understand the filesystem. This is really the largest missing component of cobbler and a great add.
To me, it seems this is one of the most generic ways we've seen how to solve the problem thus far -- and that's much better than solving it for just one OS (Windows specific code -- ack), or doing something hackish at the filesystem level that is more in the config management layer. If someone wants to use config management systems or backup systems, nothing is stopping from doing that on top of Cobbler -- in fact, that can be a good thing. This is about dealing with /filesystem/ images.
And as always, it's not required that you use it if the use case doesn't make sense for you. I can see this being /highly/ useful in academic type environments, where the division in IT between Linux and Windows systems does not exist ... and not just at university levels, but also in K-12 lab situations and other places where the administrator doesn't have the time to learn DHCP, DNS, image cloning tools, kickstart, and so on, ad nauseum. The other use case is for a heavily customized OS image, which do exist in certain niche applications. That is less of a target but still something we should cover in other to completely cover the provisioning use cases.
For folks that can do kickstart like solutions, absolutely, do those! They are much more sustaintable and easy to manage -- in particular, the updates problem goes away, and the storage requirements are much smaller.
-Andrew
On Wed, Jul 30, 2008 at 12:02 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
I've been talking with Andrew Brown from NCSU, and we have some ideas on how to implement a cobbler imaging solution utilizing livecd's and partimage. He's going to be taking a crack at implementing this for a future cobbler release. I've included basic details here so others could see what we are thinking and weigh in. The use case is for the Virtual Compute Lab (http://vcl.ncsu.edu/) though this should be extensible to any other place that needs to clone images and might have mixed Linux/other deployments. Naturally, if you can do kickstart (or preseed, or autoyast, or ...), it's always preferable to do kickstart (or equivalents) -- maintaining security updates on images and so forth and dealing with hardware differences is an additional layer of complexity. This is somewhat based around some capabilities of IBM's xcat, though we're going to rework it to make it work idiomatically in cobbler where there is much less setup involved. The following instructions assume pxe_just_once is turned on in /etc/cobbler/settings and the systems PXE first in BIOS order. That makes some things simpler as the live images can simply reboot when done. The idea/syntax is as follows: # from a base of the imported RHEL5 distro, use livecd-tools to create a livecd and convert it to a PXE-able image. # this livecd image will contain a post script that uses partimage to export partitions to a configured NFS share (in cobbler) # and/or load the image based on kernel arguments configured via flags below. cobbler distro make-cloner --name=RHEL5-cloner --distro=RHEL5 # here we make a profile for what is being cloned. For example, "RHEL5-image-myclassproject37", this name will be used # by the NFS share, and because it is parented by a cloner image, it will have special symantics in terms of what kernel # arguments get fed to it, such that our special live image (or modified initrd, TBD) knows what to do. cobbler profile add --name=RHEL5-image-projectX --distro=RHEL5-cloner # now we assign a system via PXE boot to be cloned. Note that we are assigning it to a live image not to be installed, but to # be netbooted and then cloned. cobbler system edit --name=foo --profile=RHEL5-image-projectX --save-clone [--netboot-enabled=1] # to clone the image, we assign another system to the cloner profile, like so, and reboot it once finished cobbler system edit --name=bar --profile=RHEL5-image-projectX --load-clone [--netboot-enabled=1] This should cover all partition types supported by partimage but not the "weird stuff". This also seems to imply that we would have a settting in /etc/cobbler/settings to configure the address info of the NFS server to save things to. Comments? Questions? --Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
So I've started looking at the script that builds a koan live cd (the 'live' directory in the koan source) to modify it to do what we need, but I'm having trouble getting the code to produce a bootable iso.
I'm just trying to run the build.py script as is, and it produces a koan-live-cd.iso. But when I boot it, it gets several errors about mounting the root filesystem, as well as several other errors that I can type up here if you want. The last line looks like "switchroot: mount failed: No such file or directory"
I need to get this working before I can move on to editing it for the cloner imaging. Any idea what's going on with this? -Andrew
On Wed, Jul 30, 2008 at 12:02 PM, Michael DeHaan mdehaan@redhat.com wrote:
I've been talking with Andrew Brown from NCSU, and we have some ideas on how to implement a cobbler imaging solution utilizing livecd's and partimage. He's going to be taking a crack at implementing this for a future cobbler release. I've included basic details here so others could see what we are thinking and weigh in. The use case is for the Virtual Compute Lab (http://vcl.ncsu.edu/) though this should be extensible to any other place that needs to clone images and might have mixed Linux/other deployments. Naturally, if you can do kickstart (or preseed, or autoyast, or ...), it's always preferable to do kickstart (or equivalents) -- maintaining security updates on images and so forth and dealing with hardware differences is an additional layer of complexity.
This is somewhat based around some capabilities of IBM's xcat, though we're going to rework it to make it work idiomatically in cobbler where there is much less setup involved.
The following instructions assume pxe_just_once is turned on in /etc/cobbler/settings and the systems PXE first in BIOS order. That makes some things simpler as the live images can simply reboot when done.
The idea/syntax is as follows:
# from a base of the imported RHEL5 distro, use livecd-tools to create a livecd and convert it to a PXE-able image. # this livecd image will contain a post script that uses partimage to export partitions to a configured NFS share (in cobbler) # and/or load the image based on kernel arguments configured via flags below. cobbler distro make-cloner --name=RHEL5-cloner --distro=RHEL5
# here we make a profile for what is being cloned. For example, "RHEL5-image-myclassproject37", this name will be used # by the NFS share, and because it is parented by a cloner image, it will have special symantics in terms of what kernel # arguments get fed to it, such that our special live image (or modified initrd, TBD) knows what to do. cobbler profile add --name=RHEL5-image-projectX --distro=RHEL5-cloner
# now we assign a system via PXE boot to be cloned. Note that we are assigning it to a live image not to be installed, but to # be netbooted and then cloned. cobbler system edit --name=foo --profile=RHEL5-image-projectX --save-clone [--netboot-enabled=1]
# to clone the image, we assign another system to the cloner profile, like so, and reboot it once finished cobbler system edit --name=bar --profile=RHEL5-image-projectX --load-clone [--netboot-enabled=1]
This should cover all partition types supported by partimage but not the "weird stuff".
This also seems to imply that we would have a settting in /etc/cobbler/settings to configure the address info of the NFS server to save things to.
Comments? Questions?
--Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Andrew Brown wrote:
So I've started looking at the script that builds a koan live cd (the 'live' directory in the koan source) to modify it to do what we need, but I'm having trouble getting the code to produce a bootable iso.
I'm just trying to run the build.py script as is, and it produces a koan-live-cd.iso. But when I boot it, it gets several errors about mounting the root filesystem, as well as several other errors that I can type up here if you want. The last line looks like "switchroot: mount failed: No such file or directory"
I need to get this working before I can move on to editing it for the cloner imaging. Any idea what's going on with this? -Andrew
Sure. Perhaps you can take a picture of the actual error, so we can run it by the livecd-tools folks?
I'm assuming you are building this on F9?
--Michael
I'm assuming you are building this on F9?
I wasn't, I was using the script and kickstart in the koan source which was fc8. I've switched to the development branch which is fc9 and re-built it.
The cd image that comes out of that works, as in, it boots and starts executing the scripts. I believe I can modify things to do what we need.
I also tried using the livecd-iso-to-pxe script to convert the iso into a pxe boot kernel/initrd and pxelinux config file. That also worked as far as I could tell booting an actual machine using the generated /tftpboot tree (it generates a kernel, initrd, and pxelinux config file)
However, I tried booting the kernel and initrd with qemu using its -kernel and -initrd options, and it wouldn't work. I'd like to get this to work if possible so I can rapidly try new images without booting up actual hardware. It's actually not that big of a deal because qemu boots the iso just fine. I'm just curious why it wouldn't boot the kernel/initrd directly. The command line looks like this:
qemu -m 256 -hda ~/disk.qcow2 -kernel vmlinuz0 -initrd initrd0.img -append "root=/koan-live-cd.iso rootfstype=iso9660 rootflags=loop"
It errors with a kernel panic being unable to mount the root filesystem. The append line was copied from the generated pxe config from the livecd-iso-to-pxe script. /koan-live-cd.iso is a file in the initrd.
Anyways, if that's a dead end, I won't worry about it. I'm going to try and modify the koan live cd to be a cloner live cd. I'm first going to get it working with dd, since partimage isn't in the repos and I'll have to build it myself. -Andrew
On Tue, Aug 5, 2008 at 2:58 PM, Michael DeHaan mdehaan@redhat.com wrote:
Andrew Brown wrote:
So I've started looking at the script that builds a koan live cd (the 'live' directory in the koan source) to modify it to do what we need, but I'm having trouble getting the code to produce a bootable iso.
I'm just trying to run the build.py script as is, and it produces a koan-live-cd.iso. But when I boot it, it gets several errors about mounting the root filesystem, as well as several other errors that I can type up here if you want. The last line looks like "switchroot: mount failed: No such file or directory"
I need to get this working before I can move on to editing it for the cloner imaging. Any idea what's going on with this? -Andrew
Sure. Perhaps you can take a picture of the actual error, so we can run it by the livecd-tools folks?
I'm assuming you are building this on F9?
--Michael
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Andrew Brown wrote:
I'm assuming you are building this on F9?
I wasn't, I was using the script and kickstart in the koan source which was fc8. I've switched to the development branch which is fc9 and re-built it.
The cd image that comes out of that works, as in, it boots and starts executing the scripts. I believe I can modify things to do what we need.
I also tried using the livecd-iso-to-pxe script to convert the iso into a pxe boot kernel/initrd and pxelinux config file. That also worked as far as I could tell booting an actual machine using the generated /tftpboot tree (it generates a kernel, initrd, and pxelinux config file)
However, I tried booting the kernel and initrd with qemu using its -kernel and -initrd options, and it wouldn't work. I'd like to get this to work if possible so I can rapidly try new images without booting up actual hardware. It's actually not that big of a deal because qemu boots the iso just fine. I'm just curious why it wouldn't boot the kernel/initrd directly. The command line looks like this:
qemu -m 256 -hda ~/disk.qcow2 -kernel vmlinuz0 -initrd initrd0.img -append "root=/koan-live-cd.iso rootfstype=iso9660 rootflags=loop"
This is what koan is for.
If using a VM:
# on cobbler server cobbler image add --name=livecd --path=nfs://server/path/to/livecd.iso
# on host system koan --virt --virt-type=qemu --image=livecd
This all goes through the virtinst libraries to make sure the correct arguments are used. If that /still/ fails, we can debug this.
The process for PXEbooting that still involves "cobbler distro add" and not "image add" based on the Wiki link "AllAboutImages" I posted yesterday.
It errors with a kernel panic being unable to mount the root filesystem. The append line was copied from the generated pxe config from the livecd-iso-to-pxe script. /koan-live-cd.iso is a file in the initrd.
Anyways, if that's a dead end, I won't worry about it. I'm going to try and modify the koan live cd to be a cloner live cd. I'm first going to get it working with dd, since partimage isn't in the repos and I'll have to build it myself.
Yep, we're going to want to get partimage packaged for Fedora.
-Andrew
On Tue, Aug 5, 2008 at 2:58 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Andrew Brown wrote: > So I've started looking at the script that builds a koan live cd (the > 'live' directory in the koan source) to modify it to do what we need, > but I'm having trouble getting the code to produce a bootable iso. > > I'm just trying to run the build.py script as is, and it produces a > koan-live-cd.iso. But when I boot it, it gets several errors about > mounting the root filesystem, as well as several other errors that I > can type up here if you want. The last line looks like "switchroot: > mount failed: No such file or directory" > > I need to get this working before I can move on to editing it for the > cloner imaging. Any idea what's going on with this? > -Andrew Sure. Perhaps you can take a picture of the actual error, so we can run it by the livecd-tools folks? I'm assuming you are building this on F9? --Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Hi All, I thought I'd give an update on where I am. I've been working on a live cd image that will boot up and take/restore an image to an nfs export and then reboot.
Attached are the base.cfg kickstart file and build.py script to build the live cd. It is somewhat untested at the moment. Taking images works but I haven't yet tried restoring them (I plan to do that shortly).
The process for saving an image is as follows, and this is mostly identical to how xcat does it: 0) mounts remote nfs export at /mnt/nfs 1) saves off the mbr with e.g. "dd if=/dev/sda of=/mnt/nfs/imagename/mbr bs=512 count=1" 2) Saves off extended partition image information with "sfdisk /dev/sda -d > /mnt/nfs/imagename/sfdisk" 3) Loops for each partition listed in the output of "sfdisk -l /dev/sda" 3.a) If the partition type (last column) is "Empty", skip it 3.b) Save the partition with e.g. "dd if=/dev/sda1 of=/mnt/nfs/imagename/1 conv=sync,noerror"
Eventually we can use the partition type to determine if we can use partimage on it (for ext/ntfs partitions) or if we can do something else (swap partitions, mkswap to restore). For now, everything is copied with dd.
The script expects arguments to be passed through the kernel command line. Here are the arguments it needs: nfs= the nfs path to mount. e.g. 10.10.10.1:/export image= the name of the image to save/restore. This translates to the folder name under the nfs path where files will be saved. drive= the local drive where things will be saved save|load either one of these is specified and the image is either saved or loaded
And to make a long post even longer, I was wondering if anyone could shed some light on an odd problem. It seems that while in the live environment, the one and only hard drive appears as /dev/sdb instead of the expected /dev/sda. I was trying this on an IBM bladecenter blade, and found that /dev/sda was something else and the hard drive was assigned /dev/sdb. It's not like this in a non-live environment. Anyone have any ideas? -Andrew
On Thu, Aug 7, 2008 at 8:39 AM, Michael DeHaan mdehaan@redhat.com wrote:
Andrew Brown wrote:
I'm assuming you are building this on F9?
I wasn't, I was using the script and kickstart in the koan source which was fc8. I've switched to the development branch which is fc9 and re-built it.
The cd image that comes out of that works, as in, it boots and starts executing the scripts. I believe I can modify things to do what we need.
I also tried using the livecd-iso-to-pxe script to convert the iso into a pxe boot kernel/initrd and pxelinux config file. That also worked as far as I could tell booting an actual machine using the generated /tftpboot tree (it generates a kernel, initrd, and pxelinux config file)
However, I tried booting the kernel and initrd with qemu using its -kernel and -initrd options, and it wouldn't work. I'd like to get this to work if possible so I can rapidly try new images without booting up actual hardware. It's actually not that big of a deal because qemu boots the iso just fine. I'm just curious why it wouldn't boot the kernel/initrd directly. The command line looks like this:
qemu -m 256 -hda ~/disk.qcow2 -kernel vmlinuz0 -initrd initrd0.img -append "root=/koan-live-cd.iso rootfstype=iso9660 rootflags=loop"
This is what koan is for.
If using a VM:
# on cobbler server cobbler image add --name=livecd --path=nfs://server/path/to/livecd.iso
# on host system koan --virt --virt-type=qemu --image=livecd
This all goes through the virtinst libraries to make sure the correct arguments are used. If that /still/ fails, we can debug this.
The process for PXEbooting that still involves "cobbler distro add" and not "image add" based on the Wiki link "AllAboutImages" I posted yesterday.
It errors with a kernel panic being unable to mount the root filesystem. The append line was copied from the generated pxe config from the livecd-iso-to-pxe script. /koan-live-cd.iso is a file in the initrd.
Anyways, if that's a dead end, I won't worry about it. I'm going to try and modify the koan live cd to be a cloner live cd. I'm first going to get it working with dd, since partimage isn't in the repos and I'll have to build it myself.
Yep, we're going to want to get partimage packaged for Fedora.
-Andrew
On Tue, Aug 5, 2008 at 2:58 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Andrew Brown wrote: > So I've started looking at the script that builds a koan live cd (the > 'live' directory in the koan source) to modify it to do what we need, > but I'm having trouble getting the code to produce a bootable iso. > > I'm just trying to run the build.py script as is, and it produces a > koan-live-cd.iso. But when I boot it, it gets several errors about > mounting the root filesystem, as well as several other errors that
I
> can type up here if you want. The last line looks like
"switchroot:
> mount failed: No such file or directory" > > I need to get this working before I can move on to editing it for the > cloner imaging. Any idea what's going on with this? > -Andrew Sure. Perhaps you can take a picture of the actual error, so we can run it by the livecd-tools folks? I'm assuming you are building this on F9? --Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:
cobbler@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Okay, a few things since yesterday: I'm not worrying about the hard drive device issue for the moment, it seems to be related to whether the bladecenter media tray is assigned to that blade or not.
I've also edited the code to ignore listed partitions of type "Empty" or "Extended"
But somehow the process isn't working. I followed the process very closely of xcat, a similar provisioning engine. After taking and restoring an image, it doesn't boot.
I tried the process manually today. That is, I booted with a live cd and ran each command myself. Saved the mbr, saved the partition table with sfdisk, and saved the contents of each partition of a freshly installed linux installation.
Then I went to the next blade, identical hardware and setup, and booted the live cd up. -Restored partition entries with sfdisk -Restored mbr with dd -Restored partitions again with sfdisk. I don't fully understand why it's done again, this was just following the xcat process (for which I can post the exact code if anyone's curious). -And of course restore all partitions one at a time
When I tried to boot it back up, it got as far as printing "GRUB" and hung there. I need some help here, I'm not sure what's going on.
I tried a different order to restoring partition/mbr info: Restore partition stuff with sfdisk, and then the mbr with dd. I was thinking sfdisk may have overwritten the mbr or something, but I got the same results.
Anyone have any ideas?
-Andrew
On Mon, Aug 18, 2008 at 1:39 PM, Andrew Brown ambrown4@ncsu.edu wrote:
Hi All, I thought I'd give an update on where I am. I've been working on a live cd image that will boot up and take/restore an image to an nfs export and then reboot.
Attached are the base.cfg kickstart file and build.py script to build the live cd. It is somewhat untested at the moment. Taking images works but I haven't yet tried restoring them (I plan to do that shortly).
The process for saving an image is as follows, and this is mostly identical to how xcat does it: 0) mounts remote nfs export at /mnt/nfs
- saves off the mbr with e.g. "dd if=/dev/sda of=/mnt/nfs/imagename/mbr
bs=512 count=1" 2) Saves off extended partition image information with "sfdisk /dev/sda -d
/mnt/nfs/imagename/sfdisk"
- Loops for each partition listed in the output of "sfdisk -l /dev/sda"
3.a) If the partition type (last column) is "Empty", skip it 3.b) Save the partition with e.g. "dd if=/dev/sda1 of=/mnt/nfs/imagename/1 conv=sync,noerror"
Eventually we can use the partition type to determine if we can use partimage on it (for ext/ntfs partitions) or if we can do something else (swap partitions, mkswap to restore). For now, everything is copied with dd.
The script expects arguments to be passed through the kernel command line. Here are the arguments it needs: nfs= the nfs path to mount. e.g. 10.10.10.1:/export image= the name of the image to save/restore. This translates to the folder name under the nfs path where files will be saved. drive= the local drive where things will be saved save|load either one of these is specified and the image is either saved or loaded
And to make a long post even longer, I was wondering if anyone could shed some light on an odd problem. It seems that while in the live environment, the one and only hard drive appears as /dev/sdb instead of the expected /dev/sda. I was trying this on an IBM bladecenter blade, and found that /dev/sda was something else and the hard drive was assigned /dev/sdb. It's not like this in a non-live environment. Anyone have any ideas? -Andrew
On Thu, Aug 7, 2008 at 8:39 AM, Michael DeHaan mdehaan@redhat.com wrote:
Andrew Brown wrote:
I'm assuming you are building this on F9?
I wasn't, I was using the script and kickstart in the koan source which was fc8. I've switched to the development branch which is fc9 and re-built it.
The cd image that comes out of that works, as in, it boots and starts executing the scripts. I believe I can modify things to do what we
need.
I also tried using the livecd-iso-to-pxe script to convert the iso into a pxe boot kernel/initrd and pxelinux config file. That also worked as far as I could tell booting an actual machine using the generated /tftpboot tree (it generates a kernel, initrd, and pxelinux config file)
However, I tried booting the kernel and initrd with qemu using its -kernel and -initrd options, and it wouldn't work. I'd like to get this to work if possible so I can rapidly try new images without booting up actual hardware. It's actually not that big of a deal because qemu boots the iso just fine. I'm just curious why it wouldn't boot the kernel/initrd directly. The command line looks like this:
qemu -m 256 -hda ~/disk.qcow2 -kernel vmlinuz0 -initrd initrd0.img -append "root=/koan-live-cd.iso rootfstype=iso9660 rootflags=loop"
This is what koan is for.
If using a VM:
# on cobbler server cobbler image add --name=livecd --path=nfs://server/path/to/livecd.iso
# on host system koan --virt --virt-type=qemu --image=livecd
This all goes through the virtinst libraries to make sure the correct arguments are used. If that /still/ fails, we can debug this.
The process for PXEbooting that still involves "cobbler distro add" and not "image add" based on the Wiki link "AllAboutImages" I posted yesterday.
It errors with a kernel panic being unable to mount the root filesystem. The append line was copied from the generated pxe config from the livecd-iso-to-pxe script. /koan-live-cd.iso is a file in the initrd.
Anyways, if that's a dead end, I won't worry about it. I'm going to try and modify the koan live cd to be a cloner live cd. I'm first going to get it working with dd, since partimage isn't in the repos and I'll have to build it myself.
Yep, we're going to want to get partimage packaged for Fedora.
-Andrew
On Tue, Aug 5, 2008 at 2:58 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Andrew Brown wrote: > So I've started looking at the script that builds a koan live cd (the > 'live' directory in the koan source) to modify it to do what we need, > but I'm having trouble getting the code to produce a bootable iso. > > I'm just trying to run the build.py script as is, and it produces
a
> koan-live-cd.iso. But when I boot it, it gets several errors
about
> mounting the root filesystem, as well as several other errors that
I
> can type up here if you want. The last line looks like
"switchroot:
> mount failed: No such file or directory" > > I need to get this working before I can move on to editing it for the > cloner imaging. Any idea what's going on with this? > -Andrew Sure. Perhaps you can take a picture of the actual error, so we can run it by the livecd-tools folks? I'm assuming you are building this on F9? --Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:
cobbler@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Andrew Brown wrote:
Okay, a few things since yesterday: I'm not worrying about the hard drive device issue for the moment, it seems to be related to whether the bladecenter media tray is assigned to that blade or not.
I've also edited the code to ignore listed partitions of type "Empty" or "Extended"
Is there a new attachment we can look at for this?
But somehow the process isn't working. I followed the process very closely of xcat, a similar provisioning engine. After taking and restoring an image, it doesn't boot.
I tried the process manually today. That is, I booted with a live cd and ran each command myself. Saved the mbr, saved the partition table with sfdisk, and saved the contents of each partition of a freshly installed linux installation.
Then I went to the next blade, identical hardware and setup, and booted the live cd up. -Restored partition entries with sfdisk -Restored mbr with dd -Restored partitions again with sfdisk. I don't fully understand why it's done again, this was just following the xcat process (for which I can post the exact code if anyone's curious). -And of course restore all partitions one at a time
When I tried to boot it back up, it got as far as printing "GRUB" and hung there. I need some help here, I'm not sure what's going on.
One thing to check is to stop before rebooting and see if grub is installed correctly, or if any errors happen during grub-install. For that, it may be worth running through the script line by line or at least logging the output of each step w/ debug output printed before each command as needed.
I tried a different order to restoring partition/mbr info: Restore partition stuff with sfdisk, and then the mbr with dd. I was thinking sfdisk may have overwritten the mbr or something, but I got the same results.
Grub lives in the MBR, though are you calling grub-install after all of that?
Anyone have any ideas?
-Andrew
On Mon, Aug 18, 2008 at 1:39 PM, Andrew Brown <ambrown4@ncsu.edu mailto:ambrown4@ncsu.edu> wrote:
Hi All, I thought I'd give an update on where I am. I've been working on a live cd image that will boot up and take/restore an image to an nfs export and then reboot. Attached are the base.cfg kickstart file and build.py script to build the live cd. It is somewhat untested at the moment. Taking images works but I haven't yet tried restoring them (I plan to do that shortly). The process for saving an image is as follows, and this is mostly identical to how xcat does it: 0) mounts remote nfs export at /mnt/nfs 1) saves off the mbr with e.g. "dd if=/dev/sda of=/mnt/nfs/imagename/mbr bs=512 count=1" 2) Saves off extended partition image information with "sfdisk /dev/sda -d > /mnt/nfs/imagename/sfdisk" 3) Loops for each partition listed in the output of "sfdisk -l /dev/sda" 3.a) If the partition type (last column) is "Empty", skip it 3.b) Save the partition with e.g. "dd if=/dev/sda1 of=/mnt/nfs/imagename/1 conv=sync,noerror" Eventually we can use the partition type to determine if we can use partimage on it (for ext/ntfs partitions) or if we can do something else (swap partitions, mkswap to restore). For now, everything is copied with dd. The script expects arguments to be passed through the kernel command line. Here are the arguments it needs: nfs= the nfs path to mount. e.g. 10.10.10.1:/export image= the name of the image to save/restore. This translates to the folder name under the nfs path where files will be saved. drive= the local drive where things will be saved save|load either one of these is specified and the image is either saved or loaded And to make a long post even longer, I was wondering if anyone could shed some light on an odd problem. It seems that while in the live environment, the one and only hard drive appears as /dev/sdb instead of the expected /dev/sda. I was trying this on an IBM bladecenter blade, and found that /dev/sda was something else and the hard drive was assigned /dev/sdb. It's not like this in a non-live environment. Anyone have any ideas? -Andrew On Thu, Aug 7, 2008 at 8:39 AM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com>> wrote: Andrew Brown wrote: > > I'm assuming you are building this on F9? > > > I wasn't, I was using the script and kickstart in the koan source > which was fc8. I've switched to the development branch which is fc9 > and re-built it. > > The cd image that comes out of that works, as in, it boots and starts > executing the scripts. I believe I can modify things to do what we need. > > I also tried using the livecd-iso-to-pxe script to convert the iso > into a pxe boot kernel/initrd and pxelinux config file. That also > worked as far as I could tell booting an actual machine using the > generated /tftpboot tree (it generates a kernel, initrd, and pxelinux > config file) > > However, I tried booting the kernel and initrd with qemu using its > -kernel and -initrd options, and it wouldn't work. I'd like to get > this to work if possible so I can rapidly try new images without > booting up actual hardware. > It's actually not that big of a deal because qemu boots the iso just > fine. I'm just curious why it wouldn't boot the kernel/initrd > directly. The command line looks like this: > > qemu -m 256 -hda ~/disk.qcow2 -kernel vmlinuz0 -initrd initrd0.img > -append "root=/koan-live-cd.iso rootfstype=iso9660 rootflags=loop" > This is what koan is for. If using a VM: # on cobbler server cobbler image add --name=livecd --path=nfs://server/path/to/livecd.iso # on host system koan --virt --virt-type=qemu --image=livecd This all goes through the virtinst libraries to make sure the correct arguments are used. If that /still/ fails, we can debug this. The process for PXEbooting that still involves "cobbler distro add" and not "image add" based on the Wiki link "AllAboutImages" I posted yesterday. > It errors with a kernel panic being unable to mount the root > filesystem. The append line was copied from the generated pxe config > from the livecd-iso-to-pxe script. /koan-live-cd.iso is a file in the > initrd. > > > Anyways, if that's a dead end, I won't worry about it. I'm going to > try and modify the koan live cd to be a cloner live cd. I'm first > going to get it working with dd, since partimage isn't in the repos > and I'll have to build it myself. Yep, we're going to want to get partimage packaged for Fedora. > -Andrew > > On Tue, Aug 5, 2008 at 2:58 PM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com> > <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>>> wrote: > > Andrew Brown wrote: > > So I've started looking at the script that builds a koan live cd > (the > > 'live' directory in the koan source) to modify it to do what we > need, > > but I'm having trouble getting the code to produce a bootable iso. > > > > I'm just trying to run the build.py script as is, and it produces a > > koan-live-cd.iso. But when I boot it, it gets several errors about > > mounting the root filesystem, as well as several other errors that I > > can type up here if you want. The last line looks like "switchroot: > > mount failed: No such file or directory" > > > > I need to get this working before I can move on to editing it > for the > > cloner imaging. Any idea what's going on with this? > > -Andrew > > Sure. Perhaps you can take a picture of the actual error, so we > can run > it by the livecd-tools folks? > > I'm assuming you are building this on F9? > > --Michael > > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > https://fedorahosted.org/mailman/listinfo/cobbler > > > ------------------------------------------------------------------------ > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
On Tue, Aug 19, 2008 at 6:16 PM, Michael DeHaan mdehaan@redhat.com wrote:
Andrew Brown wrote:
Okay, a few things since yesterday: I'm not worrying about the hard drive device issue for the moment, it seems to be related to whether the bladecenter media tray is assigned to that blade or not.
I've also edited the code to ignore listed partitions of type "Empty" or "Extended"
Is there a new attachment we can look at for this?
I've attached the most recent base.cfg which contains the code. Keep in mind that today I did things manually though, not using the script.
But somehow the process isn't working. I followed the process very closely of xcat, a similar provisioning engine. After taking and restoring an image, it doesn't boot.
I tried the process manually today. That is, I booted with a live cd and ran each command myself. Saved the mbr, saved the partition table with sfdisk, and saved the contents of each partition of a freshly installed linux installation.
Then I went to the next blade, identical hardware and setup, and booted the live cd up. -Restored partition entries with sfdisk -Restored mbr with dd -Restored partitions again with sfdisk. I don't fully understand why it's done again, this was just following the xcat process (for which I can post the exact code if anyone's curious). -And of course restore all partitions one at a time
When I tried to boot it back up, it got as far as printing "GRUB" and hung there. I need some help here, I'm not sure what's going on.
One thing to check is to stop before rebooting and see if grub is installed correctly, or if any errors happen during grub-install. For that, it may be worth running through the script line by line or at least logging the output of each step w/ debug output printed before each command as needed.
Like I said, I did the entire procedure manually... entered each command myself so I knew exactly what was running. Once I get it working manually, I can easily find out if my script is doing things any differently.
How do I tell if grub is installed correctly?
I tried a different order to restoring partition/mbr info: Restore partition stuff with sfdisk, and then the mbr with dd. I was thinking sfdisk may have overwritten the mbr or something, but I got the same results.
Grub lives in the MBR, though are you calling grub-install after all of that?
Right. I'm not calling grub-install. I didn't think it was necessary. Grub lives in the mbr, which is the first 512 bytes of the drive. I'm saving the mbr to a file and restoring it back. Shouldn't that be sufficient?
Again, I'm following the procedure that xcat uses as closely as possible. I'm not against making changes of course, but I'm wondering what I'm doing differently since I didn't see any calls to grub-install in the xcat scripts. -Andrew
Anyone have any ideas?
-Andrew
On Mon, Aug 18, 2008 at 1:39 PM, Andrew Brown <ambrown4@ncsu.edu mailto:ambrown4@ncsu.edu> wrote:
Hi All, I thought I'd give an update on where I am. I've been working on a live cd image that will boot up and take/restore an image to an nfs export and then reboot. Attached are the base.cfg kickstart file and build.py script to build the live cd. It is somewhat untested at the moment. Taking images works but I haven't yet tried restoring them (I plan to do that shortly). The process for saving an image is as follows, and this is mostly identical to how xcat does it: 0) mounts remote nfs export at /mnt/nfs 1) saves off the mbr with e.g. "dd if=/dev/sda of=/mnt/nfs/imagename/mbr bs=512 count=1" 2) Saves off extended partition image information with "sfdisk /dev/sda -d > /mnt/nfs/imagename/sfdisk" 3) Loops for each partition listed in the output of "sfdisk -l /dev/sda" 3.a) If the partition type (last column) is "Empty", skip it 3.b) Save the partition with e.g. "dd if=/dev/sda1 of=/mnt/nfs/imagename/1 conv=sync,noerror" Eventually we can use the partition type to determine if we can use partimage on it (for ext/ntfs partitions) or if we can do something else (swap partitions, mkswap to restore). For now, everything is copied with dd. The script expects arguments to be passed through the kernel command line. Here are the arguments it needs: nfs= the nfs path to mount. e.g. 10.10.10.1:/export image= the name of the image to save/restore. This translates to the folder name under the nfs path where files will be saved. drive= the local drive where things will be saved save|load either one of these is specified and the image is either saved or loaded And to make a long post even longer, I was wondering if anyone could shed some light on an odd problem. It seems that while in the live environment, the one and only hard drive appears as /dev/sdb instead of the expected /dev/sda. I was trying this on an IBM bladecenter blade, and found that /dev/sda was something else and the hard drive was assigned /dev/sdb. It's not like this in a non-live environment. Anyone have any ideas? -Andrew On Thu, Aug 7, 2008 at 8:39 AM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com>> wrote: Andrew Brown wrote: > > I'm assuming you are building this on F9? > > > I wasn't, I was using the script and kickstart in the koan source > which was fc8. I've switched to the development branch which is fc9 > and re-built it. > > The cd image that comes out of that works, as in, it boots and starts > executing the scripts. I believe I can modify things to do what we need. > > I also tried using the livecd-iso-to-pxe script to convert the iso > into a pxe boot kernel/initrd and pxelinux config file. That also > worked as far as I could tell booting an actual machine using the > generated /tftpboot tree (it generates a kernel, initrd, and pxelinux > config file) > > However, I tried booting the kernel and initrd with qemu using its > -kernel and -initrd options, and it wouldn't work. I'd like to get > this to work if possible so I can rapidly try new images
without
> booting up actual hardware. > It's actually not that big of a deal because qemu boots the iso just > fine. I'm just curious why it wouldn't boot the kernel/initrd > directly. The command line looks like this: > > qemu -m 256 -hda ~/disk.qcow2 -kernel vmlinuz0 -initrd initrd0.img > -append "root=/koan-live-cd.iso rootfstype=iso9660 rootflags=loop" > This is what koan is for. If using a VM: # on cobbler server cobbler image add --name=livecd --path=nfs://server/path/to/livecd.iso # on host system koan --virt --virt-type=qemu --image=livecd This all goes through the virtinst libraries to make sure the correct arguments are used. If that /still/ fails, we can debug this. The process for PXEbooting that still involves "cobbler distro add" and not "image add" based on the Wiki link "AllAboutImages" I posted yesterday. > It errors with a kernel panic being unable to mount the root > filesystem. The append line was copied from the generated pxe config > from the livecd-iso-to-pxe script. /koan-live-cd.iso is a file in the > initrd. > > > Anyways, if that's a dead end, I won't worry about it. I'm going to > try and modify the koan live cd to be a cloner live cd. I'm first > going to get it working with dd, since partimage isn't in the repos > and I'll have to build it myself. Yep, we're going to want to get partimage packaged for Fedora. > -Andrew > > On Tue, Aug 5, 2008 at 2:58 PM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com> > <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>>>
wrote:
> > Andrew Brown wrote: > > So I've started looking at the script that builds a koan live cd > (the > > 'live' directory in the koan source) to modify it to do what we > need, > > but I'm having trouble getting the code to produce a bootable iso. > > > > I'm just trying to run the build.py script as is, and it produces a > > koan-live-cd.iso. But when I boot it, it gets several errors about > > mounting the root filesystem, as well as several other errors that I > > can type up here if you want. The last line looks like "switchroot: > > mount failed: No such file or directory" > > > > I need to get this working before I can move on to editing it > for the > > cloner imaging. Any idea what's going on with this? > > -Andrew > > Sure. Perhaps you can take a picture of the actual error, so we > can run > it by the livecd-tools folks? > > I'm assuming you are building this on F9? > > --Michael > > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > https://fedorahosted.org/mailman/listinfo/cobbler > > >
> > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Andrew Brown wrote:
On Tue, Aug 19, 2008 at 6:16 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Andrew Brown wrote: > Okay, a few things since yesterday: > I'm not worrying about the hard drive device issue for the moment, it > seems to be related to whether the bladecenter media tray is assigned > to that blade or not. > > I've also edited the code to ignore listed partitions of type "Empty" > or "Extended" Is there a new attachment we can look at for this?
I've attached the most recent base.cfg which contains the code. Keep in mind that today I did things manually though, not using the script.
> > But somehow the process isn't working. I followed the process very > closely of xcat, a similar provisioning engine. After taking and > restoring an image, it doesn't boot. > > > I tried the process manually today. That is, I booted with a live cd > and ran each command myself. Saved the mbr, saved the partition table > with sfdisk, and saved the contents of each partition of a freshly > installed linux installation. > > Then I went to the next blade, identical hardware and setup, and > booted the live cd up. > -Restored partition entries with sfdisk > -Restored mbr with dd > -Restored partitions again with sfdisk. I don't fully understand why > it's done again, this was just following the xcat process (for which > I can post the exact code if anyone's curious). > -And of course restore all partitions one at a time > > When I tried to boot it back up, it got as far as printing "GRUB" and > hung there. I need some help here, I'm not sure what's going on. One thing to check is to stop before rebooting and see if grub is installed correctly, or if any errors happen during grub-install. For that, it may be worth running through the script line by line or at least logging the output of each step w/ debug output printed before each command as needed.
Like I said, I did the entire procedure manually... entered each command myself so I knew exactly what was running. Once I get it working manually, I can easily find out if my script is doing things any differently.
How do I tell if grub is installed correctly?
"grubby" has some probe options that should do this. See "man grubby"?
> > I tried a different order to restoring partition/mbr info: Restore > partition stuff with sfdisk, and then the mbr with dd. I was thinking > sfdisk may have overwritten the mbr or something, but I got the same > results. Grub lives in the MBR, though are you calling grub-install after all of that?
Right. I'm not calling grub-install. I didn't think it was necessary. Grub lives in the mbr, which is the first 512 bytes of the drive. I'm saving the mbr to a file and restoring it back. Shouldn't that be sufficient?
In theory, assuming it's not a GPT partition /and/ grub lives in the MBR (both of which can't really be assumed), yes.
It's best to use grubby, the command line tool, for manipulating grub. As a bonus it also knows how to manipulate lilo and elilo. There is some code in koan that references a few common grubby commands, though you'll probably want to change this around.
--bad-image-ok does not work, but otherwise what you see koan using for the live CD is close.
Also there are some bits of the live config script that are using grub-install.
On Wed, Aug 20, 2008 at 7:44 AM, Michael DeHaan mdehaan@redhat.com wrote:
Andrew Brown wrote:
On Tue, Aug 19, 2008 at 6:16 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Andrew Brown wrote: > Okay, a few things since yesterday: > I'm not worrying about the hard drive device issue for the moment, it > seems to be related to whether the bladecenter media tray is assigned > to that blade or not. > > I've also edited the code to ignore listed partitions of type "Empty" > or "Extended" Is there a new attachment we can look at for this?
I've attached the most recent base.cfg which contains the code. Keep in mind that today I did things manually though, not using the script.
> > But somehow the process isn't working. I followed the process very > closely of xcat, a similar provisioning engine. After taking and > restoring an image, it doesn't boot. > > > I tried the process manually today. That is, I booted with a live cd > and ran each command myself. Saved the mbr, saved the partition table > with sfdisk, and saved the contents of each partition of a freshly > installed linux installation. > > Then I went to the next blade, identical hardware and setup, and > booted the live cd up. > -Restored partition entries with sfdisk > -Restored mbr with dd > -Restored partitions again with sfdisk. I don't fully understand why > it's done again, this was just following the xcat process (for which > I can post the exact code if anyone's curious). > -And of course restore all partitions one at a time > > When I tried to boot it back up, it got as far as printing "GRUB" and > hung there. I need some help here, I'm not sure what's going on. One thing to check is to stop before rebooting and see if grub is installed correctly, or if any errors happen during grub-install. For that, it may be worth running through the script line by line or at least logging the output of each step w/ debug output printed before each command as needed.
Like I said, I did the entire procedure manually... entered each command myself so I knew exactly what was running. Once I get it working manually, I can easily find out if my script is doing things any differently.
How do I tell if grub is installed correctly?
"grubby" has some probe options that should do this. See "man grubby"?
> > I tried a different order to restoring partition/mbr info: Restore > partition stuff with sfdisk, and then the mbr with dd. I was thinking > sfdisk may have overwritten the mbr or something, but I got the
same
> results. Grub lives in the MBR, though are you calling grub-install after all of that?
Right. I'm not calling grub-install. I didn't think it was necessary. Grub lives in the mbr, which is the first 512 bytes of the drive. I'm saving the mbr to a file and restoring it back. Shouldn't that be sufficient?
In theory, assuming it's not a GPT partition /and/ grub lives in the MBR (both of which can't really be assumed), yes.
It's best to use grubby, the command line tool, for manipulating grub. As a bonus it also knows how to manipulate lilo and elilo. There is some code in koan that references a few common grubby commands, though you'll probably want to change this around.
--bad-image-ok does not work, but otherwise what you see koan using for the live CD is close.
Also there are some bits of the live config script that are using grub-install.
So I suppose I'm wrong in assuming that saving the mbr+partition layout and each partitions' contents, and then restoring each component is not sufficient for perfectly duplicating a hard drive. Where else could data lie?
I'll look into using grubby to make sure grub is installed, but I still don't know why this doesn't work as is, things should be restored exactly as they were, right?
And further, what about systems that don't use grub, such as windows? How are we going to do this so that it's still cross platform?
-Andrew
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Running "grub-install /dev/sda" in a live environment "fixes" the machine so it will boot.
Unless there's a good reason not to though, I'd like to know why the current method doesn't work, and find a general solution that will work for any setup. See my last email.
And also, I can't seem to find "grubby". It's not included on the fedora rescue cd or ubuntu live cd, and the fedora live cd keeps giving me a kernel panic when I try to boot it. But that's a separate issue for now. -Andrew
On Wed, Aug 20, 2008 at 2:25 PM, Andrew Brown ambrown4@ncsu.edu wrote:
On Wed, Aug 20, 2008 at 7:44 AM, Michael DeHaan mdehaan@redhat.comwrote:
Andrew Brown wrote:
On Tue, Aug 19, 2008 at 6:16 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Andrew Brown wrote: > Okay, a few things since yesterday: > I'm not worrying about the hard drive device issue for the moment, it > seems to be related to whether the bladecenter media tray is assigned > to that blade or not. > > I've also edited the code to ignore listed partitions of type "Empty" > or "Extended" Is there a new attachment we can look at for this?
I've attached the most recent base.cfg which contains the code. Keep in mind that today I did things manually though, not using the script.
> > But somehow the process isn't working. I followed the process
very
> closely of xcat, a similar provisioning engine. After taking and > restoring an image, it doesn't boot. > > > I tried the process manually today. That is, I booted with a live cd > and ran each command myself. Saved the mbr, saved the partition table > with sfdisk, and saved the contents of each partition of a freshly > installed linux installation. > > Then I went to the next blade, identical hardware and setup, and > booted the live cd up. > -Restored partition entries with sfdisk > -Restored mbr with dd > -Restored partitions again with sfdisk. I don't fully understand why > it's done again, this was just following the xcat process (for which > I can post the exact code if anyone's curious). > -And of course restore all partitions one at a time > > When I tried to boot it back up, it got as far as printing "GRUB" and > hung there. I need some help here, I'm not sure what's going on. One thing to check is to stop before rebooting and see if grub is installed correctly, or if any errors happen during grub-install. For that, it may be worth running through the script line by line or at least logging the output of each step w/ debug output printed before each command as needed.
Like I said, I did the entire procedure manually... entered each command myself so I knew exactly what was running. Once I get it working manually, I can easily find out if my script is doing things any differently.
How do I tell if grub is installed correctly?
"grubby" has some probe options that should do this. See "man grubby"?
> > I tried a different order to restoring partition/mbr info: Restore > partition stuff with sfdisk, and then the mbr with dd. I was thinking > sfdisk may have overwritten the mbr or something, but I got the
same
> results. Grub lives in the MBR, though are you calling grub-install after all of that?
Right. I'm not calling grub-install. I didn't think it was necessary. Grub lives in the mbr, which is the first 512 bytes of the drive. I'm saving the mbr to a file and restoring it back. Shouldn't that be sufficient?
In theory, assuming it's not a GPT partition /and/ grub lives in the MBR (both of which can't really be assumed), yes.
It's best to use grubby, the command line tool, for manipulating grub. As a bonus it also knows how to manipulate lilo and elilo. There is some code in koan that references a few common grubby commands, though you'll probably want to change this around.
--bad-image-ok does not work, but otherwise what you see koan using for the live CD is close.
Also there are some bits of the live config script that are using grub-install.
So I suppose I'm wrong in assuming that saving the mbr+partition layout and each partitions' contents, and then restoring each component is not sufficient for perfectly duplicating a hard drive. Where else could data lie?
I'll look into using grubby to make sure grub is installed, but I still don't know why this doesn't work as is, things should be restored exactly as they were, right?
And further, what about systems that don't use grub, such as windows? How are we going to do this so that it's still cross platform?
-Andrew
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Andrew Brown wrote:
Running "grub-install /dev/sda" in a live environment "fixes" the machine so it will boot.
Unless there's a good reason not to though, I'd like to know why the current method doesn't work, and find a general solution that will work for any setup. See my last email.
And also, I can't seem to find "grubby". It's not included on the fedora rescue cd or ubuntu live cd, and the fedora live cd keeps giving me a kernel panic when I try to boot it. But that's a separate issue for now.
Not sure why your MBR isn't being copied.
Grubby is /sbin/grubby. It is part of the mkinitrd package and should be on all Fedora live CD environments (as well as the non-Live ones). Ubuntu probably doesn't use it.
It's probably worth filing a bug against livecd-creator (or perhaps another component) for the kernel panic.
-Andrew
On Wed, Aug 20, 2008 at 2:25 PM, Andrew Brown <ambrown4@ncsu.edu mailto:ambrown4@ncsu.edu> wrote:
On Wed, Aug 20, 2008 at 7:44 AM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com>> wrote: Andrew Brown wrote: > On Tue, Aug 19, 2008 at 6:16 PM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com> > <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>>> wrote: > > Andrew Brown wrote: > > Okay, a few things since yesterday: > > I'm not worrying about the hard drive device issue for the > moment, it > > seems to be related to whether the bladecenter media tray is > assigned > > to that blade or not. > > > > I've also edited the code to ignore listed partitions of type > "Empty" > > or "Extended" > > Is there a new attachment we can look at for this? > > > I've attached the most recent base.cfg which contains the code. Keep > in mind that today I did things manually though, not using the script. > > > > > > > But somehow the process isn't working. I followed the process very > > closely of xcat, a similar provisioning engine. After taking and > > restoring an image, it doesn't boot. > > > > > > I tried the process manually today. That is, I booted with a > live cd > > and ran each command myself. Saved the mbr, saved the partition > table > > with sfdisk, and saved the contents of each partition of a freshly > > installed linux installation. > > > > Then I went to the next blade, identical hardware and setup, and > > booted the live cd up. > > -Restored partition entries with sfdisk > > -Restored mbr with dd > > -Restored partitions again with sfdisk. I don't fully > understand why > > it's done again, this was just following the xcat process (for > which > > I can post the exact code if anyone's curious). > > -And of course restore all partitions one at a time > > > > When I tried to boot it back up, it got as far as printing > "GRUB" and > > hung there. I need some help here, I'm not sure what's going on. > > One thing to check is to stop before rebooting and see if grub is > installed correctly, or if any errors happen during grub-install. > For > that, it may be worth running through the script line by line or at > least logging the output of each step w/ debug output printed before > each command as needed. > > > Like I said, I did the entire procedure manually... entered each > command myself so I knew exactly what was running. Once I get it > working manually, I can easily find out if my script is doing things > any differently. > > How do I tell if grub is installed correctly? "grubby" has some probe options that should do this. See "man grubby"? > > > > > > > > I tried a different order to restoring partition/mbr info: Restore > > partition stuff with sfdisk, and then the mbr with dd. I was > thinking > > sfdisk may have overwritten the mbr or something, but I got the same > > results. > > Grub lives in the MBR, though are you calling grub-install after > all of > that? > > > Right. I'm not calling grub-install. I didn't think it was > necessary. Grub lives in the mbr, which is the first 512 bytes of the > drive. I'm saving the mbr to a file and restoring it back. Shouldn't > that be sufficient? In theory, assuming it's not a GPT partition /and/ grub lives in the MBR (both of which can't really be assumed), yes. It's best to use grubby, the command line tool, for manipulating grub. As a bonus it also knows how to manipulate lilo and elilo. There is some code in koan that references a few common grubby commands, though you'll probably want to change this around. --bad-image-ok does not work, but otherwise what you see koan using for the live CD is close. Also there are some bits of the live config script that are using grub-install. So I suppose I'm wrong in assuming that saving the mbr+partition layout and each partitions' contents, and then restoring each component is not sufficient for perfectly duplicating a hard drive. Where else could data lie? I'll look into using grubby to make sure grub is installed, but I still don't know why this doesn't work as is, things should be restored exactly as they were, right? And further, what about systems that don't use grub, such as windows? How are we going to do this so that it's still cross platform? -Andrew _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Andrew Brown wrote:
Running "grub-install /dev/sda" in a live environment "fixes" the machine so it will boot.
Unless there's a good reason not to though, I'd like to know why the current method doesn't work, and find a general solution that will work for any setup. See my last email.
And also, I can't seem to find "grubby". It's not included on the fedora rescue cd or ubuntu live cd, and the fedora live cd keeps giving me a kernel panic when I try to boot it. But that's a separate issue for now. -Andrew
grub-install is also fine. Grubby is what you use to manipulate grub.conf once installed. Apologies for the confusion there.
--Michael
On Wed, Aug 20, 2008 at 2:25 PM, Andrew Brown <ambrown4@ncsu.edu mailto:ambrown4@ncsu.edu> wrote:
On Wed, Aug 20, 2008 at 7:44 AM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com>> wrote: Andrew Brown wrote: > On Tue, Aug 19, 2008 at 6:16 PM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com> > <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>>> wrote: > > Andrew Brown wrote: > > Okay, a few things since yesterday: > > I'm not worrying about the hard drive device issue for the > moment, it > > seems to be related to whether the bladecenter media tray is > assigned > > to that blade or not. > > > > I've also edited the code to ignore listed partitions of type > "Empty" > > or "Extended" > > Is there a new attachment we can look at for this? > > > I've attached the most recent base.cfg which contains the code. Keep > in mind that today I did things manually though, not using the script. > > > > > > > But somehow the process isn't working. I followed the process very > > closely of xcat, a similar provisioning engine. After taking and > > restoring an image, it doesn't boot. > > > > > > I tried the process manually today. That is, I booted with a > live cd > > and ran each command myself. Saved the mbr, saved the partition > table > > with sfdisk, and saved the contents of each partition of a freshly > > installed linux installation. > > > > Then I went to the next blade, identical hardware and setup, and > > booted the live cd up. > > -Restored partition entries with sfdisk > > -Restored mbr with dd > > -Restored partitions again with sfdisk. I don't fully > understand why > > it's done again, this was just following the xcat process (for > which > > I can post the exact code if anyone's curious). > > -And of course restore all partitions one at a time > > > > When I tried to boot it back up, it got as far as printing > "GRUB" and > > hung there. I need some help here, I'm not sure what's going on. > > One thing to check is to stop before rebooting and see if grub is > installed correctly, or if any errors happen during grub-install. > For > that, it may be worth running through the script line by line or at > least logging the output of each step w/ debug output printed before > each command as needed. > > > Like I said, I did the entire procedure manually... entered each > command myself so I knew exactly what was running. Once I get it > working manually, I can easily find out if my script is doing things > any differently. > > How do I tell if grub is installed correctly? "grubby" has some probe options that should do this. See "man grubby"? > > > > > > > > I tried a different order to restoring partition/mbr info: Restore > > partition stuff with sfdisk, and then the mbr with dd. I was > thinking > > sfdisk may have overwritten the mbr or something, but I got the same > > results. > > Grub lives in the MBR, though are you calling grub-install after > all of > that? > > > Right. I'm not calling grub-install. I didn't think it was > necessary. Grub lives in the mbr, which is the first 512 bytes of the > drive. I'm saving the mbr to a file and restoring it back. Shouldn't > that be sufficient? In theory, assuming it's not a GPT partition /and/ grub lives in the MBR (both of which can't really be assumed), yes. It's best to use grubby, the command line tool, for manipulating grub. As a bonus it also knows how to manipulate lilo and elilo. There is some code in koan that references a few common grubby commands, though you'll probably want to change this around. --bad-image-ok does not work, but otherwise what you see koan using for the live CD is close. Also there are some bits of the live config script that are using grub-install. So I suppose I'm wrong in assuming that saving the mbr+partition layout and each partitions' contents, and then restoring each component is not sufficient for perfectly duplicating a hard drive. Where else could data lie? I'll look into using grubby to make sure grub is installed, but I still don't know why this doesn't work as is, things should be restored exactly as they were, right? And further, what about systems that don't use grub, such as windows? How are we going to do this so that it's still cross platform? -Andrew _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Things have been going slow for me since I started classes, so sorry for the sparse updates.
I never did figure out why restoring the mbr and partitions separately produced an unbootable system, and it's something I'll need to eventually solve.
However, for now I've taken a step back and just focused on getting entire drives cloned with dd. Now instead of copying each partition separately, I just copy all of /dev/sda (or whatever is configured) to file.
The attached base.cfg kickstart file is attached. I just finished testing it. It's slow, takes up a lot of space, but it works. I took an image of a machine, and restored it to another machine with identical hardware.
Next step is to get the partition by partition copying working, which is what I was trying to do before. I'll do some tests to try to figure out what I was missing with my previous approach.
-Andrew
Andrew Brown wrote:
Things have been going slow for me since I started classes, so sorry for the sparse updates.
I never did figure out why restoring the mbr and partitions separately produced an unbootable system, and it's something I'll need to eventually solve.
However, for now I've taken a step back and just focused on getting entire drives cloned with dd. Now instead of copying each partition separately, I just copy all of /dev/sda (or whatever is configured) to file.
The attached base.cfg kickstart file is attached. I just finished testing it. It's slow, takes up a lot of space, but it works. I took an image of a machine, and restored it to another machine with identical hardware.
Next step is to get the partition by partition copying working, which is what I was trying to do before. I'll do some tests to try to figure out what I was missing with my previous approach.
-Andrew
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
That's ok, we're chasing lots of random features at the same time, so no rush on this one. Ultimately we have a pretty good solution now for supporting foreign OS's by using "cobbler image add" and "koan with --image" to install ISO's, so we have a route to installing Windows and foreign OS's in fullvirt that way.
Physical cloning tools would be interesting but I think they are not nearly as critical (and would be a case where I'd rather see p2v migration first).
When referring to dd (I imagine over NFS), how slow does slow mean? Just curious there (I can imagine pretty slow).
Attachment seems to be missing? Can you resend it?
--Michael
On Wed, Aug 27, 2008 at 3:44 PM, Michael DeHaan mdehaan@redhat.com wrote:
That's ok, we're chasing lots of random features at the same time, so no rush on this one. Ultimately we have a pretty good solution now for supporting foreign OS's by using "cobbler image add" and "koan with --image" to install ISO's, so we have a route to installing Windows and foreign OS's in fullvirt that way.
Physical cloning tools would be interesting but I think they are not nearly as critical (and would be a case where I'd rather see p2v migration first).
When referring to dd (I imagine over NFS), how slow does slow mean? Just curious there (I can imagine pretty slow).
Attachment seems to be missing? Can you resend it?
--Michael
I attached it, I really did!... maybe not.
Anyways, I don't have an exact time, but I'd guess it takes 30-60 minutes for 40 gigabytes over nfs maybe. I'm not sure, I usually leave it and go do something else.
Also, I like that this will be immediately supported through the distro add command by passing in the kernel and initrd. So once this works, there's nothing else to do except maybe have a convenience function.
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Andrew Brown wrote:
On Wed, Aug 27, 2008 at 3:44 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
That's ok, we're chasing lots of random features at the same time, so no rush on this one. Ultimately we have a pretty good solution now for supporting foreign OS's by using "cobbler image add" and "koan with --image" to install ISO's, so we have a route to installing Windows and foreign OS's in fullvirt that way. Physical cloning tools would be interesting but I think they are not nearly as critical (and would be a case where I'd rather see p2v migration first). When referring to dd (I imagine over NFS), how slow does slow mean? Just curious there (I can imagine pretty slow). Attachment seems to be missing? Can you resend it? --Michael
I attached it, I really did!... maybe not.
Anyways, I don't have an exact time, but I'd guess it takes 30-60 minutes for 40 gigabytes over nfs maybe. I'm not sure, I usually leave it and go do something else.
Also, I like that this will be immediately supported through the distro add command by passing in the kernel and initrd. So once this works, there's nothing else to do except maybe have a convenience function.
_______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
30-60's not horrific if you really need it done.
Just being kernel+initrd+kernel arguments (--kopts) is fantastically easy to set up.
Also very nice that the embedded script is Python :)
See if you can get it going via partimage, and either way, let's set up a Wiki page for this showing the instructions on how to build the live image and use it in cobbler. I asked earlier about hosting the image via torrent on Fedora infrastructure, and it's possible to get space for that so folks do not have to build it.
--Michael
On Wed, Aug 27, 2008 at 4:29 PM, Michael DeHaan mdehaan@redhat.com wrote:
30-60's not horrific if you really need it done.
Just being kernel+initrd+kernel arguments (--kopts) is fantastically easy to set up.
Also very nice that the embedded script is Python :)
See if you can get it going via partimage, and either way, let's set up a Wiki page for this showing the instructions on how to build the live image and use it in cobbler. I asked earlier about hosting the image via torrent on Fedora infrastructure, and it's possible to get space for that so folks do not have to build it.
--Michael
Okay. I'll keep working on this whenever I can (working around my classes). I'll let you know my progress. -Andrew
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
So I've figured out the issue (finally). Apparently, the optional grub stage 1.5 is stored in the normally unused space between the mbr and the start of the first partition. The image I chose to use for my testing did use this grub stage 1.5 (I think fedora doesn't by default though), and of course, I wasn't capturing that data in my images (I only recorded mbr, partition table, and partition contents)
So I've modified my script to capture three things now. 1) the first 63 sectors (63 * 512 bytes) of the hard drive. This includes the mbr and all space before the first partition, which starts on sector 63 for all machines I've looked at. I'm assuming this is always the case (is this a valid assumption?)
2) The output from sfdisk -d, to capture extended partitions
3) A full image of each partition using dd.
I've tested this and it seems to work perfectly. I've attached the most recent version of my kickstart file which includes the script.
The next step at this point, and correct me if I'm wrong, is to get partimage or some other utility to stand in for dd. I was taking a look at partimage-ng, which looks like a full rewrite of partimage that looks promising. It also has built in capability to fall back to a dd like copy for unknown filesystems.
Oh, and also: Unless partimage somehow captures that data automatically, as far as I can tell XCat's imaging functionality has the same issue. I figure we just hadn't run into it yet because all the Red Hat based images we have don't use the grub stage 1.5.
-Andrew Brown
Andrew Brown wrote:
So I've figured out the issue (finally). Apparently, the optional grub stage 1.5 is stored in the normally unused space between the mbr and the start of the first partition. The image I chose to use for my testing did use this grub stage 1.5 (I think fedora doesn't by default though), and of course, I wasn't capturing that data in my images (I only recorded mbr, partition table, and partition contents)
So I've modified my script to capture three things now.
- the first 63 sectors (63 * 512 bytes) of the hard drive. This
includes the mbr and all space before the first partition, which starts on sector 63 for all machines I've looked at. I'm assuming this is always the case (is this a valid assumption?)
The output from sfdisk -d, to capture extended partitions
A full image of each partition using dd.
I've tested this and it seems to work perfectly. I've attached the most recent version of my kickstart file which includes the script.
The next step at this point, and correct me if I'm wrong, is to get partimage or some other utility to stand in for dd. I was taking a look at partimage-ng, which looks like a full rewrite of partimage that looks promising. It also has built in capability to fall back to a dd like copy for unknown filesystems.
Oh, and also: Unless partimage somehow captures that data automatically, as far as I can tell XCat's imaging functionality has the same issue. I figure we just hadn't run into it yet because all the Red Hat based images we have don't use the grub stage 1.5.
-Andrew Brown
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Excellent. Glad to see this is still going on. I've added this to "/contrib" in Cobbler's git and will go about testing this shortly (as in next thing I do here).
Yes, moving to something a bit smarter than dd would be good. If we continue to go down that route, likely we would want to see partimage-ng packaged for fedora as well -- so that we'd be able to host the cloner image up on Fedora's infrastructure so other people wouldn't have to build it (having all things part of Fedora is a requirement). Does anyone else have comments/experience on partimage vs partimage-ng?
After I get testing together (assuming it all works), I'll add some instructions to the Wiki of how to use this in conjunction with cobbler commands. I have some spare machines here so I'm interested to see how it all works out. That might warrant making some commands to make that easier, TBD.
I think the "newkoan" part of the config is unneccessary and left over from koan's live image, so I'll probably clean that up. I'm guessing we can also probably pare-down the package set some and disable a few extra services, though that's not major.
Anyhow, very cool.
--Michael
On Thu, Sep 11, 2008 at 1:22 PM, Michael DeHaan mdehaan@redhat.com wrote:
Excellent. Glad to see this is still going on. I've added this to "/contrib" in Cobbler's git and will go about testing this shortly (as in next thing I do here).
Yes, moving to something a bit smarter than dd would be good. If we continue to go down that route, likely we would want to see partimage-ng packaged for fedora as well -- so that we'd be able to host the cloner image up on Fedora's infrastructure so other people wouldn't have to build it (having all things part of Fedora is a requirement). Does anyone else have comments/experience on partimage vs partimage-ng?
After I get testing together (assuming it all works), I'll add some instructions to the Wiki of how to use this in conjunction with cobbler commands. I have some spare machines here so I'm interested to see how it all works out. That might warrant making some commands to make that easier, TBD.
I think the "newkoan" part of the config is unneccessary and left over from koan's live image, so I'll probably clean that up. I'm guessing we can also probably pare-down the package set some and disable a few extra services, though that's not major.
Anyhow, very cool.
--Michael
Woah, I got your emails all out of order. Just got this one somehow.
Anyways, the NFS export *is* running as no_root_squash. It didn't occur to me earlier, but yeah, that could be an issue. The script could easily run as another user (other than root), but then it wouldn't have permission to write to the hard drive device. I'm not sure of a good way to solve that.
-Andrew
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Andrew Brown wrote:
On Thu, Sep 11, 2008 at 1:22 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Excellent. Glad to see this is still going on. I've added this to "/contrib" in Cobbler's git and will go about testing this shortly (as in next thing I do here). Yes, moving to something a bit smarter than dd would be good. If we continue to go down that route, likely we would want to see partimage-ng packaged for fedora as well -- so that we'd be able to host the cloner image up on Fedora's infrastructure so other people wouldn't have to build it (having all things part of Fedora is a requirement). Does anyone else have comments/experience on partimage vs partimage-ng? After I get testing together (assuming it all works), I'll add some instructions to the Wiki of how to use this in conjunction with cobbler commands. I have some spare machines here so I'm interested to see how it all works out. That might warrant making some commands to make that easier, TBD. I think the "newkoan" part of the config is unneccessary and left over from koan's live image, so I'll probably clean that up. I'm guessing we can also probably pare-down the package set some and disable a few extra services, though that's not major. Anyhow, very cool. --Michael
Woah, I got your emails all out of order. Just got this one somehow.
Anyways, the NFS export /is/ running as no_root_squash. It didn't occur to me earlier, but yeah, that could be an issue. The script could easily run as another user (other than root), but then it wouldn't have permission to write to the hard drive device. I'm not sure of a good way to solve that.
I think trying to do this securely in the NFS realm is going to be difficult if not impossible, indeed.
Maybe we just document it with scary blinking lights on the page that (when using this feature) it's very easy to replace disk images without hosts.allow, hosts.deny, /etc/exports, and/or iptables locked down to specify what machines can write to that NFS share. The vulnerability is the option to replace someone's partition before they clone it to lots of other machines, basically injecting new content. However if this is limited such that only machines in the datacenter can access this content, then the problem becomes ensuring users can't access /those/ machines.
Doing any sort of better locked down NFS install is a huge problem for rw NFS, especially when the user is a CD -- we can't just stick the password in the cloner image as the cloner image is public.
Other proposals welcome, perhaps ok for now.
Naturally since this NFS feature is not available until someone turns it on and so configures their cloner images, we aren't exposing a vulnerability in a place where users can't see that message about limitations -- they'll know the implications when using the feature.
This may in fact be fine for most secured lab setups, just definitely not something you'd want on an open college network.
--Michael
On Thu, Sep 11, 2008 at 9:03 PM, Michael DeHaan mdehaan@redhat.com wrote:
I think trying to do this securely in the NFS realm is going to be difficult if not impossible, indeed.
Maybe we just document it with scary blinking lights on the page that (when using this feature) it's very easy to replace disk images without hosts.allow, hosts.deny, /etc/exports, and/or iptables locked down to specify what machines can write to that NFS share. The vulnerability is the option to replace someone's partition before they clone it to lots of other machines, basically injecting new content. However if this is limited such that only machines in the datacenter can access this content, then the problem becomes ensuring users can't access /those/ machines.
Doing any sort of better locked down NFS install is a huge problem for rw NFS, especially when the user is a CD -- we can't just stick the password in the cloner image as the cloner image is public.
Other proposals welcome, perhaps ok for now.
Naturally since this NFS feature is not available until someone turns it on and so configures their cloner images, we aren't exposing a vulnerability in a place where users can't see that message about limitations -- they'll know the implications when using the feature.
This may in fact be fine for most secured lab setups, just definitely not something you'd want on an open college network.
--Michael
I was thinking of some setup with ssh and host keys, but any host key would need to be on the livecd image itself. I can't think of a good way to secure this system, NFS or not. I suppose it's okay if this feature is only practical inside of a secure lab setup though.
Andrew Brown wrote:
So I've figured out the issue (finally). Apparently, the optional grub stage 1.5 is stored in the normally unused space between the mbr and the start of the first partition. The image I chose to use for my testing did use this grub stage 1.5 (I think fedora doesn't by default though), and of course, I wasn't capturing that data in my images (I only recorded mbr, partition table, and partition contents)
So I've modified my script to capture three things now.
- the first 63 sectors (63 * 512 bytes) of the hard drive. This
includes the mbr and all space before the first partition, which starts on sector 63 for all machines I've looked at. I'm assuming this is always the case (is this a valid assumption?)
The output from sfdisk -d, to capture extended partitions
A full image of each partition using dd.
I've tested this and it seems to work perfectly. I've attached the most recent version of my kickstart file which includes the script.
The next step at this point, and correct me if I'm wrong, is to get partimage or some other utility to stand in for dd. I was taking a look at partimage-ng, which looks like a full rewrite of partimage that looks promising. It also has built in capability to fall back to a dd like copy for unknown filesystems.
Oh, and also: Unless partimage somehow captures that data automatically, as far as I can tell XCat's imaging functionality has the same issue. I figure we just hadn't run into it yet because all the Red Hat based images we have don't use the grub stage 1.5.
-Andrew Brown
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
This file also came across without a GPL license header. Can you please add one (GPLv2+) as found on the other cobbler files or otherwise reply and say I can add it? This is also needed for us to host the ISO in a common download location.
Thanks!
--Michael
On Thu, Sep 11, 2008 at 1:38 PM, Michael DeHaan mdehaan@redhat.com wrote:
This file also came across without a GPL license header. Can you please add one (GPLv2+) as found on the other cobbler files or otherwise reply and say I can add it? This is also needed for us to host the ISO in a common download location.
Thanks!
--Michael
You have my permission to add a GPL header to the file I submitted. The base for that file was base.cfg from koan. If that was under GPL, then I suppose I'm obligated to have this one GPL also.
I got partimage-ng compiled under fedora (which is GPL v2 also by the way). Ran into a few snags with using gcc 4.3 (looks like they fixed it in devel, but not in the release I downloaded), but it otherwise works great.
I'm going to modify my script to use it. Do you know of an easy way to include a file to the livecd image? I was just going to include (for now) the compiled binary. We can eventually build an rpm and just include that, but I don't have much experience with packaging rpms so hopefully someone can help out with that. -Andrew
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Andrew Brown wrote:
On Thu, Sep 11, 2008 at 1:38 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
This file also came across without a GPL license header. Can you please add one (GPLv2+) as found on the other cobbler files or otherwise reply and say I can add it? This is also needed for us to host the ISO in a common download location. Thanks! --Michael
You have my permission to add a GPL header to the file I submitted. The base for that file was base.cfg from koan. If that was under GPL, then I suppose I'm obligated to have this one GPL also.
I got partimage-ng compiled under fedora (which is GPL v2 also by the way). Ran into a few snags with using gcc 4.3 (looks like they fixed it in devel, but not in the release I downloaded), but it otherwise works great.
I'm going to modify my script to use it. Do you know of an easy way to include a file to the livecd image? I was just going to include (for now) the compiled binary. We can eventually build an rpm and just include that, but I don't have much experience with packaging rpms so hopefully someone can help out with that.
Including an RPM is easy. Including a file is not. An ugly trick for testing might just be to have your CD wget that file from another server until you can package it for RPM, which I'd be more than happy to help with it that proves to be the way we want to go. Others here can help also.
The RPM steps, for completeness, are:
mkdir /tmp/myrepo cp *.rpm /tmp/myrepo yum install yum-utils createrepo /tmp/myrepo
Then just reference it in the "repo" part of base.cfg ... (like I did with koan for the cobbler live CD)
-Andrew
_______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Andrew Brown wrote:
On Thu, Sep 11, 2008 at 1:38 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
This file also came across without a GPL license header. Can you please add one (GPLv2+) as found on the other cobbler files or otherwise reply and say I can add it? This is also needed for us to host the ISO in a common download location. Thanks! --Michael
You have my permission to add a GPL header to the file I submitted. The base for that file was base.cfg from koan. If that was under GPL, then I suppose I'm obligated to have this one GPL also.
I got partimage-ng compiled under fedora (which is GPL v2 also by the way). Ran into a few snags with using gcc 4.3 (looks like they fixed it in devel, but not in the release I downloaded), but it otherwise works great.
I'm going to modify my script to use it. Do you know of an easy way to include a file to the livecd image? I was just going to include (for now) the compiled binary. We can eventually build an rpm and just include that, but I don't have much experience with packaging rpms so hopefully someone can help out with that. -Andrew
_______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Further question, how do you have /etc/exports configured on the NFS box? Does it have root squash enabled or is it otherwise wide open? I presume the live CD stuff is running as root.
If it's the latter, that may be acceptable, though we need to be very careful about documenting those limitations. Specifying a user at minimum is probably a good idea.
--Michael
As a part of spacewalk (https://fedorahosted.org/spacewalk/wiki) we were planning to add an interactive cobbler setup script that basically asks a bunch of questions and sets up the cobbler configs accordingly. Basically we are filling out things that cobbler check asks for..
Given this context I was wondering if it would make sense to have a cobbler-setup tool as a part of the cobbler upstream itself. For example we can have a good default configuration setup and then have the user run this script where it asks questions like "do you want PXE setup" and if so "provide the next server ip" and so on... We can either do it that way or in addition have cobbler setup take in arguments like --enable-pxe --next-server-ip=xxx.xxx.xxx.xxx and cobble up a default cobbler configuration... Here is an example workflow
# yum install cobbler # cobbler-setup .....question - answer session.... ...Your cobbler configuration has been setup running cobbler check.... ..looks ok... ...start httpd..
# cobbler import ....
Please let me know if you'd find such a script useful. Any suggestions or comments about the way you'd like the setup script to function would be great..
Partha
Partha Aji wrote:
As a part of spacewalk (https://fedorahosted.org/spacewalk/wiki) we were planning to add an interactive cobbler setup script that basically asks a bunch of questions and sets up the cobbler configs accordingly. Basically we are filling out things that cobbler check asks for..
Given this context I was wondering if it would make sense to have a cobbler-setup tool as a part of the cobbler upstream itself. For example we can have a good default configuration setup and then have the user run this script where it asks questions like "do you want PXE setup" and if so "provide the next server ip" and so on... We can either do it that way or in addition have cobbler setup take in arguments like --enable-pxe --next-server-ip=xxx.xxx.xxx.xxx and cobble up a default cobbler configuration... Here is an example workflow
# yum install cobbler # cobbler-setup .....question - answer session.... ...Your cobbler configuration has been setup running cobbler check.... ..looks ok... ...start httpd..
# cobbler import ....
Please let me know if you'd find such a script useful. Any suggestions or comments about the way you'd like the setup script to function would be great..
Partha
I can see this being useful. Most of the user questions I get on IRC from new users involve setting up XMLRPC/the-web-app and auth-type questions, so if the installer helps with those that would be useful. I don't think it would be a good idea to ask about every config file option, but the important ones would be good to have.
Some things I'd recommend.
(A) don't require this setup script, but it can be there to walk new users through setup. (B) Use Cheetah and /usr/share/cobbler/modules.conf.template and /usr/share/cobbler/settings.template to build out the file (C) All questions have good reasonable defaults, except for the question about "server address". (C) Questions that should be asked:
-- What is the resolvable address/ip of this server [enter for autodiscover]? -- Do you want to enable Cobbler's DHCP management? [y/n] (default no) -- Which DHCP module do you want to use? [isc/dnsmasq] (default isc) -- Do you want to enable Cobbler's DNS management feature? [y/n] (default no) -- Which DNS module do you want to use? [bind/dnsmasq] (default bind) -- Are your systems typically set to PXE first in the BIOS order? [default :no] (this would adjust pxe_just_once, default 0) -- Make cobbler managed yum repos available to installed systems (default no) (this adjusts yum_post_install_mirror) -- What webui authentication mechnism do you want to use [default: configfile] -- (If configfile) Enter default username/password for webapp -- Possibly prompt for default virtualization settings, such as xen or qemu, how much RAM by default, etc -- (For spacewalk, we'd probably want to launch this as /usr/bin/setup-cobbler --defaults=spacewalk to default to authn_spacewalk, etc?) -- ...
I don't believe spacewalk is going to use cobbler import, so we can skip that step.
The setup script should probably mention what the next steps are though, in which case, mentioning that the user should read the manpage WRT "cobbler import" may be a fair step.
Anyone else have comments?
--Michael
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler@lists.fedorahosted.org