Posts made by ianabc

OK, apache isn’t started then, you could try starting it manually to see if it throws an error
[CODE]
$ sudo apache2ctl -X -k start
[/CODE]

Is apache running then?
[CODE]
$ ps -ef | grep apache
[/CODE]

Sorry, that startup command was for redhat type distributions, for ubuntu it should be
[CODE]
$ /etc/init.d/apache2 start
$ tail -n 100 /var/log/apache2/error.log
[/CODE]

[quote=“NDNtech, post: 32807, member: 23658”][CODE]root@SC-Image:/# apachectl configtest
Syntax OK
[/CODE][/quote]
That’s good, the apache config must be sane, you can ignore the fqdn stuff for the moment. What about the error.log?

Alright, now could you try the configtest,
[CODE]
$ apachectl configtest
$ service apache start
$ tail -n 100 /var/log/apache2/error.log
[/CODE]

Yeah, sorry about that, my fingers are slower than Toms! that command won’t work until apache is reinstalled.

Your apache config looks broken. What does
[CODE]
$ apachectl configtest
[/CODE]
return now? Also can you try restarting and tailing the end of the error.log - it might help diagnose the reason why apache won’t start.

It looks like the package installation went fine, it looks like the problem might be with the apache configuration. Could you try
[CODE]
$ apache2ctl configtest
[/CODE]
Also you might see errors in your apache log (might be /var/log/apache2/error.log on ubuntu). Just try starting up apache then having a look at the end of that file, e.g.
[CODE]
$ /etc/init.d/apache2 start
$ tail -n 100 /var/log/apache2/error.log
[/CODE]

It might be worth trying to manually install the apache2 package and see what error is getting thrown.
[CODE]
$ sudo apt-get purge apache2
$ sudo apt-get update
$ sudo apt-get install apache2
[/CODE]
*EDIT Remember to purge the packages again when you are done
[CODE]
$ sudo apt-get purge apache2
[/CODE]
My guess would be dependancy problems due to an external repository.

I missed the “hide menu” option as well first time round. It not only hides the display menu but when you hit “Esc” to get into the menu it prompts you for your fog username/password, protecting all of your menu items - including the advanced ones.

I promised to test the linux resizing then dropped off for a bit but I’m testing now and it looks good!

I have an single root partition on 10G ext4fs. Uploading that to a “Single partition resizeable image”, resize picked it up and shrunk it down. After the system rebooted the root was down to 970Mb (285Mb when compressed in /images).

On deploy it popped back up to 10G as expected (the underlying disk is actually a 22Gb qcow2 image). I’m going to dig around in the subversion diffs to see if I can follow along and I’ll try out some alternative configs, but this really great work!

I can’t test it today but I’ll give it a go over the weekend. Thanks!

I’ve never actually played with the windows resizing - I’ve always just done it manually. I’ll take a look at it before I wander off down the wrong path

I’m interested in seeing this, and Tom’s right, the best place for this would probably be in the init before root filesystem is mounted.

Something like a checkbox “Expand to fill disk” associated with the Host (or Image) might work, then if the partition table and filesystem support it run, the resize {ext?,xfs,ntfs} tools after the initial deploy. I’ll try to make a patch if I get time.

Out of interest I gave this a shot, this worked for me
[CODE]
$ parted /dev/sda
(parted) resizepart
Partition number? 1
Warning: Partition /dev/sda1 is being used. Are you sure you want to continue?
Yes/No? yes
End? [51.2GB]? 100%
(parted) quit

$ resize2fs /dev/sda1
[/CODE]
I wouldn’t suggest this as a good idea on a working system, but since you already have your deploy image in fog, don’t worry about messing up the partition table/filesystem. If you make a mistake, you can just redeploy!

A google search for “ubutnu first boot script” or something similar should give instructions on how to do this on the first reboot.

EDIT I chose to do this with “resizepart” rather than “resize” because “resize” will cause parted to try to resize the filesystem itself, I think this is better left to native tools like resize2fs!

[quote=“Bill G., post: 31996, member: 24757”]Thanks for the info… I created a new Raw image on a 40GB HD and deployed the image to a 80GB HD. It created a 40GB partition for the OS and an additional 40GB of “Free Space.” How do I automatically take advantage of all of the HD space, i.e., one 80GB partition?[/quote]

It will depend on the filesystems that you have chosen, but with ext4 as an example, you could write a script to update the partition table with parted and then resize the filesystem with e2fsprogs. You could set this script to run at the next reboot in your image (most distributions have a facility for this already). The complexity of the script would grow quickly depending on your partition layout but if you just have a single root partition it shouldn’t be too difficult.

I would start by booting one of your images and trying to do it manually on the command line. Once you have a sequence that works, make a script and start testing/debugging.

I’ve wondered about doing this as a special type of deploy in fog, but there are so many variations (different filesystems etc.) that it would probably be hard.

This is really puzzling, I’ll dig around and see if I have one of those cards available for testing. I think you already checked this, but could you confirm that in the fog debug ethtool reports 1000Mb as the negotiated speed and that you switch also agrees that this is the negotiated speed?

Here is a sample NFS mount from a linux client - in principle it should all be GigE between the fog server and this machine, but they are quite a few hops apart and those switches and routers might be busy, could you try something similar for comparison?
[CODE]
$ mkdir /fogtest
$ mount -o vers=3,nolock IP.OF.YOUR.FOG:/images/dev /fogtest
$ dd bs=1M count=1024 if=/dev/zero of=zeros.img conv=fdatasync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied 30.5422 s, 35.2 MB/s

$ dd bs=1024M if=./zeros.img of=/dev/null iflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied 21.0712 s, 51.0 MB/s

$ rm zeros.img
$ umount /fogtest
$ rmdir /fogtest
[/CODE]
I’m not too worried (or impressed :)) by these numbers. If you get similar results you know that the problem lies further up the stack.

The iSCSI speed sounds plausible for a single GigE link, but the NFS does indeed seem slow.

If there was a 100Mb link somewhere you would expect to see 7MB/s or so and as you said everything is claiming to be running GigE. 26MB/s is an odd result, especially if that is bi-directional. Can I ask how you are testing? dd over NFS can help but it can be a bit tricky because of the buffering and syncing.

Did you try Tom’s suggestion of switching out the kernel for a test.

Have a fun weekend!

[quote=“braindead, post: 31723, member: 24282”]
My copies are going as they have before: ~75 MB/sec.
[/quote]

Is this is a raw copy over NFS? If not could you try a copy and report the speed? 75MB/s is in the right ballpark for gigabit over NFS.