the / marks are slashes. Many times, I’ve seen the pxe default file looking for web:
<IPADDRESS>/fog rather than <IPADDRESS>/fog/ <- (This is the trailing slash as it trails at the end.)
The default file is generally located in:
/tftpboot/pxelinux.cfg/
the file is just called default.
You can edit it however you want, but just make sure the slash is in the file and in the fog settings.
[quote=“Tom Elliott, post: 14178, member: 7271”]darkapec,
What type of pxe setup are you using? gpxelinux or pxelinux. In either case, your file should not be setup, as far as I can tell, with a prefix of: tftp:/ . Even if this is an okay header portion, try tftp://. If that isn’t working, and you’re using gpxelinux, make sure your file is accessible via a webserver. Then change the tftp:/ parts to http://
One other think that’s standing out, is the kernel line.
[FONT=Consolas]KERNEL linux.c32[/FONT]
[FONT=Consolas]Is this actually your kernel? It doesn’t look like it to me. Usually the kernel is vmlinuz or bzImage[/FONT]
Try using:
[FONT=Consolas]LABEL Ubuntu LTSP 12.04[/FONT]
[FONT=Consolas] MENU LABEL LTSP - Ubuntu Desktop[/FONT]
[FONT=Consolas] KERNEL tftp:/192.168.1.145/opt/ltsp/i386/boot/vmlinuz[/FONT]
[FONT=Consolas] append initrd=tftp:/192.168.1.145/opt/ltsp/images/i386.img ro quiet splash[/FONT]
If this doesn’t work try:
[FONT=Consolas]LABEL Ubuntu LTSP 12.04[/FONT]
[FONT=Consolas] MENU LABEL LTSP - Ubuntu Desktop[/FONT]
[FONT=Consolas] KERNEL [url]http://192.168.1.145/opt/ltsp/i386/boot/vmlinuz[/url][/FONT]
[FONT=Consolas] append initrd=[url]http://192.168.1.145/opt/ltsp/images/i386.img[/url] ro quiet splash[/FONT][/quote]
Also, just as I’m reading a little bit more, if this chainload is supposed to be happening as such maybe the lines should read:
[FONT=Consolas]LABEL Ubuntu LTSP 12.04[/FONT]
[FONT=Consolas]MENU LABEL LTSP - Ubuntu Desktop[/FONT]
[FONT=Consolas]KERNEL linux.c32[/FONT]
[FONT=Consolas]append initrd=tftp:/192.168.1.145/opt/ltsp/images/i386.img ro quiet splash[/FONT]
[FONT=Consolas]Remember, that you’ve already loaded a kernel, so loading vmlinuz shouldn’t work to my knowledge[/FONT]
One of the things I’ve learned with building a custom kernel is to Read the friendly Wiki page or (RTFW) as other so like to display.
If you’re building the kernel on a 64 bit system, make sure your make commands are:
make ARCH=i386 <command>
So when you’re doing the menuconfig do:
make ARCH=i386 menuconfig
Then make your changes and save the new config.
Then when you create the bzImage file do:
make ARCH=i386 bzImage.
I would almost recommend making this an actual part of the WIKI rather than just a note, as it wouldn’t hurt anything to do this from any platform whether i386 or 64 bit.
Thank you,
On the localboot line try:
localboot 0x80
Usually it is set to:
localboot 0 which doesn’t seem to work with ahci and gpxelinux.
darkapec,
What type of pxe setup are you using? gpxelinux or pxelinux. In either case, your file should not be setup, as far as I can tell, with a prefix of: tftp:/ . Even if this is an okay header portion, try tftp://. If that isn’t working, and you’re using gpxelinux, make sure your file is accessible via a webserver. Then change the tftp:/ parts to http://
One other think that’s standing out, is the kernel line.
[FONT=Consolas]KERNEL linux.c32[/FONT]
[FONT=Consolas] [/FONT]
[FONT=Consolas]Is this actually your kernel? It doesn’t look like it to me. Usually the kernel is vmlinuz or bzImage[/FONT]
Try using:
[FONT=Consolas]LABEL Ubuntu LTSP 12.04[/FONT]
[FONT=Consolas] MENU LABEL LTSP - Ubuntu Desktop[/FONT]
[FONT=Consolas] KERNEL tftp:/192.168.1.145/opt/ltsp/i386/boot/vmlinuz[/FONT]
[FONT=Consolas] append initrd=tftp:/192.168.1.145/opt/ltsp/images/i386.img ro quiet splash[/FONT]
If this doesn’t work try:
[FONT=Consolas]LABEL Ubuntu LTSP 12.04[/FONT]
[FONT=Consolas] MENU LABEL LTSP - Ubuntu Desktop[/FONT]
[FONT=Consolas] KERNEL [url]http://192.168.1.145/opt/ltsp/i386/boot/vmlinuz[/url][/FONT]
[FONT=Consolas] append initrd=[url]http://192.168.1.145/opt/ltsp/images/i386.img[/url] ro quiet splash[/FONT]
For the hdparm issue, check your FOG Configuration->FOG Settings->Web Server and make sure the web root has the trailing slash. Also check that this information is corresponding to the PXE Default file web={IP}/fog/ portion. If it doesn’t have the trailing slash, it can cause this issue, as the FOG scripts actually run the system as:
${web}service/<file>
Without the trailing slash, it will search for something like:
192.168.1.1/fogservice/<file>.php which obviously wouldn’t exist. Some systems seem to not care and add the trailing slash, but a majority of them do this is in this fashion from what I’ve seen.
Maybe I’m wrong, but it couldn’t hurt to check.
Also, if it keeps being deployed, check your /tftpboot/pxelinux.cfg folder. If there are no tasks, you should only have the default file. Chances are, and I’m only guessing, you’ve got a file that is representing that system’s mac address in the format of 01-XX-XX-XX-XX-XX-XX where the X’s correspond with your systems mac address. Delete this file and you should no longer have this issue.
Thank you,
I’ve found that any time I’ve had the hdparm: ioctl 0x304 failed: Inappropriate ioctl for device issue, it’s not necessarily a driver issue, though it could very well be one. However, check your PXE file.
Make sure that the web part of the pxe server: does not look like this:
10.0.7.1/fog
Make sure you add the trailing slash otherwise you’ll see this issue.
On the same note, make sure your FOG Settings Page :
FOG Configuration (? Circle Icon) -> FOG Settings -> Web Server section -> Web Root also has the trailing slash as this is used to create the boot file for the hosts when tasks are setup.
Hopefully this helps.
[COLOR=#000000]10.0.7.1/fog/[/COLOR]
so no luck so far with Single Disk, Resizeable. It feels like it’s not making/rewriting after upload a copy of the mbr. For UEFI this shouldn’t be required, but that’s a different story. 105906 is the right start point for part 2. Remember I’m nobody so I was just testing different things. Maybe force the file to copy the mbr before resize, then resize image/upload, then resize back and write mbr back?
I know that’s a lot, but the script could do it all. I just don’t know where to begin.
Thanks,
I think I’ve found out the issue to the single disk, resizable not operating. I believe it’s due to the start of the 2nd partition being input improperly. It is set in the init.gz /bin/fog file as part2start=105906 but in actuality, the part2start could be found by the fdisk command, hence making it operable for, basically, an windows ntfs system. fdisk -lu will output the partitions in their sector start/end positions. This might help us out a little, maybe. I’ll do some more testing before posting results.
AHCI Drivers wouldn’t create the problem necessarily, though many people opt to keep the BIOS setup as IDE. I haven’t seen any issues with either.
I have played with FOG and Sysprep, and I found that you can only do sysprep the first time on windows 7 for the Single Disk, Resizeable option to work with 0.32 and your system. The caveat to this is that it will not work after you’ve activated and licensed windows for the first time. Windows will let you sysprep whenever you want, but FOG does not enjoy this.
The way I got around this is by doing the base install. Once it’s at the screen asking you for username and machine name, I do a CTRL+ALT+SHIFT+F3 (just to be safe, I never remember which is the actual combination so I do them all) to drop down into Audit mode. Then I can install all the software I need, updates, drivers etc… Then I sysprep and reboot, right after setting the machine to create upload task. I’ve not had any issues with this method.
[quote=“Greg Martin, post: 14169, member: 10982”]When I try connecting to fog using the web interface, I get the the following error.
Unable to connect to database.
I checked the connection and was able to connect by entering the root password. I’m not sure if I’m missing something, but could someone help me troubleshoot this issue?
Thanks,
Greg[/quote]
Greg,
Check your config.inc.php file. It is located typically in:
/var/www/html/fog/commons (redhat base) or
/var/www/fog/commons (debian/ubuntu)
It sounds like the information you need is not in this file.
Also, if you’re trying to access a separate mysql server you need to ensure your host can actually log in.
So to test that, you would do:
mysql -u root -p -h <hostname/IP>
If you can connect this way, you know all is good.
[quote=“Tom Elliott, post: 14166, member: 7271”]Under the Fog Configuration page (the ? circle icon) the Mac-List page did not operate. Even with adjusting the $FOGCore values to $this->FOGCore as needed, the page displayed, but the Delete and Update did not work. I corrected this and will attach the files.
With this, though it’s not pretty, under the Host page, I’ve added the ability to add additional macs and, with the database loaded with the mac address vendor’s, it now displays the vendor for the macs. If it can’t find the mac listed, it will give the link for the lookup vendor, though I haven’t seen how to get this working … yet.
Inventory of the files are:
{fogwebdir}/lib/pages/FOGConfigurationPage.class.php
{fogwebdir}/lib/pages/HostManagementPage.class.php[/quote]
I forgot to mention, there were quite a few files that are referenced for the mac-list information. The original link lists it as mac-list, but all other needed files (the js, the ajax file, etc… reference the sub class as maclist) so Loading Vendors was giving issue as maclist didn’t exist and the delete/update buttons on the fog configuration page didn’t work because of the same reason. I’ll past the files that I changed to make it follow mac-list.
Inventory of the files are:
{fogwebdir}/management/js/fog.about.mac-list.js (Uploaded as txt file as js not allowed. Also, had to rename this file originally as the sub is mac-list, and this was called fog.about.maclist.js)
{fogwebdir}/management/ajax/mac-getman.php (Updated the sub reference)
{fogwebdir}/management/includes/submenu.include.php (The sub was here already, but just in case)
{fogwebdir}/management/includes/about.include.php (changed filename reference of maclist to mac-list)
{fogwebdir}/management/includes/about.mac-list.include.php (changed name of file and href information)
{fogwebdir}/management/indexold.php (Fixed this file so it actually logs you in now as well. Fixed the reference to sub)
[url=“/_imported_xf_attachments/0/369_fog.about.mac-list.txt?:”]fog.about.mac-list.txt[/url][url=“/_imported_xf_attachments/0/370_mac-getman.php?:”]mac-getman.php[/url][url=“/_imported_xf_attachments/0/371_submenu.include.php?:”]submenu.include.php[/url][url=“/_imported_xf_attachments/0/372_indexold.php?:”]indexold.php[/url][url=“/_imported_xf_attachments/0/373_about.include.php?:”]about.include.php[/url][url=“/_imported_xf_attachments/0/374_about.mac-list.include.php?:”]about.mac-list.include.php[/url]
Under the Fog Configuration page (the ? circle icon) the Mac-List page did not operate. Even with adjusting the $FOGCore values to $this->FOGCore as needed, the page displayed, but the Delete and Update did not work. I corrected this and will attach the files.
With this, though it’s not pretty, under the Host page, I’ve added the ability to add additional macs and, with the database loaded with the mac address vendor’s, it now displays the vendor for the macs. If it can’t find the mac listed, it will give the link for the lookup vendor, though I haven’t seen how to get this working … yet.
Inventory of the files are:
{fogwebdir}/lib/pages/FOGConfigurationPage.class.php
{fogwebdir}/lib/pages/HostManagementPage.class.php
[url=“/_imported_xf_attachments/0/367_FOGConfigurationPage.class.php?:”]FOGConfigurationPage.class.php[/url][url=“/_imported_xf_attachments/0/368_HostManagementPage.class.php?:”]HostManagementPage.class.php[/url]
Alright,
Update to my last post.
I created a Windows 7 VM and just installed the base. I haven’t activated or anything else, just installed and uploaded image.
The issue from above seems to be fine, except I keep getting hangs off and on. That could be a problem with my network as I have many different IP’s. I live on a 10/8 rather than a XXX/24 subnet. That aside, I was able to fully upload the image file.
The problem I came across, though, is that Single Disk, Resizeable seems broken to me. It uploaded the image, but only the mbr part of the image and broke the Windows 7 system where it needs to run a chkdsk. That aside it didn’t hurt the system, just a nuisance. In either case, it didn’t download any of the other partition(s) which seems to me it should and has in the past. I’m going to compare the init.gz fog script to the one from 0.32 as that one seemed to work flawlessly. I also wan’t to fix the size information when uploading as it’s displaying 1.47 GiB available space when the image size is 7.4 GiB. It doesn’t hurt my system any as I have 4 terabytes, but could pose an issue if someone doesn’t know and pulls the plug on an image they were overwriting.
I put the image in Multiple Partition Single Disk not resizable and it seems to have uploaded just fine. Maybe I can get some help on where to look for these issues?
Thank you,
This is a bug that I can’t give any fix for. I think it’s something all systems would have an issue with.
I have a windows system with a Hybrid SSD Drive. It will attempt to upload the image, but it keeps on hanging and eventually says something to the effect of pigz not responding last 120 seconds. The system that actually holds the images dies due to a kernel panic. I think this is specific to the Hybrid Drive, but I don’t have an alternate HDD to test with, unless I build a VM, which I will do eventually. Maybe this can be a warning rather than a bug, but I don’t know where else to place this.
The reason I believe it’s due to the HDD and not an issue with the actual imaging system is because looking up similar issues for this somebody recommended doing a chkdsk on the system. I just did the 3 phase chkdsk and it would hang throughout that as well. From my experience, usually 3 phase chkdsk is generally quite fast. It appeared that the Hybrid part (the ssd if you will) makes for a relatively large buffer, but the buffer can only hold so much data on the read state. Then it pauses, pushes the data where it needs to, then starts the cycle over again. Hence the pausing. I don’t know what this would look like on the write state as I haven’t been able to create an image for my Windows system.
From the dashboard, when you click on the Disk Usage Graph, it used to give you hardware information and gives a debug message saying to use the old include style information. When you click on the old include style it requests that you login. You type your information and it just requests you to login again. However, I’ve fixed the link to actually give us a class that would be referenced.
I made adjustments (again just for the pretty factor of calculation of disk space) and created a new file.
Inventory of files changed/added are:
{fogwebdir}/lib/pages/hwinfo.class.php (created the class file)
{fogwebdir}/status/hw.php (adjusted to obtain information and calculate sizes more human readable.)
[url=“/_imported_xf_attachments/0/365_hwinfo.class.php?:”]hwinfo.class.php[/url][url=“/_imported_xf_attachments/0/366_hw.php?:”]hw.php[/url]
Found an issue with the Disk Usage Graph on the main page of the web interface. What happens is when the used space is equal to the total available space, the graph only show’s 50% usage.
This is due to the way, that I can tell, the jquery.flot.pie.js script interprets the information in the calcTotal and combined functions.
Attached is the modified file that seems to work appropriately. This file goes in {fogwebdir}/managment/js/
I’ve also made a few changes to {fogwebdir}/management/js/fog.dashboard.js and {fogwebdir}/status/freespace.php so that it interprets the information accurately from Available and Used space and displays in EiB thru KiB. The method it uses currently obtains the appropriate Available space, but misinterprets the Used spaced. What I mean by this is when a file system is created there is always a portion that is unavailable space. The math takes the total size of the drive and subtracts the actual free space which is not necessarily an accurate representation of what the file system actually has.
So for inventory the files I’ve changed/added for the Dashboard area are:
{fogwebdir}/management/js/fog.dashboard.js (named as fog.dashboard.txt for upload)
{fogwebdir}/management/js/jquery.flot.pie.js (named as jquery.flot.pie.txt for upload)
{fogwebdir}/status/freespace.php
[url=“/_imported_xf_attachments/0/362_fog.dashboard.txt?:”]fog.dashboard.txt[/url][url=“/_imported_xf_attachments/0/363_jquery.flot.pie.txt?:”]jquery.flot.pie.txt[/url][url=“/_imported_xf_attachments/0/364_freespace.php?:”]freespace.php[/url]
[quote=“Tom Elliott, post: 14110, member: 7271”]Another minor issue that I’ve so far noticed is:
Reports, all of the pages will not work and it appears it’s because it has to communicate with the database. This communication is lost because the mysql_query statements within this pages look to be sending to a variable $conn that doesn’t exist for those pages. Also, as it needs to communicate with the database, the base configuration files are not existing either. My best suggestion would be to make a configuration file that stores the references needed within a file called something like base.inc.php that includes the base required files of commons/init.php commons/init.database.php. For the $conn variable, suggest an include statement of the base.inc.php so that the $conn system can be accessed even though it’s not directly defined in the file. So, basically, all main files should have an include BASEPATH . ‘commons/base.inc.php’; statement in them. This would also work for all other file that request this same information.
Found out that Pending MACs.php file the reference to class HostManager works if called like this:
$hostMan = new HostManager(); Rather than
$hostMan = $FOGCore->getClass(‘HostManager’);
Fixed and working on my side.
My base.inc.php file is:
<?php
/* This file just stores the heading information for including *
and is located in commons.
Then added the line to the files needed. Though I guess in the management/index.php all you should need is the reference :
In the reports *.php files.
include BASEPATH . ‘/commons/base.inc.php’;[/quote]
I was/am able to remove the need of the $conn variable declaration in base.inc.php and reference the global variable for database connections within the reports directory as:
$this->conn
So a simple sed script is really useful to fix this. Also with this, the $hostMan function in Pending MACS.php can now be referenced as: $this->FOGCore->getClass(‘HostManager’);
In the {fogwebdir}/management/*.php files, place near the top:
include ‘…/commons/base.inc.php’;
In the {fogwebdir}/commons/base.inc.php file just have:
base.inc.php
<?php
/* This file just stores the heading information for including *
*/
if (!defined(‘BASEBATH’))
require_once(‘system.php’);
require_once(BASEPATH . ‘/commons/config.php’);
require_once(BASEPATH . ‘/commons/init.php’);
require_once(BASEPATH . ‘/commons/init.database.php’);
?>
Hopefully somebody see’s this all.
Thanks,
Fixed / found issue on management/reports/Pending MACS.php. The reference of
$hostMan = $FOGCore->getClass(‘HostManager’);
Doesn’t do anything as the class in reference is technically non existent. To fix this and get report is to change that line to:
$hostMan = new HostManager();
This seems to allow it to work Properly.
EDIT:
now we can go, more or less, back to the reference sample originally intended with a minor change.
Change the line:
$hostMan = $FOGCore->getClass(‘HostManager’);
To:
$hostMan = $this->FOGCore->getClass(‘HostManager’);