Posts made by dylan123

@Sebastian-Roth said in Very slow cloning speed on specific model:

@darkxeno @dylan123 @Middle @oleg-knysh Build is done. Anyone keen to test?

sudo -i
cd /var/www/html/fog/service/ipxe
wget https://fogproject.org/kernels/bzImage-4.9.51
wget https://fogproject.org/inits/init-4.9.x.xz
chown apache:apache bzImage-4.9.51 init-4.9.x.xz

Thanks @Sebastian-Roth , I’ve just got back from leave. Ended up just manually setting up the device and don’t have another one to test with unfortunately. If I do, I’ll give this a test and see if it makes a difference. Thanks again for your assistance.

@Sebastian-Roth said in Very slow cloning speed on specific model:

Is you image set to “Partclone zstd” or “Partclone grip”??

Can confirm I’m using partclone gzip

@Sebastian-Roth said in Very slow cloning speed on specific model:

@dylan123 Now that you have downloaded the kernel make sure it’s in the right location (/var/www/html/fog/service/ipxe/), then edit the host’s settings in the web UI and set bzImage-4.9.51 as Host Kernel. Schedule a task, boot the device and pay attention to where it says bzImage-4.9.51... ok.

Thanks Seb.

Had some issues when I attempted to run the image.

Just showing I’ve got the files in the right area -

Have put the argument in -

When it boots, It says the Kernel is old and then it goes to this -

It then just counts up from /dev/nvme0n1p2, 3, etc

Without the init argument I get a different kind of issue which ends in -

Fatal : Kernel too old
Kernal panic - not syncing: Attempting to kill init! exitcode=0x00007f00

kernel Offset: disabled
—[ end Kernel panic - not syncing: Attempting to kill init! exitcode=0x00007f00

I’ve only got one more machine to go so I might just be better doing this one from scratch but figured I’d mention it anyways as I’m sure someone else will likely have a similar issue and if it’s something I can fix in the next couple of days I’ll do it that way before manually setting it up.

@Sebastian-Roth said in Very slow cloning speed on specific model:

@Duncan Just updated the kernel in https://fogproject.org/kernels/bzImage-4.9.51

Please re-download and try again.

I’ve been having a similar issue as the OP with one of these images. I’ve updated my fog to the latest version and got the latest kernel but I suppose that it doesn’t necessarily mean it gets the older ones.

I’ve ssh into my Fog environment, ran a command to download the kernel however I’m not sure what to do with it after that point?

@george1421 said in Database Connection Unavailable:

@dylan123 I was just thinking about it on the way into the office this AM. Being out of space on the root partition would keep mysql from starting. I’ve done it my self. Now that you restored it from backup that evidence is kind of gone. But if you issue a df -h lets see what your free space is now?

Here’s the result of that -

I’m not sure which of the outputs the database sits on to know whether it’s out of space or not.

I still have a backup of where it doesn’t seem to work as my first restore had the same issue so I can bring that back temporarily to do some testing/troubleshooting to try pin it down further.

@Sebastian-Roth said in Database Connection Unavailable:

@dylan123 What about the error logs??

If I remember correctly I did reset my VM to an earlier state as well just to get rid of the issue. But I’d really be interested to know how this happens. I find it really strange.

If I run cat /var/log/mysql/log.error I still get a no result return. Running journalctl -xe doesn’t show up any of the errors it previously was, it ends with ‘the start-up result is done.’

@dylan123 said in Database Connection Unavailable:

I’m trying to restore from a VM took 37 days ago, hopefully that does the trick… Will report back.

Just confirming that this backup worked thankfully so that’s a good result.

Thanks for the time and efforts as always guys, much appreciated!

@Sebastian-Roth I gave it a crack but not luck. Well it seemed to get rid of the permission errors but I just got generic failed to start -

– The result is failed.
Oct 29 19:19:24 Fog sudo[1883]: pam_unix(sudo:session): session closed for user
Oct 29 19:19:24 Fog systemd[1]: mysql.service: Unit entered failed state.
Oct 29 19:19:24 Fog systemd[1]: mysql.service: Failed with result ‘exit-code’.
Oct 29 19:19:24 Fog systemd[1]: mysql.service: Service hold-off time over, sched
Oct 29 19:19:24 Fog systemd[1]: Stopped MySQL Community Server.
– Subject: Unit mysql.service has finished shutting down

I’m trying to restore from a VM took 37 days ago, hopefully that does the trick… Will report back.

@george1421 So gave it a restart and tried running the command again but it failed.

Result when running systemctl status mysql.service

Result when running journalctl -xe

The denied entries seem interesting, not that I know why they’d be getting denied but I imagine that might be the issue.

I get no return at all though when I run cat /var/log/mysql/error.log

Everything had been running fine for a couple of years so I’m confused at to what’s happened. Must have been an update it’s done by itself, just find it strange that restoring hasn’t worked.

@george1421 Hey George,

I assume the command should be systemctl?

When I changed it to that it is just blank until I quit out of it -

Running Ubuntu version 16.

@george1421 Hey George, see below for the outputs to your questions.

I’m not sure if the mariadb is separate to the mysql one or together? That’s what I get when I try to run the command though.

In terms of the log file, I’m seeing the below -

Cat seems to be the right command but doesn’t open anything when I run it?

Hi all,

Attempted to log onto my FOG server yesterday afternoon and got a ‘database connection unavailable error’. I did some reading on the forum and came across this thread - https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy which seems to be the issue I’m having in that it’s on Ubuntu 16.

I tried the first suggestion of re-running the fog server by doing the following -

• sudo -i
• cd /root/fogproject
• git checkout dev-branch
• git pull
• cd bin
• ./installfog.sh

This completed however I’m still getting the same error and I can see in the install that mysql part completes -

I then tried the second suggestion there which was opening MYSQL but when I do that, it’s unable to connect to it and I then try start the service and that has an error which I could see in the log -

I tried to roll this back to a veeam image from a couple of weeks ago and I’m getting the same issue. It might be that I need to go back further but I think I read on here that others who have tried the same had the same issue of it not fixing the database.

I’m hoping I’ve missed something simple in what I should be doing but I’m just not sure what that might be or what I should attempt to do next.

Any help would be great.

@Sebastian-Roth Might be right about the computer as it has been faulty with a lot of crashing. I tried to open it up however once I took the back off (~2015 MacBook Pro) I didn’t really have access to anything without taking the keyboard off which I didn’t want to attempt to do.

I tried on an alternative Mac however I was unable to get it to show the USB on boot - tried a hard restart, ram clear, fully reformatted etc but couldn’t get it to play.

Will try another mac the next time I get my hands on one.

@p4cm4n Out of curiosity, once it finished transferring the 37gb and had the other ~473gb to go, did it just go about it’s business or did it stop? Mine seems to bug out and go to a black screen with white text with the rejecting I/O to offline device kind of thing. That being said, when I actually boot the laptop it works with the image it took down.

Just tested and it didn’t take up 500GB of data as such although it still wants to push down 500gb as such so it is a little more time consuming than usual to back up so interested to hear how you’re making images of your machines.

Edit: Not really working though, it seems to reach about 10% before it has a “WRITE FPDMA QUEUED” type issue followed by saying “rejecting I/O to offline device”.

Will keep playing though.

@drewklein22 I just gave your USB method a shot and it seems to be working which is fantastic!

Couple of questions however:

• Are you having to go non resizable with your images to capture the image? I’m trying this right now and the Mac HDD is 500gb which from the looks of things, means it’s going to back up 500gb worth of data even though it’s only using say 30-50gb. Is this an issue for you or do you have a work around? When I tried to select single disk resizable I got 'invalid operating system id: Apple Mac OS (8) (validResizeOS).

• I did test with a Apple ethernet to USB along with a Microsoft and neither of those worked as you said, only ethernet to thunderbolt. Have you tried this with the USB - C devices? I plan on trying the next time I get a spare one for a period but it will be a bit of a hurdle if it’s only working via thunderbolt.

Anyways, I’ll likely report back on the second one, curious to hear about your results with the top one though (or anyone else).

@Sebastian-Roth Yeah it is, at least to one I did about 5 days prior and I hadn’t done any system updates.

I won’t rule out the firmware, just think it would be unlikely as the end user wouldn’t have done any special updates and if it was a Windows one, I imagine I would have had more issues by or I might have seen someone else post on here now unless it’s only just came out in the past few days.

Just wasn’t sure if this might have been a more ‘generic’ issue that some have come across. It’s the first machine I’ve ever had with this issue and I feel like I’ve done a lot of deployments/captures with FOG (well not really, probably around 50-100 surfaces over time).

Will keep my eye out for it, unfortunately I’ve got the end user back on the machine for the time being as I was attempting to quickly roll them over to a replacement machine by capturing their image and pulling it back down to a new machine. Might be a little while before I get another chance to play.

Will post back here with any updates the next time I try.

Thanks

Hey guys,

Not sure how to best describe this. Have one particular surface which I’m trying to capture which it freezes after going ‘init.xz…ok’ and nothing further happens, see attached -

I’ve left it like this for 15 minutes and nothing further happens. I tried to delete the host to do a quick registration to see if that would do anything different, it seems to kick it off and after it gets to the ‘init.xz…ok’ the screen just goes black and nothing else happens.

This system works fine for other surface’s, so it’s just hanging on this one and I’m not really sure why.

I’ve just updated my fog server to the latest update of 1.5.4 but this hasn’t made any difference.

Any advice/ideas?

@fishfox said in Securing NFS:

Agree with all Tom’s points, NFS is not a simple protocol to harden.

What I recommend is VLANing your FOG network so it is manually exposed via your switch configs. Does require managed switching, but will accomplish the task.

Yeah that was kind of what I was thinking as I believe you can restrict access to particular IP ranges and then just having it on another VLAN range which is accessible from my desk - given I usually do all imaging at my desk.

Kind of thought the below would be the response but figured I’d ask the question as you guys know a lot more then me.

Hey,

We recently had a penetration test done at my work where it was listed that the fog server has overly permissive NFS in where they were able to gain access to the images directory.

I’ve done a bit of reading on what can be done to tighten up security but a few solutions I’ve seen such as Kerberos seem like it could potentially have impacts to how the fog server operates.

I came across NFS security on the fogwiki - https://wiki.fogproject.org/wiki/index.php?title=FOG_security#Securing_NFS suggesting more to come soon however this was mid 2016, just wondering if there might have been an update?

I don’t know a great deal in this area but I keep thinking that by securing it, will I then run into issues when trying to upload/deploy an image onto a random device?

There’s also a section on ‘securing your images’, by doing the two steps mentioned in that section, would this in a way cover off ‘securing NFS’? I imagine it stops being able to connect to the images directory of the fog server without account access but if that was the case, wouldn’t that cover the securing NFS? Probably not that easy, my understanding in the area in minimal so I’m understanding the basics without fully understanding how it works.

So with the ‘manage-bde -off C:’ command, are people then turning that back on once the image is created/deployed? Or given Bitlocker isn’t on, not bothering?

I suppose it’s made me think I should potentially look at turning bitlocker on for some staff members which will probably just be a manual process, but just wondering if I should then be turning the above command on when I do it.