@sebastian-roth Yes.
GPT partition layouts with SFDISK tend to have the firstlba and lastlba sectors defined for the drive. The resizable element weren’t taking the firstlba into account for the variable sizes.
Making the firstlba (if present) part of the fixed size caused the problem to be fixed.
We need information. What version of FOG are you using?
Your first bet, I think, would be to try upgrading to at least the latest stable.
Can we remote please?
If you’re running 1.5.0-RC-6, then the latest init’s and kernels are already in your FOG setup. So, no, it won’t hurt to do the wget commands as @george1421 or @Sebastian-Roth have suggested, but I don’t think there will be any difference.
You’ll want the registered host kernel argument, for the time being, to be:
isdebug=yes ismajordebug=1
the isdebug=yes will make it so the host will always boot everything into debug, so you don’t have to keep checking the ‘Schedule task as debug’
The ismajordebug will print out more disk based information as the system processes.
To start the process of imaging at the command prompt (if that’s what you want to reference it as) run fog.
I’m pretty sure i know what’s wrong, but I don’t know of a good fix. Having the information as performed will be much more helpful. I’m sure I can get it, but understand trying to get these “little” things worked out is really causing more problems than it’s worth to continue tweaking. I fix one thing, but another thing breaks. It’s really way too finicky to keep adjusting for one, then the other.
Understand this isn’t a dig at you or anybody, just understand my brain is fried from trying to get ALL things working perfectly at his point.
@john-sartoris Way too many pictures with minimal text inbetween makes it hard to follow.
That all said.
/dev/sda2 does not have a partition table.
FOG’s capture system works as such:
Get the current layout.
Attempt to shrink partitions as possible/required. (All partitions)
Once all partitions are shrunk, get the partition table of the disk.
The problem seems to be something with /dev/sda2 though we don’t know what. Something is causing partclone to not even be able to mount /dev/sda2.
I don’t understand the issue. “List filter issue for auto updating lists in new ui…” What does this mean? Is it a bug? the filters should remain on updates. I can just remove all the filters for auto updating lists though. I fail to see the value if all it does is cause issues. Coding for these things is not simple and having to maintain a list of things to be maintained shouldn’t be a requirement. Sorry if i sound rude, but i don’t understand what the problem is.
What is PJ?
Notice the message?
“HINTS:” is the big part, it seems this disk is setup in “RAID” mode?
@george1421 I’ll try to get this fixed, I thought I already did, but I might have missed it already sorry.
To help clarify things.
“Active Tasks” only shows the “jobs” that are to be performed, not every detail of that job as that would take up a lot of room about the “overall” task being completed.
Active Snapin Tasks, is where you can see the individual tasks, the host it’s working from, and their current progress states. Of course they only show up when they’re in pending/progress states. When they’re completed they’re no longer considered active.
This is NOT a report of tasks, but rather an “overview”.
Report pages work differently, in that they should display completed items. Though I’ll admit it’s been a bit since I looked it over.
Confirmed and fixed in working branch. Thanks for reporting.
I’m confused, can you more clearly describe the problem?
Is it snapin reports having the issue? You mean you cannot see “in-progress” tasks on the snapin history report?
@predator Well, I think you’re confusing terminologies here.
FOG Client, in my eyes, is the machine you’re attempting to image. The FOG Client, you’re basing your layout on, is actually what I would term “FOG Server”?
VM Host needs an IP address.
VM Guest = FOG Server as I’m seeing it. (This is the vm guest that’s hosting the fog server)
@predator Why did you setup on 207, but then go to 208?
There may be some GUI bugs here and there, but client operations and primary elements should work as no code changes have occurred for these things. That said, you shouldn’t have any issues “mixing” 1.4.4 and 1.5.0-RC at all, as there also hasn’t been any schema changes and no work on how storage nodes communicate (No FOG Linux Service Changes).
@sebastian-roth I suspect it was my “fixing” code that is now “fixed” but causing a problem with latest updates. Just a guess. My fixing code just made it so fedora could install, and basically all it did was make sure the path it was looking for during startup existed. Now it looks like it’s the reverse, it’s trying to create a file that already exists, hence permission denied… (as it’s likely in use then too).
@george1421 I feel I should point out the boot.wim line has the -n boot.wim portion as well. This tells it the name.
Does this work?
cpuid --ext 29 && set arch x64 || set arch x86
kernel http://${fog-ip}/wimboot
initrd -n BCD http://${fog-ip}/mdtboot/${arch}/ISO/boot/bcd BCD
initrd -n boot.sdi http://${fog-ip}/mdtboot/${arch}/ISO/boot/boot.sdi boot.sdi
initrd -n boot.wim http://${fog-ip}/mdtboot/LiteTouchPE_${arch}.wim boot.wim
boot