Posts made by cspence

Okay, I lied about waiting until Monday.

On the 1.2.0 boot image, my best guess is it doesn’t use udhcpc. The 1.2.0 image successfully uses eth1 on its own. So it looks like your initial theory is out.

But I found more: /etc/network/interfaces forces the use of [B]udhcpc -t 100 -T 20[/B] as an argument to [B]iface [COLOR=#ff0000]eth0[/COLOR] inet dhcp[/B] on the SVN versions. The 1.2.0 does not even have configurations for eth0 or eth1. At this time, I’m not sure what action gets an IP on the 1.2.0 image. But this should be helpful for anyone else to continue the search.

[quote=“Uncle Frank, post: 42916, member: 28116”]If I get thinks right here I’d say that this is simply a question of the order in which linux registers the network interfaces when FOG comes up on the client. Maybe I am wrong but I believe that FOG 1.2.0 did not magicaly “find the working interface”. It’s just that the older kernel registered the onboard NIC as eth0 I guess. Interesting post on this topic: [url]https://lists.debian.org/debian-user/2006/01/msg00075.html[/url]

Easy test would be to extract bzImage{,32} and init{,_32}.xz from fog_1.2.0.tar.gz and put those into ‘/var/www/fog/service/ipxe/’ where SVN 2948/3053 is running. Probably best to backup this whole directory first before overwriting those files.

Will be interesting to see if I am on the wrong track with this…[/quote]

It was worth a shot.

Results:
It appears that the 1.2.0 images use the on-board NIC without issue even when in use by SVN 2948/3053 (but that’s not surprising). It’s the end of the week so I’ll probably pick this up Monday.

Also, a tidbit of humor: If you run a debug task and you’re having network issues or you don’t have a network, even debug will get stuck looking for an IP from udhcpc. Very helpful.

I’m experiencing problems with some of the SVN revisions after 1.2.0 on machines with two NICs. I’m using the NIC that tends to register as eth1.

Here’s some base information:

FOG Versions Tested: 1.2.0, SVN 2948, and SVN 3053
On-Board NIC: Intel 82579LM Gigabit (Registers as eth1 with Linux)
PCI-Express NIC: Broadcom NetXtreme BCM5722 Gigabit (Registers as eth0 with Linux)

First of all, version 1.2.0 works fine. [B]This bug is experienced in SVN 2948 and 3053.[/B]

When I try to register a host or capture an image from a host, SVN 2948 and 3053 do not power on the On-Board NIC (eth1) while attempting to get a DHCP lease. Switching the cable to the PCI-E NIC immediately leases an IP. Removing the PCI-E NIC allows registration and imaging to work on the On-Board NIC.

It appears that some point between 1.2.0 and SVN 2948, the behavior was changed to only use eth0 rather than find the working interface.

[quote=“Junkhacker, post: 42892, member: 21583”]i think i remember something about muti-partition multicast imaging having an issue and being fixed in svn. i recommend upgrading to svn revision 2948, but have a backup you can revert to in case you have problems.
also, regarding this:

fog uses partclone, not partimage, for any version newer then 1.0.0[/quote]

Good things to know. I’ll look into that revision and get you some feedback.

I should have confirmed what imaging system it was using now. That would explain why ext4 had no issue.

Sounds good. If you need anything from my end, just get back to me. I’ll be glad to help (I have a couple of routes, several subnets, and several VLANs to use for thorough testing).

[quote=“Uncle Frank, post: 42863, member: 28116”]Could something be wrong with that particular swap partition?? Maybe try recreate swap on the client before uploading an image?! Just a wild guess. Will think about the issue a little more…[/quote]

I also noticed that partimage does not officially support ext4. When conducting these tests initially, I used an ext4 partition for the root partition. I thought it would be best to ensure that it wasn’t a complication from using ext4 (a long shot) so I installed Debian 7 from scratch again but with an ext3 partition. I ran the same tests again and got the same results.

It’s just strange to me that unicast jobs work fine, but multicast jobs can’t handle swap partitions in multi-partition mode.

[quote=“Wayne Workman, post: 42849, member: 28155”]I can’t lie, when I looked through that incredibly detailed post, trying to find the FOG version and realizing it wasn’t there, I smiled. :)[/quote]

I rolled my eyes when I saw your reply. I edited it into the original post and gave you credit.

I forget that not everyone runs the latest version.

I’ve been having trouble with multicasting with a Multiple Partition - Single Disk image with a swap partition. So here are some specifications I have before getting into this.

[B][U]Specifications[/U][/B]
[U]FOG Server[/U]
OS: Debian 7
IP: 10.2.0.50/24
[COLOR=#ff0000]FOG Version: 1.2.0 (Edit: Thanks for pointing out I left it off, Wayne Workman.)[/COLOR]
Locally Hosted Services: TFTP, NFS
Firewall: Disabled (not in production)

[U]DHCP Server[/U]
OS: Windows Server 2008 R2
DHCP Options configured to use 10.2.0.50 as the TFTP server as directed

[U]Example Targets[/U]
IPs: 10.1.5.1/24, 10.1.5.1/24
Hard Drive Space: 250GB

[U]Test Image[/U]
OS: Debian 7
Size: 1.2GB
Partitioning Method: MBR
Partition 1: Primary, Bootable, /
Partition 2: Primary, Swap, swapon
Bootloader: GRUB

[B][U]Test Scenario 1[/U][/B]
Description: Multicasting Multiple Partition - Single Disk Image (fstab Config 1)
Special note: The fstab used UUIDs to identify all partitions.

[U]Issues[/U]
Deployment would successfully send the root partition and freeze on the swap partition. To get around it, I would have to stop the tasks and hard reboot the machines. The images were bootable.

Inspecting the machine showed that the swap partition was created, but that they had not been activated (UUID mismatch issue - Example thread: [url]http://fogproject.org/forum/threads/imaging-linux-systems-uuid-for-swap-not-matching-on-deployed-systems-eh.10901/[/url]).

[B][U]Test Scenario 2[/U][/B]
Description: Multicasting Single Disk Image
Special note: The fstab used UUIDs to identify all partitions.

[U]Issues[/U]
Imaging successful. No hangs during imaging.

[B][U]Test Scenario 3[/U][/B]
Description: Multicasting Multiple Partition - Single Disk Image (fstab Config 2)
Special note: The fstab used /dev/sda* format to identify all partitions.

[U]Issues[/U]
Again, deployment would successfully send the root partition and freeze on the swap partition. To get around it, I would have to stop the tasks and hard reboot the machines. The images were bootable.

The swap partition was created, formatted properly, and was active.

[B][U]Concluding Comments & Questions[/U][/B]
For the record, I had the same thing happen when I had my root partition as a primary and the swap as a logical partition.

The swap deployment hang issues only occur when using Multicast jobs. Unicast deployment does not hang and the job completes without intervening by powering off the machines and cancelling the tasks.

Is this a known issue or is this just something I’m doing?

If I remember correctly, Ubuntu by default will provided colorized output. If installfog.sh was executable, it would be highlighted a different color. Run:

[B]ls -l[/B]

This will show the permissions on the file. You should see [B]-rwxr-xr-x[/B] for permissions. If you don’t have any executable bits, you’ll get the response you got. How do you fix it? For a start, you could run:

[B]sudo chmod 755 installfog.sh[/B]

This will only make that first script executable. In the same directory, there’s a .install.sh file that probably won’t have executable rights either.

[B][U]If you really want to make sure it works[/U][/B]
It seems you must have extracted the files in a strange way because you should already have the correct permissions. When you get the tar.gz from the website, run tar to extract the files to preserve permissions:

[B]tar zxvf fog_1.2.0.tar.gz[/B]

This will extract everything out into your current directory. Then all the permissions should be correct.