r1025 released. Should address the iceweasel browser hover issue on deploy as noted by VincentJ. Also, parted uses 99% for layout rather than 100% or the actual available disksize. This seems unusual, but Not all disks like 100% use and not all like the diskSize for the value. I figure lose 1% of the drive and you can recoup later on as needed.
Posts made by Tom Elliott
-
RE: Latest FOG 0.33b
-
RE: Latest FOG 0.33b
This may sound weird. I’m testing with, rather than size or 100% on the parted side of the house, just setting 99%. It means, theoretically, that you’re not getting 100% of the drive. However, it should work across all hard-drives. If there’s a major reason we shouldn’t be using 99% of the drives, please let me know and I’ll try to figure out another solution.
-
RE: Latest FOG 0.33b
VincentJ,
Thank you very much for the suggestions/bugs.
I’ll try explaining/showing my assistance where I can.
First Question: What revision of FOG 0.33b are you using? I ask is it is pertinent to your 2nd tip/find there.
In response to 1:
I will try to take a look at this as I’ve never done a manual add, then an inventory. Maybe the MAC entered is trying to impede on a database entry it thinks doesn’t exists, but at the end it finds it? I don’t know, I’ll test and see if I can replicate the results.In response to 2:
If you’re on the latest version of FOG, and this issue is still happening, I don’t know where else to go. Basically, I’ve rewritten the fog script to take into count different size Hard Drives. Parted doesn’t like the use of kB mB, etc… for disk size. Nor do all drives like to use 100% for the layout. This doesn’t seem right to me, but it’s up to the creator of parted how they want to do things. I’m looking to test with -1s for the end to use the full size of drive in place, but don’t know what repercussions they may pose. With that said, what size is the Hard Drive you’re using? 50Gb, 80Gb, etc…In response to 3:
This is expected behavior. I think the “DEBUG” is only enabled as this is a beta release. If you disable debug on the OS, Image, and Host pages, this clear’s itself right up. That said, I believe the latest version (r1024) has this, issue, taken care of, though I could very well be wrong.In response to 4:
I don’t see any change on my side. Can you try being more specific? Meaning, are you using a different language?In response to 5:
I’m assuming you mean, basically, doing quick host registration after full inventory of the host?In response to 6:
I don’t have FOGImageReplicator on my end, so I may need to setup a storage node and test out some more. Sorry about that.In response to 7:
This sounds like my response to number 2. I’m guessing parted is actually errorring out and not creating the partition as required.In response to 8:
That’s actually a piece of partclone. It’s nothing I can change directly. I suppose I could look at their source, but I’d probably cause more problems. My guess for this is partclone is only copying the data, not the free space, so blocks not being at the same pace as the rest of the drive actually makes sense. For example, Let’s just say we have a 10GB hard drive, with only 2GB of data. The blocks progress, should be less than the main progress. It’s only copying used blocks of data, not free. So when it encounters the free blocks, it can zoom right past. Just my theory.In response to 9:
Compression is enabled by default. It’s pigz compression, so it uses the systems total number of cores to speed up progress. With that, it’s a part of the FOG scripts built into the init.gz. If you don’t need/want compression, you’ll have to decompress the init.gz, mount the init file, and edit the bin/fog script. The compression ratio, I’ve set, is -9. If you don’t want any compression, I’d think putting it as -0 would work.In response to the suggestions.
I don’t know what you mean about the hardware inventory showing what’s happening with the system. Maybe there’s something beyond what I’m aware of. I’ll take a look to try to see what you mean. Adding the image and progress bar, I don’t know exactly what I’m doing in that respect. I’m trying to compare the progress indicator from 0.32 to what we’ve got in 0.33 so I could, potentially, get something like that going, but it’s not a guarantee.
Compression settings could be added to the GUI, now that I understand, better, what’s actually happening. It would require a minor rewrite in how the system picks up and builds the PXE file for the tasks. It would also require adding another field to the FOG Settings table on the database. Probably called Compression Ratio.
Bandwidth graph, I’ve noticed, does have a few bugs, but I don’t know where they lie yet. I’ve been looking at it for quite some time.
Partclone, unfortunately, is it’s own thing. I’ll try seeing of there’s command line arguments that can provide that for us.
What do you mean about logs being sent to the server? You mean essentially creating a log on the FOG Server, for all tasks? I don’t think this is impossible, but imagine it causing issues in filtering and reporting. -
RE: Latest FOG 0.33b
My only guess, as to the issue, is that primary partitions are labeled, generally, as : /dev/sda1, /dev/sda2 etc…
I’m guessing, if you were to perform fdisk -l on a working system at that point, you’d see partitions labeled as:
/dev/sda1
/dev/sda2
/dev/sda2p1
/dev/sda2p2Or very similar.
FOG doesn’t search for partitions within partitions, it only searches, to my understanding, for primary partitions.
I don’t know how I can try to make logical partitioning work. My question, though, is why couldn’t you make /home a primary partition on the device. Swap as well?
I only ask this because I’ve tested ext4 imaging on my systems at home, with a similar setup:
/dev/sda1 = / partition
/dev/sda2 = swap partition
/dev/sda3 = /home
/dev/sda4 = /tmp -
RE: Default file...
I’m happy that you’ve found 0.33b as I need as many people testing/reporting the software for me as possible, as I am only one person.
I have not seen the issue where the screen basically goes all white. Can you describe what you did that caused this? If you were manually editing the file to add the ISO, maybe there’s a typo somewhere that’s giving the symptoms that you’re seeing. To my knowledge, the web GUI is using CTRL+M (^M) for new lines so we don’t have \n within the source to actually make the file. That’s not to say something wasn’t missed and whatever information you can provide will be extremely helpful.
Thank you,
-
RE: Latest FOG 0.33b
This is normal behaviour with the kernel. The kernel has to load all the drivers, and the drivers it thinks it needs, when the client is booting into the system. Some systems take longer, some systems take much less time. I don’t know where the differences lie within all the possible types of systems, so this is likely to be something I’m not going to be trying to correct for. The error’s you’re seeing are, in some way’s, to be expected, as they’re basically just telling you the kernel loaded the driver, but there’s no equipment or item to relate it to. They’re generally, as I like to call them, “false” errors.
I don’t know if there are still problems with logical partitions and swap. The r1023 -> and up, revisions should have mkswap/swapon/swapoff and should read the partitions, though I don’t know your particular setups. It’s also using partclone now, so creating/deploying the image shouldn’t be a problem in and of itself.
The one thing I haven’t played with yet, is just using partclone to make an exact replica of the drive vs. the partitions.
I imagine the partitions should only be needed specifically for resizable disks, but could forsee an issue if we copy the drive as is in disk size issues later on. What I mean by this, is if we copy the drive “as is” will it affect drives that might be larger than the original image created drive in limiting the actual size available? These are unknown to me which is why I tried leaving things in, more or less, the same state as before.
I hope this helps. If you’re noticing issues with logical partitions and swap, please try to describe what you’re seeing.
Thank you,
-
RE: Set mysql password after installation
If you’re trying to add a password to your non-passworded mysql use this command:
[code]mysqladmin -u root password ‘PASSWORD’[/code]
Of course change PASSWORD with your password. If you’re going to use special characters such as !@#$%^&*() You’ll need the quotes.
If you’re trying to change a password to a passworded mysql use this command:
[code]mysqladmin -u root -p’OLDPASSWORD’ password ‘NEWPASSWORD’[/code]Changing OLDPASSWORD and NEWPASSWORD to their respective passwords.
Hope this helps.
-
RE: Lenovo Thinkpad x240
I’ve built a kernel that I’d like you to try. I don’t know where the hold out is, so this kernel has bios info embedded as well as all possible (I could find) intel drivers as well. Hope it helps.
[URL=‘https://mastacontrola.com/fogboot/kernel/bzImageLenovoTest’]https://mastacontrola.com/fogboot/kernel/[COLOR=#000000]bzImageLenovoTest[/COLOR][/URL]
[COLOR=#000000]Thank you,[/COLOR]
-
RE: Deployment starts fast but then it slows
I’m under the understanding of your setup. You basically received the systems with OS Pre-loaded on them. You’re trying to create the image based on what was originally sent to you.
Most times, I’d recommend performing a complete fresh install. This will set the partition 1 to the setup FOG prefers, (100MB first Partition).
This isn’t really necessary, but it just makes sure things work properly for your setup.
-
RE: Deployment starts fast but then it slows
What is the size of the Hard drive?
As it’s being partitioned, chances are this drive is a 250GB drive?
The size you’re seeing on the server (29GB) means the compressed image is taking 29GB worth of space.
Factor in that Gzip compression/Pigz compression, usually compresses down to about 40-50% of the actual image data, this leads me to think your image size, when deployed to a machine, is actually around 60GB. Does this sound about right? This information is displayed on the Client during an upload/download task.
-
RE: Hanging after choosing registration
I’d start with trying another kernel.
[code]sudo cp /tftpboot/fog/kernel/bzImage /tftpboot/fog/kernel/bzImage.orig
sudo wget --no-check-certificate -O /tftpboot/fog/kernel/bzimage https://mastacontrola.com/fogboot/kernel/bzImage[/code]The commands above will copy your original kernel as a backup under the name bzImage.orig, and the second one will get the kernel 3.12.4 I’ve created.
-
RE: Modify init.gz
My init gz is compressed in lzma to make it smaller. However if you decompress it you want be able to decompress as lzma. To extract run this command.
[code]lzma -d -c /tftpboot/fog/images/init.gz > /tftpboot/fog/images/init[/code]Mount the init file as per normal instruction. Add your script. Unmount the file and recompress as gz. To recompress run this command.
[code]gzip -9 < /tftpboot/fog/images/init > /tftpboot/fog/images/init.gz[/code] -
RE: Debug mode : can't load keymap
The init.gz you’re currently downloading is for 0.33, let me update the init.gz link in the post, I updated the read link, but the actual link is still pointing to init.gz
The kernel is at:
[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]
The init.gz will be at:
[url]https://mastacontrola.com/fogboot/kernel/init_0.32.gz[/url]
When you copy the file to the fog server, use these commands:
[code]cp /tftpboot/fog/kernel/bzImage /tftpboot/fog/kernel/bzImage.orig
wget --no-check-certificate -O /tftpboot/fog/kernel/bzImage https://mastacontrola.com/fogboot/kernel/bzImage
cp /tftpboot/fog/images/init.gz /tftpboot/fog/images/init_orig.gz
wget --no-check-certificate -O /tftpboot/fog/images/init.gz https://mastacontrola.com/fogboot/images/init_0.32.gz[/code]It’ll be posted in just a few more minutes, having to edit a little bit on my buildroot stuff.
-
RE: Unable to upload image
Okay,
I’m sorry about that. The “scribbly screen” as I like to call it, just means it can’t process the kms (kernel mode setting) properly. It should be creating the image though.
-
RE: Debug mode : can't load keymap
Just updated the link to the file that should be downloaded for 0.32.
I had to add the kbd program.
If you have problems with this init.gz please let me know so I can make one more slight adjustment.
Also, this is being built off of the same buildroot I’ve been working with lately (2013.11), but I don’t know what kernel headers were used for the building of the init.gz, so I’d recommend updating your kernel to the one I’ve created, as the kernel headers are built off 3.12.X and I don’t know how nicely it’ll play with older kernels.
-
RE: Unable to upload image
It’s not the error that’s giving you the issue.
Download my kernel:
[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]
Copy it to your FOG Server with the following commands: (ON THE FOG SERVER TERMINAL OR CONSOLE)
[code]sudo cp /tftpboot/fog/kernel/bzImage /tftpboot/fog/kernel/bzImage.orig
cd /tftpboot/fog/kernel/
sudo wget --no-check-certificate https://mastacontrola.com/fogboot/kernel/bzImage[/code]Then try uploading again. You may have to recreate the task.
-
RE: Unable to upload image
I don’t see the picture, I’m assuming meant to put in, but no worries,
Just describe what the error message says.
-
RE: Debug mode : can't load keymap
I’m building now.
Once the init.gz is complete, you should have all keymaps available. I only, slightly, had to modify the regular fog script as the latest one doesn’t do too well with kB methods of parted and a part 2 starting where part 1 is ending.