FOG Quick/Full inventory attempt on a Dell XPS 8700 locks/fails.
-
Go to the directory:
/tftpboot/fog/kernelCopy the original kernel as backup;
mv bzImage bzImage_origWget the new kernel in the directory:
wget --no-check-certificate [url]http://mastacontrola.com/fogboot/kernel/bzImage[/url]You should be set.
-
Tom,
Sounds good, and I am trying it now. Thus far, it’s a little more “strange” than the original kernel, but it does seem to get past getting hung up on whatever piece of hardware the original bzImage was. However, when it tries to run the kernel on the client, I get a odd pause for 45 seconds to a minute. However, after that so far it seems to behave normally.
I do like how it “appears” to ignore uploading the free space, and only uploads actual data, that’s a nice welcome change. I’m uploading a host now, and attempting to deploy it to another system of the same type. So far so good, but it’s not complete yet, I’ll let you know!
Also, you were probably right about it being a hardware issue… most likely because the video card is a newer ATI Radeon model. Now that it skips over that, things are actually proceeding.
-
The 45 seconds you’re seeing in delay is due to the kernel having drivers setup for scsi systems as well and it’s actually checking for alternate ATA device connections. This is normal and expected behavior.
-
Tom,
At first it seemed to be able to image the XPS 8700 host correctly but there were a few possible issues…
-
I’m not certain if it’s relevant, but the disk on the host I wanted to image FOG seemed to think it was sdb when on the host itself it’s sda, but not certain if that makes a difference.
-
The host I was trying to take the image off of has 5 partitions, one of which is an extended, and another within the extended, the other 3 are primary. They are all ext4 partitions, and there is nothing with LVM going on. When FOG tried to image them, it seemed to image the first 3 very very quickly, almost as it if skipped them, and the 3rd (the swap partition) it seemed to skip altogether. The final partition with most of the data in it it seemed to image 69 GB of the 1 TB, and it went fairly quickly. Most of that 1 TB was emtpy space,and it seemed like the kernel skipped it for that reason.
However, when I tried to deploy the image to another machine of exactly the same configuration, it failed to deploy the image properly, and I am certain that was due to it’s having issue imaging the original host.
I’m not certain exactly what happened, the only thing I can think of is fdisk -l on the original host per partition shows something akin to:
partition x does not start on physical sector boundary. It says that for all 5 partitions, and I’m not sure if that is giving FOG any problems. I could reinstall CentOS 6.4 on the host if need be to fix it.
Let me know what you think. If necessary I could provide screenshots, but it’s quite a strange issue.
-
-
Not to stray to far from topic, what is the option your are using to select the partition type? I normally use Multi Partition - All Disks.
See if uploading the image this way has any affect on the outcome.
-
The kernel creates a small partion at point /dev/sda, I haven’t been able to figure that out yet. But it does have support for ext4. So it’s not abnormal for your disk to found on /dev/sdb
if it was actually creating the image, to my knowledge, partimage only pulls the used data off of the partitions and leaves free space alone. I just finished building a kernel off of core, so maybe this will correct the /dev/sd{a,b} problem, but the kernel size is now at 11MB, I haven’t had much time to test it if it’s using the video information, but hopefully it will operate properly as I found, today, it doesn’t recognize the drive from an HP 6475b system. So let me upload this file and give it a shot, I’ll call it bzImageCORE. Just rename it to plain bzImage for your fog host.
[url]https://mastacontrola.com/fogboot/kernel/bzImageCORE[/url]
-
Tom,
Ok, I will try that if need be, but for image type I’m using the: Multiple Partition Image - Single Disk (Not Resizeable) as the selection in image management. Do you think that might be giving it a problem? I think I might try: Raw Image (Sector By Sector, DD, Slow) instead. Who cares if it’s slow at least if I only have to do that for uploading and not for deploying it out.
If that doesn’t work, then I will try the kernel you posted above, and see what happens, I think I will do that anyways simply to test it for you on hardware that is relatively new.
I’ll let you know either way.
-
Jaymes, and Tom,
Jaymes, from now on I will try that option and see if it recognizes the partitioning scheme any better in the future.
Tom, well the sector by sector copy I did with the dd option worked on the host upload, but when I went to deploy it to the client, it just skipped it as if it didn’t exist and went right to being “done”. There didn’t seem to be any error message either that I could see, but it scrolled by incredibly fast all times I tried to see it.
So I think I’ll try your 11 MB image you linked in the post above and see what happens when I try to upload/deploy with that. Here’s hoping!
-
I hope it helps as well. Are you using a custom init.gz as well? I’ve seen the skipping and even partial copies with my custom one. Though it’s still a work in progress. Uploads seem to work fine, but deploy’s don’t for some reason. That’s an area I’ll worry about later on though.
-
Tom,
I don’t believe I am using a custom init.gz, but I am getting the issues you describe including the skipping and partial copies. It does however actually get to that point where the original bzImage would fail/lock at that point. If using a custom init.gz would help, it would be interesting to know how to do that. I’m going to try with your 11 MB image today and see what happens, didn’t get a chance yesterday.
-
I’d like to say I was also getting a blank screen after the bzimage and init.gz deployed.
This is on HP EliteDesk 800 G1
<snip>
uvesafb: failed to execute /sbin/v86d
uvesafb: make sure that v86d helper is installed and executable
uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
uvesafb: vbe_init() failed with -22
this is where the screen goes black and nothing happens.
I am using FOG 0.32, kernel 3.6.9 (I cannot get 3.8.8 to function, PXE boots ok but when selecting any options nothing happens)
when I used the bzImage Tom provided earlier this worked and the image deployed although the display was low resolution (this does not matter when deploying to be honest…)
So, thanks Tom, good solution
Cheers
Pete
