buildiso USB ?

[Dan White]

Did anyone ever come up with a reliable recipe for making a bootable USB-stick from a generated.iso ?

If so, I could use it.

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

[Alex L.]

Hi Dan,

On Tue, 22 Nov 2011, Dan White wrote:
> Did anyone ever come up with a reliable recipe for making a bootable 
> USB-stick from a generated.iso ?

try the following out and let me know how relieable it is :)

Let's assume you have your USB-stick on "/dev/sdb" and you have "syslinux"
> = 3.0 installed on your Linux box, then:

(1) by using "fdisk /dev/sdb" make sure you create a bootable FAT 
partition "/dev/sdb1"

(2) create new fat filesystem on the USB stick by using 
"mkfs.vfat /dev/sdb1"

(3) setup the bootloader by executing "syslinux /dev/sdb1"

(4) create your buildiso "cobbler buildiso --systems='host.domain.net'"

(5) step 4 should have created beside the "generated.iso" file also a 
"buildiso" directory; copy the created files from "buildiso/isolinux/*" to 
"/dev/sdb1" (mount it)

(6) rename the "isolinux.cfg" on "/dev/sdb1" to "syslinux.cfg"

(7) umount "/dev/sdb1" and try to boot with the USB-stick, just don't 
forget to disconnect it on time if you are using "clearpart" in your 
kickstart file.
> If so, I could use it.

Hope that helps,

best regards,

Alex

[Dan White]

Thanks.  I will try these steps.

I used livecd-iso-to-disk to make a stick that booted a box for me, but that box has other issues, so I need to try again.

There was a certain amount of trial-and-error in order to get the stick into a state that livecd-iso-to-disk would work on it.

One more question (for now):  Does the --standalone option make a self-contained iso, thus eliminating the need to download anything from the Cobbler Server ?

On Nov 22, 2011, at 3:27 PM, Alex L. wrote:
> Hi Dan,
>
> On Tue, 22 Nov 2011, Dan White wrote:
> > Did anyone ever come up with a reliable recipe for making a bootable 
> > USB-stick from a generated.iso ?
>
> try the following out and let me know how relieable it is :)
>
> Let's assume you have your USB-stick on "/dev/sdb" and you have "syslinux"
> > = 3.0 installed on your Linux box, then:
>
> (1) by using "fdisk /dev/sdb" make sure you create a bootable FAT 
> partition "/dev/sdb1"
>
> (2) create new fat filesystem on the USB stick by using 
> "mkfs.vfat /dev/sdb1"
>
> (3) setup the bootloader by executing "syslinux /dev/sdb1"
>
> (4) create your buildiso "cobbler buildiso --systems='host.domain.net'"
>
> (5) step 4 should have created beside the "generated.iso" file also a 
> "buildiso" directory; copy the created files from "buildiso/isolinux/*" to 
> "/dev/sdb1" (mount it)
>
> (6) rename the "isolinux.cfg" on "/dev/sdb1" to "syslinux.cfg"
>
> (7) umount "/dev/sdb1" and try to boot with the USB-stick, just don't 
> forget to disconnect it on time if you are using "clearpart" in your 
> kickstart file.
> > If so, I could use it.
>
> Hope that helps,
>
> best regards,
>
> Alex
>
> cobbler mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/cobbler

[Dan White]

I found an example of the use of --standalone

http://sugizo.wordpress.com/2011/10/13/ubuntu-install-and-configure-cobbler/

• Build ISO
   • Build ISO Base on Distro
      cobbler buildiso –iso=/tmp/Fedora-15-x86_64.iso –distro=”Fedora-15-x86_64″ –standalone
   • Build ISO Base on Profile
      cobbler buildiso –iso=/tmp/Fedora-15-x86_64.iso –profiles=”Fedora-15-x86_64″
   • Build ISO Base on System
      cobbler buildiso –iso=/tmp/fedora.iso –systems=”fedora”

I was hoping to use a combo like:
      cobbler buildiso --profiles="Fedora-15-x86_64" --systems="server1.foo.fqdn, server1.foo.fqdn, server2.foo.fqdn, server3.foo.fqdn" --standalone

but this example implies I have to include a distro.

Will this work ? :   cobbler buildiso --profiles="this" --distro="that" --systems="one,two,three,four" --standalone

On Nov 22, 2011, at 7:31 PM, Dan White wrote:
> Thanks.  I will try these steps.
>
> I used livecd-iso-to-disk to make a stick that booted a box for me, but that box has other issues, so I need to try again.
>
> There was a certain amount of trial-and-error in order to get the stick into a state that livecd-iso-to-disk would work on it.
>
> One more question (for now):  Does the --standalone option make a self-contained iso, thus eliminating the need to download anything from the Cobbler Server ?
>
> On Nov 22, 2011, at 3:27 PM, Alex L. wrote:
> > Hi Dan,
> >
> > On Tue, 22 Nov 2011, Dan White wrote:
> > > Did anyone ever come up with a reliable recipe for making a bootable 
> > > USB-stick from a generated.iso ?
> >
> > try the following out and let me know how relieable it is :)
> >
> > Let's assume you have your USB-stick on "/dev/sdb" and you have "syslinux"
> > > = 3.0 installed on your Linux box, then:
> >
> > (1) by using "fdisk /dev/sdb" make sure you create a bootable FAT 
> > partition "/dev/sdb1"
> >
> > (2) create new fat filesystem on the USB stick by using 
> > "mkfs.vfat /dev/sdb1"
> >
> > (3) setup the bootloader by executing "syslinux /dev/sdb1"
> >
> > (4) create your buildiso "cobbler buildiso --systems='host.domain.net'"
> >
> > (5) step 4 should have created beside the "generated.iso" file also a 
> > "buildiso" directory; copy the created files from "buildiso/isolinux/*" to 
> > "/dev/sdb1" (mount it)
> >
> > (6) rename the "isolinux.cfg" on "/dev/sdb1" to "syslinux.cfg"
> >
> > (7) umount "/dev/sdb1" and try to boot with the USB-stick, just don't 
> > forget to disconnect it on time if you are using "clearpart" in your 
> > kickstart file.
> > > If so, I could use it.
> >
> > Hope that helps,
> >
> > best regards,
> >
> > Alex
> >
> > cobbler mailing list
> > [e-mail]
> > https://fedorahosted.org/mailman/listinfo/cobbler
>
> cobbler mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/cobbler

[Michael DeHaan]

Apologies on answering with code, but here's an interesting comment in
the source (buildiso.py):

def generate_standalone_iso(self,imagesdir,isolinuxdir,distname,filesource):
        """
        Create bootable CD image to be used for handsoff CD installations
        """
        # Get the distro object for the requested distro
        # and then get all of its descendants (profiles/sub-profiles/systems)

And elsewhere in the code:

if standalone:
            if profiles is not None or systems is not None:
                utils.die(self.logger,"When building a standalone ISO,
use --distro only instead of --profiles/--systems")
            elif distro is None:
                utils.die(self.logger,"When building a standalone ISO,
you must specify a --distro")
            if source != None and not os.path.exists(source):
                utils.die(self.logger,"The source specified (%s) does
not exist" % source)

It looks like that will give you everything under the profiles/systems
and does not actually filter them to specific profiles.
And it should yell at you and tell you this when you try it :)

Making it understand --profiles or --systems as a kind of blacklist
seems like an easy patch.

--Michael

On Tue, Nov 22, 2011 at 7:40 PM, Dan White  wrote:
> I found an example of the use of --standalone
>
> http://sugizo.wordpress.com/2011/10/13/ubuntu-install-and-configure-cobbler/
>
> • Build ISO
>   • Build ISO Base on Distro
>      cobbler buildiso –iso=/tmp/Fedora-15-x86_64.iso –distro=”Fedora-15-x86_64″ –standalone
>   • Build ISO Base on Profile
>      cobbler buildiso –iso=/tmp/Fedora-15-x86_64.iso –profiles=”Fedora-15-x86_64″
>   • Build ISO Base on System
>      cobbler buildiso –iso=/tmp/fedora.iso –systems=”fedora”
>
> I was hoping to use a combo like:
>      cobbler buildiso --profiles="Fedora-15-x86_64" --systems="server1.foo.fqdn, server1.foo.fqdn, server2.foo.fqdn, server3.foo.fqdn" --standalone
>
> but this example implies I have to include a distro.
>
> Will this work ? :   cobbler buildiso --profiles="this" --distro="that" --systems="one,two,three,four" --standalone
>
> On Nov 22, 2011, at 7:31 PM, Dan White wrote:
> > Thanks.  I will try these steps.
> >
> > I used livecd-iso-to-disk to make a stick that booted a box for me, but that box has other issues, so I need to try again.
> >
> > There was a certain amount of trial-and-error in order to get the stick into a state that livecd-iso-to-disk would work on it.
> >
> > One more question (for now):  Does the --standalone option make a self-contained iso, thus eliminating the need to download anything from the Cobbler Server ?
> >
> > On Nov 22, 2011, at 3:27 PM, Alex L. wrote:
> > > Hi Dan,
> > >
> > > On Tue, 22 Nov 2011, Dan White wrote:
> > > > Did anyone ever come up with a reliable recipe for making a bootable
> > > > USB-stick from a generated.iso ?
> > >
> > > try the following out and let me know how relieable it is :)
> > >
> > > Let's assume you have your USB-stick on "/dev/sdb" and you have "syslinux"
> > > > = 3.0 installed on your Linux box, then:
> > >
> > > (1) by using "fdisk /dev/sdb" make sure you create a bootable FAT
> > > partition "/dev/sdb1"
> > >
> > > (2) create new fat filesystem on the USB stick by using
> > > "mkfs.vfat /dev/sdb1"
> > >
> > > (3) setup the bootloader by executing "syslinux /dev/sdb1"
> > >
> > > (4) create your buildiso "cobbler buildiso --systems='host.domain.net'"
> > >
> > > (5) step 4 should have created beside the "generated.iso" file also a
> > > "buildiso" directory; copy the created files from "buildiso/isolinux/*" to
> > > "/dev/sdb1" (mount it)
> > >
> > > (6) rename the "isolinux.cfg" on "/dev/sdb1" to "syslinux.cfg"
> > >
> > > (7) umount "/dev/sdb1" and try to boot with the USB-stick, just don't
> > > forget to disconnect it on time if you are using "clearpart" in your
> > > kickstart file.
> > > > If so, I could use it.
> > >
> > > Hope that helps,
> > >
> > > best regards,
> > >
> > > Alex
> > >
> > > cobbler mailing list
> > > [e-mail]
> > > https://fedorahosted.org/mailman/listinfo/cobbler
> >
> > cobbler mailing list
> > [e-mail]
> > https://fedorahosted.org/mailman/listinfo/cobbler
>
> cobbler mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/cobbler

[Dan White]

Good to see you on the list, Michael.  I thought you had moved on.
So it looks like the current buildiso will not give me what I am asking for.
Dang.

I was hoping for a standalone loader that I could customize to the system level.
This is because the DHCP in the environment I am in is run by the Microsoft Side of the House and I have not been able to get consistent behavior from the first part of the Cobbler net-boot process.

Reference: https://fedorahosted.org/pipermail/cobbler/2011-November/006889.html

Is buildiso.py self-contained ?  I would be willing to take a shot at getting it to do what I want.
Seems like a good feature to contribute for me to the stew.

On Nov 22, 2011, at 7:50 PM, Michael DeHaan wrote:
> Apologies on answering with code, but here's an interesting comment in
> the source (buildiso.py):
>
> def generate_standalone_iso(self,imagesdir,isolinuxdir,distname,filesource):
>        """
>        Create bootable CD image to be used for handsoff CD installations
>        """
>        # Get the distro object for the requested distro
>        # and then get all of its descendants (profiles/sub-profiles/systems)
>
> And elsewhere in the code:
>
> if standalone:
>            if profiles is not None or systems is not None:
>                utils.die(self.logger,"When building a standalone ISO,
> use --distro only instead of --profiles/--systems")
>            elif distro is None:
>                utils.die(self.logger,"When building a standalone ISO,
> you must specify a --distro")
>            if source != None and not os.path.exists(source):
>                utils.die(self.logger,"The source specified (%s) does
> not exist" % source)
>
> It looks like that will give you everything under the profiles/systems
> and does not actually filter them to specific profiles.
> And it should yell at you and tell you this when you try it :)
>
> Making it understand --profiles or --systems as a kind of blacklist
> seems like an easy patch.
>
> --Michael
>
> On Tue, Nov 22, 2011 at 7:40 PM, Dan White  wrote:
> > I found an example of the use of --standalone
> >
> > http://sugizo.wordpress.com/2011/10/13/ubuntu-install-and-configure-cobbler/
> >
> > • Build ISO
> >   • Build ISO Base on Distro
> >      cobbler buildiso –iso=/tmp/Fedora-15-x86_64.iso –distro=”Fedora-15-x86_64″ –standalone
> >   • Build ISO Base on Profile
> >      cobbler buildiso –iso=/tmp/Fedora-15-x86_64.iso –profiles=”Fedora-15-x86_64″
> >   • Build ISO Base on System
> >      cobbler buildiso –iso=/tmp/fedora.iso –systems=”fedora”
> >
> > I was hoping to use a combo like:
> >      cobbler buildiso --profiles="Fedora-15-x86_64" --systems="server1.foo.fqdn, server1.foo.fqdn, server2.foo.fqdn, server3.foo.fqdn" --standalone
> >
> > but this example implies I have to include a distro.
> >
> > Will this work ? :   cobbler buildiso --profiles="this" --distro="that" --systems="one,two,three,four" --standalone
> >
> > On Nov 22, 2011, at 7:31 PM, Dan White wrote:
> > > Thanks.  I will try these steps.
> > >
> > > I used livecd-iso-to-disk to make a stick that booted a box for me, but that box has other issues, so I need to try again.
> > >
> > > There was a certain amount of trial-and-error in order to get the stick into a state that livecd-iso-to-disk would work on it.
> > >
> > > One more question (for now):  Does the --standalone option make a self-contained iso, thus eliminating the need to download anything from the Cobbler Server ?
> > >
> > > On Nov 22, 2011, at 3:27 PM, Alex L. wrote:
> > > > Hi Dan,
> > > >
> > > > On Tue, 22 Nov 2011, Dan White wrote:
> > > > > Did anyone ever come up with a reliable recipe for making a bootable
> > > > > USB-stick from a generated.iso ?
> > > >
> > > > try the following out and let me know how relieable it is :)
> > > >
> > > > Let's assume you have your USB-stick on "/dev/sdb" and you have "syslinux"
> > > > > = 3.0 installed on your Linux box, then:
> > > >
> > > > (1) by using "fdisk /dev/sdb" make sure you create a bootable FAT
> > > > partition "/dev/sdb1"
> > > >
> > > > (2) create new fat filesystem on the USB stick by using
> > > > "mkfs.vfat /dev/sdb1"
> > > >
> > > > (3) setup the bootloader by executing "syslinux /dev/sdb1"
> > > >
> > > > (4) create your buildiso "cobbler buildiso --systems='host.domain.net'"
> > > >
> > > > (5) step 4 should have created beside the "generated.iso" file also a
> > > > "buildiso" directory; copy the created files from "buildiso/isolinux/*" to
> > > > "/dev/sdb1" (mount it)
> > > >
> > > > (6) rename the "isolinux.cfg" on "/dev/sdb1" to "syslinux.cfg"
> > > >
> > > > (7) umount "/dev/sdb1" and try to boot with the USB-stick, just don't
> > > > forget to disconnect it on time if you are using "clearpart" in your
> > > > kickstart file.
> > > > > If so, I could use it.
> > > >
> > > > Hope that helps,
> > > >
> > > > best regards,
> > > >
> > > > Alex

[Jörgen Maas]

On Wed, Nov 23, 2011 at 3:25 AM, Dan White  wrote:
> Good to see you on the list, Michael.  I thought you had moved on.
> So it looks like the current buildiso will not give me what I am asking for.
> Dang.
>
> I was hoping for a standalone loader that I could customize to the system level.
> This is because the DHCP in the environment I am in is run by the Microsoft Side of the House and I have not been able to get consistent behavior from the first part of the Cobbler net-boot process.
>
> Reference: https://fedorahosted.org/pipermail/cobbler/2011-November/006889.html
>
> Is buildiso.py self-contained ?  I would be willing to take a shot at getting it to do what I want.
> Seems like a good feature to contribute for me to the stew.

Can you please explain the exact use case please? What do you mean
with a standalone loader? With the standalone ISO you basically get
the installation media from your Linux distro with associated
profiles/systems and the isolinux menu so you can still use kickstarts
for handsoff installations.

If you are using standalone ISO installations (you'd do this because
netbooting isn't available), so what does DHCP have to do with it ?

Thanks.

[Dan White]

----- Jörgen Maas  wrote:
> On Wed, Nov 23, 2011 at 3:25 AM, Dan White  wrote:
> > Good to see you on the list, Michael.  I thought you had moved on.
> > So it looks like the current buildiso will not give me what I am asking for.
> > Dang.
> >
> > I was hoping for a standalone loader that I could customize to the system level.
> > This is because the DHCP in the environment I am in is run by the Microsoft Side of the House and I have not been able to get consistent behavior from the first part of the Cobbler net-boot process.
> >
> > Reference: https://fedorahosted.org/pipermail/cobbler/2011-November/006889.html
> >
> > Is buildiso.py self-contained ?  I would be willing to take a shot at getting it to do what I want.
> > Seems like a good feature to contribute for me to the stew.
>
> Can you please explain the exact use case please? What do you mean
> with a standalone loader? With the standalone ISO you basically get
> the installation media from your Linux distro with associated
> profiles/systems and the isolinux menu so you can still use kickstarts
> for handsoff installations.
>
> If you are using standalone ISO installations (you'd do this because
> netbooting isn't available), so what does DHCP have to do with it ?
>
> Thanks.

Sorry if I have confused.

I started out with a classic Cobbler Server, net/PXE-booting the clients to install.
However, the folks controlling DHCP are pro-Microsoft/anti-Linux and are uncooperative.
If I do my own DHCP, it will cause problems -- possibly technical problems, most definitely bureaucratic/security problems.
So my intent is to find an alternate workflow that could remove the DHCP-related obstacle.

Does that clarify ?

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

[Christian Horn]

On Wed, Nov 23, 2011 at 12:54:58PM +0000, Dan White wrote:
> I started out with a classic Cobbler Server, net/PXE-booting the clients to install.
> However, the folks controlling DHCP are pro-Microsoft/anti-Linux and are uncooperative.
> If I do my own DHCP, it will cause problems -- possibly technical problems, most definitely bureaucratic/security problems.
> So my intent is to find an alternate workflow that could remove the DHCP-related obstacle.

I am wondering if they could do just a static load of gpxe for you,
and that could always hint on i.e. fetching something via http then
from your cobbler box which you can control.
Maybe reading up on what gpxe can do helps giving ideas.

Christian

[Dan White]

---- Christian Horn  wrote:
> On Wed, Nov 23, 2011 at 12:54:58PM +0000, Dan White wrote:
> > I started out with a classic Cobbler Server, net/PXE-booting the clients to install.
> > However, the folks controlling DHCP are pro-Microsoft/anti-Linux and are uncooperative.
> > If I do my own DHCP, it will cause problems -- possibly technical problems, most definitely bureaucratic/security problems.
> > So my intent is to find an alternate workflow that could remove the DHCP-related obstacle.
>
> I am wondering if they could do just a static load of gpxe for you,
> and that could always hint on i.e. fetching something via http then
> from your cobbler box which you can control.
> Maybe reading up on what gpxe can do helps giving ideas.
>
> Christian

Which "they" are you referring to ?

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

[Christian Horn]

On Wed, Nov 23, 2011 at 07:21:37PM +0000, Dan White wrote:
> ---- Christian Horn  wrote:
> > On Wed, Nov 23, 2011 at 12:54:58PM +0000, Dan White wrote:
> > > I started out with a classic Cobbler Server, net/PXE-booting the clients to install.
> > > However, the folks controlling DHCP are pro-Microsoft/anti-Linux and are uncooperative.
> > > If I do my own DHCP, it will cause problems -- possibly technical problems, most definitely bureaucratic/security problems.
> > > So my intent is to find an alternate workflow that could remove the DHCP-related obstacle.
> >
> > I am wondering if they could do just a static load of gpxe for you,
> > and that could always hint on i.e. fetching something via http then
> > from your cobbler box which you can control.
> > Maybe reading up on what gpxe can do helps giving ideas.
>
> Which "they" are you referring to ?

The admins of the dhcp server.  They would for all the systems
they pxeboot for you use the same entry.  This could fetch things
via http from always the same place on your cobbler system, and
you would in that place provide the content for the exact system
you want to deploy.
Would be limited to just one system pxebooting at a time, the
cobblersystem would at the one place just always offer the things
for one system.

Also just a rough idea, could hang fast looking at details.

Christian

[Michael DeHaan]

On Tue, Nov 22, 2011 at 9:25 PM, Dan White  wrote:
> Good to see you on the list, Michael.  I thought you had moved on.
> So it looks like the current buildiso will not give me what I am asking for.
> Dang.

Yes, though I want to help out here some.
> I was hoping for a standalone loader that I could customize to the system level.
> This is because the DHCP in the environment I am in is run by the Microsoft Side of the House and I have not been able to get consistent behavior from the first part of the Cobbler net-boot process.
>
> Reference: https://fedorahosted.org/pipermail/cobbler/2011-November/006889.html
>
> Is buildiso.py self-contained ?  I would be willing to take a shot at getting it to do what I want.
> Seems like a good feature to contribute for me to the stew.

If you only have the captive DHCP scenario, you don't need the
standalone.   As Jörgen says below, the standalone mode is intended
for network-less environments.  Imagine you have two environments at
your work -- one is full on PXE, another is a heavily locked down lab
with no outside networking and can't see the cobbler server.   This
allows you to provision inside that second network (or on something
without a network at all).   It's still fully automatic, but it puts
the kickstart onto the ISO with the distribution tree.

If you only need to avoid DHCP, the default buildiso mode just puts
the menu on the CD, but the install trees and kickstarts are still
contained on your cobbler server.   This allows you to modify the
kickstarts without reburning the CD, but you would want to reburn the
CD to change kernel options or add distros/profiles.   However, if
you're lucky, you could also just get the Microsoft side of the house
to set the "next-server" parameter for your DHCP by MAC/subnet/etc to
point at the Cobbler server -- assuming they can do that.

[Dan White]

----- Michael DeHaan  wrote:
> On Tue, Nov 22, 2011 at 9:25 PM, Dan White  wrote:
> > Good to see you on the list, Michael.  I thought you had moved on.
> > So it looks like the current buildiso will not give me what I am asking for.
> > Dang.
>
> Yes, though I want to help out here some.
> > I was hoping for a standalone loader that I could customize to the system level.
> > This is because the DHCP in the environment I am in is run by the Microsoft Side of the House and I have not been able to get consistent behavior from the first part of the Cobbler net-boot process.
> >
> > Reference: https://fedorahosted.org/pipermail/cobbler/2011-November/006889.html
> >
> > Is buildiso.py self-contained ?  I would be willing to take a shot at getting it to do what I want.
> > Seems like a good feature to contribute for me to the stew.
>
> If you only have the captive DHCP scenario, you don't need the
> standalone.   As Jörgen says below, the standalone mode is intended
> for network-less environments.  Imagine you have two environments at
> your work -- one is full on PXE, another is a heavily locked down lab
> with no outside networking and can't see the cobbler server.   This
> allows you to provision inside that second network (or on something
> without a network at all).   It's still fully automatic, but it puts
> the kickstart onto the ISO with the distribution tree.
>
> If you only need to avoid DHCP, the default buildiso mode just puts
> the menu on the CD, but the install trees and kickstarts are still
> contained on your cobbler server.   This allows you to modify the
> kickstarts without reburning the CD, but you would want to reburn the
> CD to change kernel options or add distros/profiles.   However, if
> you're lucky, you could also just get the Microsoft side of the house
> to set the "next-server" parameter for your DHCP by MAC/subnet/etc to
> point at the Cobbler server -- assuming they can do that.

Sadly, it is uglier that that.
They will not configure the development lab sub-net to default PXE-boot from my server.
I have to use individual DHCP reservations.  And they cannot/will-not do them consistently/properly.
I have resorted to the ISO workflow to end a multi-day personal productivity blockage.

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

[Jörgen Maas]

On Wed, Nov 23, 2011 at 2:53 PM, Dan White  wrote:
> Sadly, it is uglier that that.
> They will not configure the development lab sub-net to default PXE-boot from my server.
> I have to use individual DHCP reservations.  And they cannot/will-not do them consistently/properly.
> I have resorted to the ISO workflow to end a multi-day personal productivity blockage.

I can relate :(.
Like Michael said, the netboot ISO is perfect for your scenario.

[Michael DeHaan]

Sounds like a problem that could be solved with a more complex networking setup.

However, I won't pretend I'm that person, I did develop my DHCP plugin
with DHCP listening on only one interface, with another pointed to the
outside world, using iptables for software routing.
That was a while ago.

System records are pretty useful enough for me to not want to do
without them though, since you can do things like:

cobbler system edit --netboot-enabled=1
and utilize the power management commands to do installs without
visiting the box (if so equipped)

On Wed, Nov 23, 2011 at 8:53 AM, Dan White  wrote:
> ----- Michael DeHaan  wrote:
> > On Tue, Nov 22, 2011 at 9:25 PM, Dan White  wrote:
> > > Good to see you on the list, Michael.  I thought you had moved on.
> > > So it looks like the current buildiso will not give me what I am asking for.
> > > Dang.
> >
> > Yes, though I want to help out here some.
> > > I was hoping for a standalone loader that I could customize to the system level.
> > > This is because the DHCP in the environment I am in is run by the Microsoft Side of the House and I have not been able to get consistent behavior from the first part of the Cobbler net-boot process.
> > >
> > > Reference: https://fedorahosted.org/pipermail/cobbler/2011-November/006889.html
> > >
> > > Is buildiso.py self-contained ?  I would be willing to take a shot at getting it to do what I want.
> > > Seems like a good feature to contribute for me to the stew.
> >
> > If you only have the captive DHCP scenario, you don't need the
> > standalone.   As Jörgen says below, the standalone mode is intended
> > for network-less environments.  Imagine you have two environments at
> > your work -- one is full on PXE, another is a heavily locked down lab
> > with no outside networking and can't see the cobbler server.   This
> > allows you to provision inside that second network (or on something
> > without a network at all).   It's still fully automatic, but it puts
> > the kickstart onto the ISO with the distribution tree.
> >
> > If you only need to avoid DHCP, the default buildiso mode just puts
> > the menu on the CD, but the install trees and kickstarts are still
> > contained on your cobbler server.   This allows you to modify the
> > kickstarts without reburning the CD, but you would want to reburn the
> > CD to change kernel options or add distros/profiles.   However, if
> > you're lucky, you could also just get the Microsoft side of the house
> > to set the "next-server" parameter for your DHCP by MAC/subnet/etc to
> > point at the Cobbler server -- assuming they can do that.
>
> Sadly, it is uglier that that.
> They will not configure the development lab sub-net to default PXE-boot from my server.
> I have to use individual DHCP reservations.  And they cannot/will-not do them consistently/properly.
> I have resorted to the ISO workflow to end a multi-day personal productivity blockage.
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
> _______________________________________________
> cobbler mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/cobbler

[Jörgen Maas]

On Wed, Nov 23, 2011 at 1:50 AM, Michael DeHaan
 wrote:
> Apologies on answering with code, but here's an interesting comment in
> the source (buildiso.py):
>
> def generate_standalone_iso(self,imagesdir,isolinuxdir,distname,filesource):
>        """
>        Create bootable CD image to be used for handsoff CD installations
>        """
>        # Get the distro object for the requested distro
>        # and then get all of its descendants (profiles/sub-profiles/systems)
>
> And elsewhere in the code:
>
> if standalone:
>            if profiles is not None or systems is not None:
>                utils.die(self.logger,"When building a standalone ISO,
> use --distro only instead of --profiles/--systems")
>            elif distro is None:
>                utils.die(self.logger,"When building a standalone ISO,
> you must specify a --distro")
>            if source != None and not os.path.exists(source):
>                utils.die(self.logger,"The source specified (%s) does
> not exist" % source)
>
> It looks like that will give you everything under the profiles/systems
> and does not actually filter them to specific profiles.
> And it should yell at you and tell you this when you try it :)
>
> Making it understand --profiles or --systems as a kind of blacklist
> seems like an easy patch.

Just for clarification.

When using the --standalone, you have to select *one* distro. Buildiso
then includes all profiles and systems associated with that distro and
includes them on the CD. This way you can do handsoff installations
from CD.

For the netboot ISO case the --profiles and --systems parameters are
whitelist options. Why should one want to change that behaviour to
blacklisting for the standalone ISO case?

Maybe i just don't understand ;)

[Dan White]

----- Jörgen Maas  wrote:
> On Wed, Nov 23, 2011 at 1:50 AM, Michael DeHaan
>  wrote:
> > Apologies on answering with code, but here's an interesting comment in
> > the source (buildiso.py):
> >
> > def generate_standalone_iso(self,imagesdir,isolinuxdir,distname,filesource):
> >        """
> >        Create bootable CD image to be used for handsoff CD installations
> >        """
> >        # Get the distro object for the requested distro
> >        # and then get all of its descendants (profiles/sub-profiles/systems)
> >
> > And elsewhere in the code:
> >
> > if standalone:
> >            if profiles is not None or systems is not None:
> >                utils.die(self.logger,"When building a standalone ISO,
> > use --distro only instead of --profiles/--systems")
> >            elif distro is None:
> >                utils.die(self.logger,"When building a standalone ISO,
> > you must specify a --distro")
> >            if source != None and not os.path.exists(source):
> >                utils.die(self.logger,"The source specified (%s) does
> > not exist" % source)
> >
> > It looks like that will give you everything under the profiles/systems
> > and does not actually filter them to specific profiles.
> > And it should yell at you and tell you this when you try it :)
> >
> > Making it understand --profiles or --systems as a kind of blacklist
> > seems like an easy patch.
>
> Just for clarification.
>
> When using the --standalone, you have to select *one* distro. Buildiso
> then includes all profiles and systems associated with that distro and
> includes them on the CD. This way you can do handsoff installations
> from CD.
>
> For the netboot ISO case the --profiles and --systems parameters are
> whitelist options. Why should one want to change that behaviour to
> blacklisting for the standalone ISO case?
>
> Maybe i just don't understand ;)

Thank you for the information, Jörgen.
I am willing to try generating a standalone ISO and see what it can/cannot do for me.

Again, I will share what I find with the list in the hope that the info will help someone else.

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

[Jörgen Maas]

On Wed, Nov 23, 2011 at 1:49 PM, Dan White  wrote:
> Thank you for the information, Jörgen.
> I am willing to try generating a standalone ISO and see what it can/cannot do for me.
>
> Again, I will share what I find with the list in the hope that the info will help someone else.

If you find any bugs in the buildiso stuff, please do let me know
(cc).. and i will (try to) fix them asap!