• Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
  • Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

FOG 1.5.6: Auto resize is unpredictable

Scheduled Pinned Locked Moved Solved
Bug Reports
7
57
7.5k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • E
    Eric Johnson
    last edited by Jul 11, 2019, 1:50 PM

    So… current status.

    Since it worked all the time with my diff with a Pause I just removed my Pause in non-debug mode… Seriously.

    I have done 6 multicast deploys to 4 machines with this init and had no resize problems. Running with the original init showed 1-2 out of 4 resize failures.

    This of course is NOT what I would call a fix. Kinda a workaround. And I don’t know if this is fixing the problem or just making it less likely to happen, as this should not be actually fixing anything. I through it out here for folks who might run into the same problem as a workaround till we figure out what the hell is going on… 🙂

    diff -u /mnt/init-orig/usr/share/fog/lib/partition-funcs.sh /mnt/init/usr/share/fog/lib/partition-funcs.sh
    --- /mnt/init-orig/usr/share/fog/lib/partition-funcs.sh 2019-05-04 17:58:07.000000000 -0400
    +++ /mnt/init/usr/share/fog/lib/partition-funcs.sh      2019-07-11 09:22:49.000000000 -0400
    @@ -401,8 +401,15 @@
         #    majorDebugPause
         #fi
         #[[ $status -eq 0 ]] && applySfdiskPartitions "$disk" "$tmp_file1" "$tmp_file2"
    +    processSfdisk "$minf" filldisk "$disk" "$disk_size" "$fixed" "$orig" 
    +#        Pause ESJ
         processSfdisk "$minf" filldisk "$disk" "$disk_size" "$fixed" "$orig" > "$tmp_file2"
         status=$?
    +       echo $tmp_file2
    +       ls -l $tmp_file2
    +        cat $tmp_file2
    +#        Pause ESJ
    +
         if [[ $ismajordebug -gt 0 ]]; then
             echo "Debug"
             majorDebugEcho "Trying to fill with the disk with these partititions:"
    
    1 Reply Last reply Reply Quote 0
    • E
      Eric Johnson @Sebastian Roth
      last edited by Jul 11, 2019, 1:53 PM

      @Sebastian-Roth Doh. Good idea, should have thought of that. But since even just doing some other output (see my recent post) seems to make the problem vanish…

      Dis one is very odd.

      Q 1 Reply Last reply Jul 11, 2019, 2:46 PM Reply Quote 0
      • Q
        Quazz Moderator
        last edited by Jul 11, 2019, 1:58 PM

        I created a PR to fix some stuff and to hopefully handle errors better/more reliably.

        I don’t think it will fix this problem necessarily, but it should should hopefully throw errors when we expect it to.

        https://github.com/FOGProject/fos/pull/26

        You can download the inits of it here: https://dev.fogproject.org/blue/organizations/jenkins/fos/detail/PR-26/2/artifacts

        if you’re interested in testing it out.

        1 Reply Last reply Reply Quote 1
        • Q
          Quazz Moderator @Eric Johnson
          last edited by Quazz Jul 11, 2019, 8:47 AM Jul 11, 2019, 2:46 PM

          @Eric-Johnson Interesting. Could you add

          cat /proc/sys/kernel/random/entropy_avail
          

          before and after your output commands?

          Just a wild hunch

          If my hunch is correct, then I suspect you could replace your output commands with any other output commands and it would work. Alternatively, you could smash the keyboard a couple of times.

          E 2 Replies Last reply Jul 11, 2019, 7:56 PM Reply Quote 0
          • E
            Eric Johnson @Quazz
            last edited by Jul 11, 2019, 7:56 PM

            @Quazz That was a crazy brilliant idea! 🙂

            I did the below, first cat before anything, then the processSfdisk to the screen then a second cat, then a pause so I can read it and it probably wasn’t important at that point (I think that would have shown the entropy increase, please let me know if I am miss-understanding what you wanted to see) but on two unicast tests so far… 2260 before / 2261 after (identical)

            Going to do a multicast test to all 4 in a sec. See if there is any variation.

            diff -u /mnt/init-orig/usr/share/fog/lib/partition-funcs.sh /mnt/init/usr/share/fog/lib/partition-funcs.sh
            --- /mnt/init-orig/usr/share/fog/lib/partition-funcs.sh 2019-05-04 17:58:07.000000000 -0400
            +++ /mnt/init/usr/share/fog/lib/partition-funcs.sh      2019-07-11 15:31:10.000000000 -0400
            @@ -401,8 +401,19 @@
                 #    majorDebugPause
                 #fi
                 #[[ $status -eq 0 ]] && applySfdiskPartitions "$disk" "$tmp_file1" "$tmp_file2"
            +cat /proc/sys/kernel/random/entropy_avail
            +    processSfdisk "$minf" filldisk "$disk" "$disk_size" "$fixed" "$orig" 
            +echo "after"
            +cat /proc/sys/kernel/random/entropy_avail
            +
            +        Pause #ESJ
                 processSfdisk "$minf" filldisk "$disk" "$disk_size" "$fixed" "$orig" > "$tmp_file2"
                 status=$?
            +       echo $tmp_file2
            +       ls -l $tmp_file2
            +        cat $tmp_file2
            +#        Pause ESJ
            +
                 if [[ $ismajordebug -gt 0 ]]; then
                     echo "Debug"
                     majorDebugEcho "Trying to fill with the disk with these partititions:"
            
            Q 1 Reply Last reply Jul 12, 2019, 7:38 AM Reply Quote 0
            • E
              Eric Johnson @Quazz
              last edited by Eric Johnson Jul 11, 2019, 2:19 PM Jul 11, 2019, 8:18 PM

              @Quazz grrr. no luck. entropy started pretty high and was only slightly higher after the call to processSfdisk in 8 out of 8 cases… 2258-2261 before and after in all cases.

              Was a great idea, worth trying though!

              1 Reply Last reply Reply Quote 0
              • E
                Eric Johnson
                last edited by Jul 11, 2019, 11:37 PM

                Current status:

                Tried clever suggestion from @Quazz … it didn’t pan out.

                But inspired me to think outside the box. Tried using /root/sfblahblah.$$ instead of /tmp (since tmpfs is different than ramdisk…) That was just as unsuccessful.

                Just adding a “sync;sync;sync” (cause anything I tell you three times is true) seems successful. On two tests so far.

                Maybe?

                Current working diff…

                [root@fog ipxe]# diff -u /mnt/init-orig/usr/share/fog/lib/partition-funcs.sh /mnt/init/usr/share/fog/lib/partition-funcs.sh
                --- /mnt/init-orig/usr/share/fog/lib/partition-funcs.sh	2019-05-04 17:58:07.000000000 -0400
                +++ /mnt/init/usr/share/fog/lib/partition-funcs.sh	2019-07-11 18:10:20.000000000 -0400
                @@ -401,8 +401,17 @@
                     #    majorDebugPause
                     #fi
                     #[[ $status -eq 0 ]] && applySfdiskPartitions "$disk" "$tmp_file1" "$tmp_file2"
                +#    processSfdisk "$minf" filldisk "$disk" "$disk_size" "$fixed" "$orig" 
                     processSfdisk "$minf" filldisk "$disk" "$disk_size" "$fixed" "$orig" > "$tmp_file2"
                     status=$?
                +sync;sync;sync
                +#	echo $tmp_file2
                +#	ls -l $tmp_file2
                +#        cat $tmp_file2
                +#echo "after"
                +#cat /proc/sys/kernel/random/entropy_avail
                +#Pause #ESJ
                +	
                     if [[ $ismajordebug -gt 0 ]]; then
                         echo "Debug"
                         majorDebugEcho "Trying to fill with the disk with these partititions:"
                [root@fog ipxe]#
                
                T 1 Reply Last reply Jul 12, 2019, 12:35 AM Reply Quote 1
                • T
                  Tom Elliott @Eric Johnson
                  last edited by Jul 12, 2019, 12:35 AM

                  @Eric-Johnson what about replacing sync with sleep 5? Sync is just ensuring cached items in wait get pushed to disk, maybe the scripts are working just a slight bit too fast?

                  Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                  Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                  Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                  1 Reply Last reply Reply Quote 0
                  • S
                    Sebastian Roth Moderator
                    last edited by Jul 12, 2019, 6:00 AM

                    @Tom-Elliott While you might be pointing to the right spot here I don’t thing adding a time based sleep is a great idea.

                    Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                    Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                    1 Reply Last reply Reply Quote 0
                    • Q
                      Quazz Moderator @Eric Johnson
                      last edited by Quazz Jul 12, 2019, 3:14 AM Jul 12, 2019, 7:38 AM

                      @Eric-Johnson I mostly wanted to see it before and after your cat and ls commands and such, but I don’t think it matters, since 2000+ should be more than enough for just about anything anyway.

                      I was thinking that perhaps certain hardware wouldn’t generate enough entropy in time and that that would cause issues.

                      @Sebastian-Roth @Tom-Elliott Do you reckon it would be good idea to try and store the output in a variable as opposed to a file and use it as such?

                      1 Reply Last reply Reply Quote 0
                      • S
                        Sebastian Roth Moderator
                        last edited by Sebastian Roth Jul 12, 2019, 6:16 AM Jul 12, 2019, 12:15 PM

                        @Quazz While I am not against your idea of trying to move this from file to variable I really wonder why we see this issue right here lately. Did we always have this issue and people just didn’t report? I doubt that! Or is it a change we pushed out in the last weeks? I have gone through the commit and nothing really makes sense from my point of view.

                        I just try to take one step back before we head into trying to fix this. Is this hardware specific? @Eric-Johnson
                        Should we try a 1.5.5 or even 1.5.4 FOG server and see if it’s the same?!

                        Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                        Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                        Q 1 Reply Last reply Jul 12, 2019, 12:25 PM Reply Quote 0
                        • Q
                          Quazz Moderator @Sebastian Roth
                          last edited by Quazz Jul 12, 2019, 6:29 AM Jul 12, 2019, 12:25 PM

                          @Sebastian-Roth From what I gather, it’s an issue that isn’t happening under every circumstance (personally haven’t ran into it, having deployed to hundreds of devices over the course of each new init release), but does happen reliably under certain conditions.

                          It seems odd that a momentary delay in the script or otherwise a sync of the “disk” (as in the ramdisk) would prevent this issue from appearing again.

                          From what I can tell, people did start reporting such issues after a certain version, perhaps a buildroot update (Just looked and Buildroot version 2019.02 has bugfixes up to 2019.02.4 now! changes list: https://git.busybox.net/buildroot/plain/CHANGES?id=2019.02.4) ? People tend to wait a while before updating, so we may have to look a bit further back.

                          1 Reply Last reply Reply Quote 0
                          • E
                            Eric Johnson
                            last edited by Jul 12, 2019, 1:19 PM

                            Bad news. On the 3rd deploy with sync;sync;sync one failed.

                            Good news:

                            I moved all the metering to AFTER the sfdisk (and didn’t send the sfdisk output to /dev/null as was suggested by @Sebastian-Roth ). Found something interesting. Twice on one of the 4 machines the sfdisk is failing with a disk in use error. The input is good, no issue with the tmp file. But sfdisk seems to think the disk is in use. I think we have the smoking gun.

                            Adding some df and swapon -s now to see if this I can see the disk in use by some other tools. Next step if to dig up sfdisk source and see what makes it think it is use.

                            Maybe --force or --no-reread as suggested by the error mesage as a BFMI workaround? 🙂

                            --- /mnt/init-orig/usr/share/fog/lib/partition-funcs.sh 2019-05-04 17:58:07.000000000 -0400
                            +++ /mnt/init/usr/share/fog/lib/partition-funcs.sh      2019-07-12 08:37:10.000000000 -0400
                            @@ -73,7 +73,14 @@
                                 local file="$2"
                                 [[ -z $disk ]] && handleError "No disk passed (${FUNCNAME[0]})\n   Args Passed: $*"
                                 [[ -z $file ]] && handleError "No file to receive from passed (${FUNCNAME[0]})\n   Args Passed: $*"
                            -    sfdisk $disk < $file >/dev/null 2>&1
                            +#    sfdisk $disk < $file >/dev/null 2>&1
                            +    sfdisk $disk < $file 
                            +echo " "
                            +echo $file
                            +ls -l $file
                            +cat $file
                            +Pause #ESJ
                            +
                                 [[ ! $? -eq 0 ]] && majorDebugEcho "sfdisk failed in (${FUNCNAME[0]})"
                             }
                             # $1 is the name of the disk drive
                            @@ -403,6 +410,8 @@
                                 #[[ $status -eq 0 ]] && applySfdiskPartitions "$disk" "$tmp_file1" "$tmp_file2"
                                 processSfdisk "$minf" filldisk "$disk" "$disk_size" "$fixed" "$orig" > "$tmp_file2"
                                 status=$?
                            +#Pause #ESJ
                            +
                                 if [[ $ismajordebug -gt 0 ]]; then
                                     echo "Debug"
                                     majorDebugEcho "Trying to fill with the disk with these partititions:"
                            

                            alt text

                            Q 1 Reply Last reply Jul 12, 2019, 1:39 PM Reply Quote 1
                            • Q
                              Quazz Moderator @Eric Johnson
                              last edited by Quazz Jul 12, 2019, 7:50 AM Jul 12, 2019, 1:39 PM

                              @Eric-Johnson Very interesting, here’s what sfdisk man page has to say about it.

                              sfdisk uses BLKRRPART (reread partition table) ioctl to make sure
                                     that the device is not used by system or another tools (see also
                                     --no-reread).  It's possible that this feature or another sfdisk
                                     activity races with udevd.  The recommended way how to avoid possible
                                     collisions is to use exclusive flock for the whole-disk device to
                                     serialize device access.  The exclusive lock will cause udevd to skip
                                     the event handling on the device.  For example:
                              
                                            flock /dev/sdc sfdisk /dev/sdc
                              
                                     Note, this semantic is not currently supported by udevd for MD and DM
                                     devices.
                              

                              So perhaps adding flock $disk before sfdisk $disk < $file will resolve it

                              Making the line read as flock $disk sfdisk $disk < $file

                              E 1 Reply Last reply Jul 12, 2019, 2:32 PM Reply Quote 1
                              • E
                                Eric Johnson @Quazz
                                last edited by Jul 12, 2019, 2:32 PM

                                @Quazz

                                Reading the man page eh? Silly me downloading util-linux and tracing through source… LOL. (Hadn’t really started that except the download part 🙂 )

                                Three times with flock $disk sfdisk $disk < $file now, no resize errors.

                                Gonna remove all the debug code and let em run to completion now.

                                I think ya got it though! 🙂 Thanks!

                                1 Reply Last reply Reply Quote 2
                                • T
                                  Tom Elliott
                                  last edited by Jul 12, 2019, 4:20 PM

                                  This is really good information. I suppose it could be useful especially with the speed of NVMe usurping so many other disk access things, maybe udev is the issue the whole time in regards to “sporadic access” and usability?

                                  Thank you all for the debugging and communication.

                                  Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                                  Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                                  Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                                  1 Reply Last reply Reply Quote 0
                                  • E
                                    Eric Johnson
                                    last edited by Jul 12, 2019, 4:53 PM

                                    Two 4 stations multicasts. No resize problems. Below diff is only change. I think this one is done! 🙂

                                    diff -u /mnt/init-orig/usr/share/fog/lib/partition-funcs.sh /mnt/init/usr/share/fog/lib/partition-funcs.sh 
                                    --- /mnt/init-orig/usr/share/fog/lib/partition-funcs.sh 2019-05-04 17:58:07.000000000 -0400
                                    +++ /mnt/init/usr/share/fog/lib/partition-funcs.sh      2019-07-12 10:26:47.000000000 -0400
                                    @@ -73,7 +73,7 @@
                                         local file="$2"
                                         [[ -z $disk ]] && handleError "No disk passed (${FUNCNAME[0]})\n   Args Passed: $*"
                                         [[ -z $file ]] && handleError "No file to receive from passed (${FUNCNAME[0]})\n   Args Passed: $*"
                                    -    sfdisk $disk < $file >/dev/null 2>&1
                                    +    flock $disk sfdisk $disk < $file >/dev/null 2>&1
                                         [[ ! $? -eq 0 ]] && majorDebugEcho "sfdisk failed in (${FUNCNAME[0]})"
                                     }
                                     # $1 is the name of the disk drive
                                    
                                    1 Reply Last reply Reply Quote 1
                                    • E
                                      Eric Johnson
                                      last edited by Jul 12, 2019, 4:58 PM

                                      Found a couple more sfdisk that might need protecting…

                                      [root@fog ipxe]# diff -ur /mnt/init-orig/usr/share/fog/lib /mnt/init/usr/share/fog/lib
                                      diff -ur /mnt/init-orig/usr/share/fog/lib/funcs.sh /mnt/init/usr/share/fog/lib/funcs.sh
                                      --- /mnt/init-orig/usr/share/fog/lib/funcs.sh   2019-05-04 17:58:07.000000000 -0400
                                      +++ /mnt/init/usr/share/fog/lib/funcs.sh        2019-07-12 12:57:23.000000000 -0400
                                      @@ -1977,7 +1977,7 @@
                                               sfdiskLegacyOriginalPartitionFileName "$imagePath" "$disk_number"
                                               if [[ -r $sfdiskoriginalpartitionfilename ]]; then
                                                   dots "Inserting Extended partitions (Original)"
                                      -            sfdisk $disk < $sfdiskoriginalpartitionfilename >/dev/null 2>&1
                                      +            flock $disk sfdisk $disk < $sfdiskoriginalpartitionfilename >/dev/null 2>&1
                                                   case $? in
                                                       0)
                                                           echo "Done"
                                      @@ -1988,7 +1988,7 @@
                                                   esac
                                               elif [[ -e $sfdisklegacyoriginalpartitionfilename ]]; then
                                                   dots "Inserting Extended partitions (Legacy)"
                                      -            sfdisk $disk < $sfdisklegacyoriginalpartitionfilename >/dev/null 2>&1
                                      +            flock $disk sfdisk $disk < $sfdisklegacyoriginalpartitionfilename >/dev/null 2>&1
                                                   case $? in
                                                       0)
                                                           echo "Done"
                                      diff -ur /mnt/init-orig/usr/share/fog/lib/partition-funcs.sh /mnt/init/usr/share/fog/lib/partition-funcs.sh
                                      --- /mnt/init-orig/usr/share/fog/lib/partition-funcs.sh 2019-05-04 17:58:07.000000000 -0400
                                      +++ /mnt/init/usr/share/fog/lib/partition-funcs.sh      2019-07-12 10:26:47.000000000 -0400
                                      @@ -73,7 +73,7 @@
                                           local file="$2"
                                           [[ -z $disk ]] && handleError "No disk passed (${FUNCNAME[0]})\n   Args Passed: $*"
                                           [[ -z $file ]] && handleError "No file to receive from passed (${FUNCNAME[0]})\n   Args Passed: $*"
                                      -    sfdisk $disk < $file >/dev/null 2>&1
                                      +    flock $disk sfdisk $disk < $file >/dev/null 2>&1
                                           [[ ! $? -eq 0 ]] && majorDebugEcho "sfdisk failed in (${FUNCNAME[0]})"
                                       }
                                       # $1 is the name of the disk drive
                                      
                                      1 Reply Last reply Reply Quote 1
                                      • S
                                        Sebastian Roth Moderator
                                        last edited by Sebastian Roth Jul 13, 2019, 1:10 AM Jul 13, 2019, 7:05 AM

                                        @Eric-Johnson @Quazz You guys rock!! Thank you very much for digging that deep and finding this!

                                        From the sound of what you describe it pretty much is some kind of timing issue and therefore perfectly matches the findings on the device being busy/locked at that stage. While I still don’t really understand why this is happening now but has not occurred (or not being reported) in the past much I am pretty confident that you have hit the nail on the head with this.

                                        Looking through the scripts I see even more places where sfdisk might bite us and I have a feeling that some other issue reports we currently have might be caused by this same busy/lock problem with sfdisk somewhere else in the scripts. Here is a full (?) list of the places:

                                        roth@x220:~/workspace/fog/fos/Buildroot/board/FOG/FOS/rootfs_overlay$ find . -type f -exec grep "sfdisk " {} /dev/null \; | grep -v -e ":[[:space:]]*#" -e majorDebugEcho
                                        ./usr/share/fog/lib/partition-funcs.sh:    sfdisk -d $disk 2>/dev/null > $file
                                        ./usr/share/fog/lib/partition-funcs.sh:    sfdisk $disk < $file >/dev/null 2>&1
                                        ./usr/share/fog/lib/partition-funcs.sh:    sfdisk -d $disk 2>/dev/null | egrep '(Id|type)=\ *[5f]' | wc -l
                                        ./usr/share/fog/lib/partition-funcs.sh:            parttype=$(sfdisk -d $disk 2>/dev/null | awk -F[,=] "/^$escape_part/{print \$6}")
                                        ./usr/share/fog/lib/partition-funcs.sh:            sfdisk -d $disk
                                        ./usr/share/fog/lib/funcs.sh:    local count=$(sfdisk -d $disk 2>/dev/null | awk /start=\ *[1-9]/'{print $4+0}' | sort -n | head -n1)
                                        ./usr/share/fog/lib/funcs.sh:    [[ $hasgpt -eq 0 ]] && have_extended_partition=$(sfdisk -l $disk 2>/dev/null | egrep "^${disk}.* (Extended|W95 Ext'd \(LBA\))$" | wc -l)
                                        ./usr/share/fog/lib/funcs.sh:            sfdisk -d $disk 2>/dev/null > $sfdiskfilename
                                        ./usr/share/fog/lib/funcs.sh:            sfdisk -d $disk 2>/dev/null > $sfdiskfilename
                                        ./usr/share/fog/lib/funcs.sh:            sfdisk $disk < $sfdiskoriginalpartitionfilename >/dev/null 2>&1
                                        ./usr/share/fog/lib/funcs.sh:            sfdisk $disk < $sfdisklegacyoriginalpartitionfilename >/dev/null 2>&1
                                        ./usr/share/fog/lib/funcs.sh:    fsid="$(sfdisk -d "$disk" |  grep "$part" | sed -n 's/.*Id=\([0-9]\+\).*\(,\|\).*/\1/p')"
                                        

                                        Question: Is there a good reason that we shouldn’t add flock ... to all those calls as well? @Eric-Johnson @Quazz @Tom-Elliott

                                        Though I don’t know if the same can even happen if sfdisk is just reading (-d for dumping the table) instead of it writing to disk but on the other hand I reckon adding flock ... wouldn’t hurt it in any case?!?! On the other hand it sounds a bit like “we don’t know what’s happening here so let’s just try to hit everything with a rock that looks like it might be dangerous” - not my kind of style.

                                        Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                                        Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                                        1 Reply Last reply Reply Quote 0
                                        • fry_pF
                                          fry_p Moderator
                                          last edited by Jul 13, 2019, 10:48 AM

                                          Just want to chime in to say good job everyone! I would have thrown my hat in for testing fixes if I wasn’t sweating my buns off in hot school buildings reassembling classroom technology. I have experienced a pattern of right after uploading an image, as the upload is complete and the machine attempts to come out of sysprep, I get an error. Now I am not sure it is related to this, but I heard someone else having the same issue. After re-deploying to the very same machine with the image that was just captured, everything works just fine. Regardless it looks like you guys already have a good idea of what is going on, so I’ll shut up now 😄

                                          Like open source community computing? Why not do it for a good cause?
                                          Use your computer/server for humanitarian projects when it is idle!
                                          https://join.worldcommunitygrid.org?recruiterId=1026912

                                          1 Reply Last reply Reply Quote 0
                                          • 1
                                          • 2
                                          • 3
                                          • 3 / 3
                                          3 / 3
                                          • First post
                                            42/57
                                            Last post

                                          290

                                          Online

                                          12.0k

                                          Users

                                          17.3k

                                          Topics

                                          155.2k

                                          Posts
                                          Copyright © 2012-2024 FOG Project