Images are not restored on empty(wiped) disks?
-
Hello
Fog download to a wiped disc do not work here (debugging that i ran in an other problem, so pardon for the second thread in 2 days)
I have manually to create a (dummy)partition on the client to make download work.
But that can’t be true for a remote imaging system, or?Image are not restored on empty disks
Steps to reproduce:
Create a VM for Windows 7 32 bit using Virtual Box 4.3.15beta (.14 is broken)
Disk 25GB dynamically, (is filled with zeroes, unformated, uninitialized)Insert CD iPXE.iso (I don’t think that step matters, it’s only for my convience as a can’t change DHCP)
boot iPXE (sets only chain next server IP etc)
boot from fog “default.ipxe”
Perform Full Host Registration and Inventory (works flawlessly)Hostname:xx
Image ID:1
Group:
Produktkey:
AD:nPrimary User: t
#1 tag
#2 tag
Image now? NAt fog-Server Webfront end:
Manage Hosts
List all host
Host Name:tt
Host Image: Gold
<update>List all hosts
click “download”“Download trask created”
Task management
Client boots via ipxe
Linux is directly booting
Some messages with “OK” can be seen
I have to press enter several times
VM boots immediately again without any transferNo image transfer occured
Task became deleted on the fog server
Task became reported as “OK”.FOG “Report Management” says:
fog tt 2014-08-05
11:31:41 2014-08-05
11:31:42 00:00:01 Gold Download1 sec: impossible. There was no transfer at all. There is no windows on the client.
root@fog2:~# uname -a
Linux fog2 3.2.0-67-generic-pae #101-Ubuntu SMP Tue Jul 15 18:04:54 UTC 2014 i686 i686 i386 GNU/Linux
root@fog2:~#Client in debug mode:
root@10#uname -a
Linux 10.0.2.15 3.15.6 #1 SMP PREEMPT … i686 GNU/LiunuxOn the clients “debug” console:
(have to retype the screen output of virtual box…all typos are
mine)
Client debug download
root@10#Hexdump –C –n 1M
Shows all zero
root@10#cat /proc/partition
0 0 262144000 sda
root@10#Fdisk /dev/sda
…
Device does not contain a recognized partition table
Created a new DOS disklabel with disk identifier .l…
wroot@10#fog (start an download at the server)
Does a lot stuff but do not download the imagesNext try:
Create a partition:
root@10#fdisk /dev/sda
n
p
1
w
qroot@10#fog (start a download at the server)
surprise!
“download” works now!
Part clone launches and writes images with 2GB/min
The only difference:
A Partition was written!After the use of the fast wipe command the restore(download) will not work too.
Any takers?
Any hint why only I have that problem? -
i use fog 1.2 on ubuntu 4
-
That I why I created a guide on how to use the Debug system of FOG to create a partition. You need to have A partition on a hard drive if you plan to use it with fog.
[url]http://fogproject.org/forum/threads/quick-format-to-ntfs-with-fog-for-noobs.10349/[/url]
It’s called Quick Format to NTFS but this is misleading as the partition that is actually written isn’t NTFS, but it does create a partition and imaging can be completed.
-
Such a “step-by-step-tutorial” is of great help! Thanks.
I am doing the same “step-by-step” as the surface of fog have some more dark corners
of, em, unconventional usability ways
BOT:
So is my finding is right…
“Not partition no fog!”
But i don’t understand the sense and that’s not what i would have expected.
Are there historically reasons? (See the obsolete hint, that partitions are not resizable)First:
What’s the use of a remote deploy system when i have to “go” to each machine and create partition manually?
Why is that required?
Why can’t this be done remotely. automatically best before the restore?
I found someone has written tons of bash code handling partition, disk detection and resize.
What’s all that code for?Second:
why isn’t that flagged as an error in the machine report?
Only the fast time of less a second gives a hint, that there was something wrong.Of cause, now adays, almost every (Windows) PC is delivered with a partition. i Assume that’s the reason why the board is not full of reports like this.
But VMs and new (replacemant) disks are not pre-partioned and embedded system are not either.
(Initializing the partition on a headless (embedded) system is difficult,
without a local keyboard and console :-))Third(general problem)
how can i get better (debug) loggings?
I hacked the bangshe line to get llittle clue what’s is going on (add -x) , but that’s only locally vissible. -
Because FOG is meant to CLONE to multiple machines. Typically you won’t have to mess with the partitions unless it is in fact a new or blank disk. To be expected. In the olden days you had to create a partition before you could install an OS. Same base here. FOG doesn’t take it upon it’s self to start writing partitions free willy nilly. Imagine if your deployment failed a few times and then you checked the machine to find 40 partitions, sure it’s not that big of a deal, but it’s daunting and scary, and your data would be gone, so Imagine accidentally clicking the Deploy button instead of Upload on your golden image, and it starts down the path and the first thing it wants to do is make partitions, and now all your work is gone…
I have made the suggestion to include a step that will write a blank partition to a disk (if you check the box during deployment) but NOT an always on (default) selection.
so [B]FIRST[/B]
Yes, it does suck to have to touch the machine to create a partition, but it isn’t something that needs to be done on each deployment, if you add a partition and register to fog, you can continue to image that machine indefinitely until something destroys or removes the partitions again.
I am not sure why it is required, ( I bet Tom does).
Again I have made the suggestion to include the option as part of the “deployment” option, but we are actively working to solve real issues rather than ones that can be worked around, and not that often to occur.
[B]SECOND[/B]
I agree with you on the FLAG we should at least get a proper response when imaging and it fails due to a lack of partitions, a warning or an error log where I can check the actual reason would be nice. A check before it completes the job would be nice too! And it has been suggested already
You hit the nail on the head with the last comment (of section 2) there “Of cause, now adays, almost every (Windows) PC is delivered with a partition. i Assume that’s the reason why the board is not full of reports like this.” you are absolutely correct. Many of us are using a mass production model of PC and it comes with an OEM OS on it (so it has partitions) so we can just nuke the information and carry on dancing. The only time this is an issue is if you receive a hard drive replacement from the manufacturer, or you replace the drive with a brand new one, then you need a partition for FOG to store information to.
I don’t have anything to say about the VM machines. you are correct, using this “work around” with a virtual machine could be cumbersome.
I have no expertise on the [B]third[/B] set of questions
-
OK.Thanks for the infos/views.
Hm, is there no way just to (remotely) “dd” a dummy mbr (i have a quite good mbr that works…see “/image” or?)
and partition table (only if the first 512 byte/32MB are all zero(*))?
And fog deploy will overwrite the dummy partition entries. -
I’m starting to wonder @Micahel Thomas if your partitions are laid out in GPT.
While DD works to create a backup of the MBR, it’s not always so simple. If GPT isn’t properly removed, the disk will have a hard time being imaged in the first place.
If the disk doesn’t contain any form of initialization tasks, FOG will have a hard time generating new tables on. I’ve added checks and balances to attempt making this a non-issue in the case of a completely clean, uninitialized disk during a download task, but it appears this has still not been successful.
-
Hello Tom
thanks your “wondering” (and your work on/at fog)
Your are right: It’s hard to get rid off GPT. But that’s by intension, but
I’m lucky currently not to have to handle GPT-
I think i will use fog to deploy an “embedded” OS.
So the disks delivered are empty (i think all “00”), uses MBR.
But don’t (usually) have a BIOS compatible console.
So there is problem with the debug-option
No keyboard, No screen.
Deploying via fog would have been so elegant.If i could give help i would like to help to find the reason while that big fog script fails to detect that the disk is empty.
I see it is looking on /proc/partition and asks sfdisk. All say: There is a “/dev/sda” (but no /dev/sda1)
I used a dd | hexdump to see that the first 32MB are really empty(=zero(0)).A new feature request thread (i’ll place there):
Would it make sense the setup a syslogd so the fog-script could sent persistent log file entries the fog-server.
IIRC this are only some line of configuration in /etc and installing
