Upload / Download issue

[Tom Elliott]

@Sozen now reboot the system, but don’t let it network boot.
I want to see if your system starts booting now.

All we’re doing is switching the boot flag from SDA2 to SDA1 and the sfdisk allows us to do that non-interactively. So yes, expected to have no output.

[Sozen]

@Tom-Elliott
Sorry, it remain black screen ft “_”

[Tom Elliott]

@Sozen Do you know if the system had an image before?

Would you mind trying:

sgdisk -Z /dev/sda

Then run the command fog from back within the debug menu?

You’ll be prompted to hit enter a bunch of times but that’s because you’re in debug.

[Sozen]

@Tom-Elliott
Yeah I mean I tried to copy some on this one . And before I’ve started put my images on it there was nothing.

Nothing happened after :
http://hpics.li/f71c535

Tried to reboot and still our lovely _

[Tom Elliott]

@Sozen That’s okay.

I have another suspicion to the problem but not a good way to fix it unfortunately.

Do you still have the machine that you used to “upload” the image originally? Can you perform, more or less the same sequence to get that system into a Debug session (but choose Upload - Debug)?

No I don’t want you to run the sfdisk or sgdisk commands on the “upload” machine. All I want from that is the fdisk -l /dev/sda if you can provide it.

Thank you,

[Sozen]

@Tom-Elliott
Ok there is the result !

http://hpics.li/a25cc46

Should I run the upload ?

[Tom Elliott]

@Sozen Based on what I’m seeing. It is indeed due to size of the originating hdd.

Both disks have the exact same partition layout (but the originating system the hdd is 250GB while the receiving system is 150GB).

This has to be the problem. No you do not need to upload, but I do think you need to change the image from a non-resize mode and capture it as resizable.

[Sozen]

@Tom-Elliott
So I’m gonna upload a rezisable one, try to download it on the client ! I’ll keep u informed about the progress !

Thx for everything but imo this will continue tomorrow its already late in france

[Wayne Workman]

@Tom-Elliott said in Upload / Download issue:

you need to change the image from a non-resize mode and capture it as resizable.

That’s the answer.

[george1421]

@Wayne-Workman I agree. You can’t play with the format (sizeable vs non-resizable) once the image has been captured. If you capture it resizable you must deploy resizable. The same for non-resizable capture.

[Sozen]

@george1421 That’s because I’m on my way to create a new images ! Resizable this time… Hopefully the upload wont take too long :s

[Sozen]

Hey there !

First thing first,

The upload ended yesterday night all seems to be ok !
(strange thing that the new image got the exact same size than the non rezisable one tho)

I tried to download it on my hosts and I get this:

File: \BOOT\BCD
Status: 0XC0000001
Info: An error occurred while attempting to read the boot configuration data.

I used the options (Single disk resizable) there no others resizable mode on my fog…

Thx !

Edit: forgot to say that the download is instant and I guess it shouldn’t be

[Sozen]

@Tom-Elliott
Vous parlez francais?

[Quazz]

My guess is something went wrong with the upload.

Most likely FTP failing to move the newly captured images.

Can you check in /images/dev if there’s a folder there?

[Sozen]

@Quazz
Hmmm you are right there is nothing in /images/dev
All my images are in /images

[Sozen]

@Quazz And… What I should I do to fix this?
Thx

[Quazz]

@Sozen /images/dev should be empty (bar .mntcheck) after a successful upload.

However, given that it is obviously not working properly, something else is up. Might be worthwhile to try and capture again and watch it closely.

Does it resize before capture? (if no, then you’re not using resizable image type)

Does it capture every partition?

Does it report any errors at any stage?

[Tom Elliott]

@Sozen If you were capturing the image, the and the image is NOT in /images/dev, it means all things went fine. However, the naming convention of the /images/dev folder is typically /images/dev/<macofhostuploading>

The other reason the image might be exactly the same size? A resizable image moves the partition layout to allow the image to go onto a smaller disk. All imaging formats FOG uses (partial exception with RAW) only captures the used space. So it’s entirely possible, if the machine that uploaded the image before is uploading the image again, but as resizable, the data didn’t change at all.

[Wayne Workman]

@Sozen I agree with Quazz. You should watch the upload process.

[Sozen]

@Quazz

Yeah I’ll try to do that !
Not sure about how I can check if he captured every partition tho…
Any idea?
Edit : is it normal that when the data block process end, the total block process in at 20-30%?

Thx !