Unable to Capture Using Single Disk - Resizable
-
@shatchett0 I’ve only ever used RHEL based linux with fog, currently using Rocky myself. If you’re more comfortable with debian then nothing wrong with that.
Which kernel did you update to? There should be some “experimental” ones from earlier this month that work great.
Also 1.5.10 not 1.5.10.1593 ?
You should update to at least the latest stable version. I can help with that if you need it. -
Sorry getting back so late. I backed out of debian and went with a clean install of Alma Linux. Downloaded the tar file for 1.5.10.1593 and installed that. Still seeing same issue. Here’s a screen capture of the version that I’m on. And it does say that I’m not up to date. Any advice would be appreciated. Thanks for your help!
-
@shatchett0 what is the format of the drives?
The formats we do accept for resize:
Ext (2/3/4)
Btrfs
Ntfs
Fat
XfsIf it’s not got any of those types of partitions, of course it won’t be able to capture them.
-
@shatchett0 I always install with the git method as it makes updates easier, but both should work the same.
I would suggest trying the git method. I’ll have to go test the tar version and see if I get the same result, it’s odd that it’s not showing you what the latest other versions are there, might be an HTTP vs HTTPS thing, might be a firewall issue, I saw something in another forum post where someone’s firewall was blocking the search for latest versions or something like that.I would also try canceling the task, boot the host to the pxe menu, and use the check compatibility option. Make sure it shows as compatible with FOG and that all the hard drive info shows the partitions you expect.
If you just installed it should have downloaded the latest kernel and init during the install, if you click on that “DefaultMember FOG Version:” box/modal it should expand and show the kernel version.
I also just noticed that your image definition shows Windows 10 (OS ID of 9) but the error message on capture shows osid=50 which is Linux, are you sure you have the right image assigned on the host being captured? (I would also increase the compression level for Zstd to 11, but that’s just me)
-
@JJ-Fullmer My inexperience with Fog is showing. I’ve been pretty careful but obviously in this particular case not careful enough. Since I last posted I did a clean install of FOG (tar version) on a clean install of Alma Linux. It seemed to work pretty well. Moving to a big (for me) machine using Alma and a clean FOG install. I’ll take a look at the doing the Git install.
-
@Tom-Elliott Hey thanks for getting back. This is the filesystem on the drive. But, oddly, with a new Alma Linux and FOG install I was able to do Single Disk - Resizable. I posted to JJ about my next steps. I’ve got to hit this with a hammer. It’s all I have .
-
@shatchett0 So it is working now on the new install?
-
Moved to a new Alma install. Used the git install. I could not register an Ubuntu 20.04 host. I then diid a clean install of Alma and used the latest tar for FOG. Was able to register a host but could not capture single disk resizable. Posting this pic of the error. Curious if anyone sees anything obvious. Thanks for any input.
-
@JJ-Fullmer Sorry JJ. I’ve been checking for replies but today is the first I’m seeing this. It was working on an old z840 with 1 TB of storage. I’ve not moved to a Dell Server with 120 TB and I posted an image of the error I’m seeing in my latest update dated 9/16/2024.
-
@JJ-Fullmer “boot the host to the pxe menu, and use the check compatibility option”
Hey JJ. what are the steps to do this?
-
@shatchett0 you would cancel the capture task and then boot the host to pxe and you should see a compatibility check in the fog boot menu.
The error also looks like an issue with ext4 thinking it’s a dirty filesystem being captured. If you schedule the capture task with debug checked you can try running the file system check tools interactively. This looks like a problem with this specific host and the image being captured more than a fog server issue. -
@JJ-Fullmer That is helpful. I’ll run those.
-
@JJ-Fullmer It looks like one of my problems was that I was runnning two network interfaces. One was going to our production network, the other to the fog network. I deleted the production interface and that eliminated the random errors I was getting. I was getting one consistent error during capture “Could not mount images folder (/bin/fog.upload) Args passed: Reason: mount: 192.168.7.184:/images/dev/ on /images failed: No such file or directory”
I had a 125 TB raid for internal storage (images) and a separate system drive for the OS and fog. So I installed the OS and fog on my raid. I can now consistently capture images with no problem. Deploying is the problem now. I’ve attached a pic. If anybody sees anything in the error please feel free to chime in.
BTW I have been using the compatibility feature to ensure the hardware passes muster.
Thanks!
-
Glad to hear it’s working for capture now. You should be able to mount /images on a separate disk without issue, but having it all in the same place is fine too.
I’m not 100% sure what that error is saying. At least not with enough detail to be helpful right off the bat.
First thing that comes to mind is a sector mismatch. If your image was captured from a disk with 512e sectors and you try to deploy to a 4kn disk (or vice versa) you’ll get errors when it tries to align the partition table because the sector sizes can’t align. It’s a limitation in disk alignment at a lower hardware level. I have some notes on when I was debugging such an issue in this post https://forums.fogproject.org/topic/17112/surface-go-4-incompatible
It could also be a simpler issue of the image doesn’t fit on the new disk. In most cases the resizable takes care of it, but if the image’s min size is bigger than the disk, not much can be done. But it looks like it’s an all disk or all partition image?
-
@JJ-Fullmer Hey, I’ll check out the notes you posted. I’m back at it after dealing with other issues.
-
@JJ-Fullmer I think you’re right. It’s a matter of disk size. I have to be more conscious of the source disk size in relation to the destination disk size. I am capturing consistently now and deploying more reliably.
So my problems really amounted to network issues (I had two interfaces that confused my fog server) and the other was not paying more attention to my disk sizes.
Thanks for all your help and patience with this.
Steve
-
@JJ-Fullmer I would mark this one as solved. I didn’t see a way for me to do it. Thanks, again
-
[[undefined-on,
J JJ Fullmer, ]]
