Image corrupted after upload to server



  • Hello,
    recently I came across a problem that have been giving a lot of headaches.
    I have a computer I use to create Image of Debian. When I give upload the image to the server, the computer image stops working and displays the following message: “Reboot and Select proper Boot device or Insert Boot Media in selected Boot device and press a key.”
    NOTE: The image that went to the server also has this problem if I try to use it on some other computer.
    NOTE 2: The image I am trying to create is Debian. With another image (eg Ubuntu) this problem does not appear.
    NOTE 3: The problem started only appear for a while now and just that image (Debian 7).
    NOTE 4: You tried to delete the server image and climb it again, but the error persisted.

    I use FOG 4469



  • @danilopinotti If you can get in touch with me via Chat, I’d be happy to explain and even help out if we could schedule it.

    Beyond that, follow the instructions below. Just test it for each revision. When you find one that fails, try the one between the failed version and the last working version you tried. Keep doing that until you find which version it is.



  • @Wayne-Workman
    Do you have any tips to facilitate the process?
    Until then I installed FOG and a DHCP server on itself. I would like to update gradually and go testing each SVN?



  • @danilopinotti Then use a real machine to test.

    FOG is a community driven project. meaning not just driven by random people, but organizations that use fog as well (mostly organization driven, actually). In order to narrow down what’s wrong, we need to know where it’s wrong.



  • @Wayne-Workman
    I do not get my boss’s authority to create virtual machines and test SVNs



  • @danilopinotti said:

    @Wayne-Workman
    It would have somewhere that explains how to do to go giving these small changes in SVN?
    What is the SVN fog 1.2.0?

    1.2.0 is SVN 2094 I believe.

    To pull a specific version down, you would use:
    svn co -r 2094 https://svn.code.sf.net/p/freeghost/code/trunk

    After getting the initial copy, to update to any specific version, it would be like this:
    svn -r 2500 up

    svn -r 3000 up

    svn -r 3500 up

    and so on.

    Using virtualization and snapshots, you could quickly “go back” when you hit a version that didn’t work, and then start trying versions between the last one and the failed one, to quickly find which version made the change that breaks fog.

    Keep in mind that fog DOES NOT support downgrading! Please build a test server to do this testing with!



  • @Wayne-Workman
    It would have somewhere that explains how to do to go giving these small changes in SVN?
    What is the SVN fog 1.2.0?



  • This post is deleted!


  • @danilopinotti If you can get it to work in 1.2.0, then it’s just a matter of slowly upgrading that 1.2.0 server through the svn revisions until it no longer works. It would be best if you could build the 1.2.0 server inside of a virtual machine so you can take snapshots before each update and roll back if needed, in order to locate exactly what svn revision fog stops working for this situation.

    If we can identify exactly which svn version it stops working with, then it will be easy for the @Developers to fix it.



  • @Wayne-Workman
    Today is not possible but tomorrow i can try to arrange this.



  • @danilopinotti Is it possible for you to test using 1.2.0 ?



  • @Wayne-Workman Thank you

    I don’t remember when I created the image (when it worked) I’ve used the Trunk or still using 1.2.0



  • @danilopinotti You’re English is good enough. :-)

    You said that previously, the Debian image worked?

    What was the last SVN revision that it worked with? And it has previously worked with Debian 7 specifically?



  • @Wayne-Workman

    Sorry for my english.

    I put an image from another computer (an image with Ubuntu) that this was giving problem. With that, I noticed that the problem is in the Debian image and not on the computer.
    Previously, this image Debian did not have this problem. I have no idea why.
    Did not do Dual Boot or anything else.

    I’m better at reading English than to write, so write these means strange phrases.



  • @danilopinotti So you’re dual booting? It seems that English isn’t your mother tongue, look at this Wikipedia article to see what I mean by “dual booting” https://en.wikipedia.org/wiki/Multi-booting



  • @Wayne-Workman
    No. I put another image on it with Ubuntu.
    Before I could climb this (faulty) for FOG, but now does not. Now happens that I described.



  • @danilopinotti said:

    @Wayne-Workman
    The strange thing is that in my case, I do not use Dell computers (if it is a chance) and it only happens with this in particular. If I put an Ubuntu on the same computer, this works with FOG.

    Yes, but are you completely deleting every single pre-existing partition before you install Ubuntu or Debian ?



  • @Wayne-Workman
    The strange thing is that in my case, I do not use Dell computers (if it is a chance) and it only happens with this in particular. If I put an Ubuntu on the same computer, this works with FOG.



  • @Tom-Elliott said:

    @Uncle-Frank because many times it’s an awkward size. Adjusting this partition in any way tends to break booting the system in whole.

    Is it at all possible to verify (beyond doubt) that it is a Dell Recovery partition and simply upload the partition without attempting to resize it?

    A partially re-sized image is much better than an inoperable image.


  • Developer

    @Tom-Elliott Well, sure! You are absolutely right. I wasn’t aware of this being a resizable image. I tend to overlook this as we are mostly using non-resizable images here at work!


 

465
Online

5.4k
Users

12.6k
Topics

118.6k
Posts