This issue involves restore of a Win10-Pro operating system to a "fanless mini PC" sold with OS pre-installed.

I have purchased several of these small, fanless computers for use by low-tech clients who only need moderate internet access...such as email and/or browsers. For backup, I have been making an image of the entire embedded 64 GByte boot disk (or SSD, or EMMC, or whatever) using Clonezilla. Recently, one client deleted much of her operating system by mistake. I tried to restore her system...but Clonezilla cannot create a partition table on the embedded drive. I've attempted to create a mirror of her drive...using an external USB disk...in order to recover her data. This also fails. As near as I can tell, it is not possible to restore a Clonezilla backup of these systems to any media.

I'm using Clonezilla v2.6.4-10-amd64. Source drive is (was) a 64 GByte embedded SSD of some sort. I've attempted multiple restore operations to the original system. No Joy. I've also attempted to restore to flash sticks, SSD drive (in USB carrier), spinning laptop drive (in USB carrier), and uSD (in USB adapter).

I have many photos...but I'm not seeing any "post a photo" links on this forum.

The show-stopping error appears to be as follows:
"Failed to create a partition table on this disk: /dev/sdb"

Creating a partition (with partition table and disk label) in advance appears to be fruitless...because this release of clonezilla uses a destructive "dd" command to zero-out portions of the target disk.

Earlier on...from reading the /var/log/clonezilla.log file, there appears to be an error when trying to access /dev/sde. This confuses me...to the best of my knowledge, the original system had only one drive (the boot drive). And /dev/sdc in the restoration system is the clonezilla backup image storage flash stick.

Any help and/or advice would be appreciated.

Not ever having used Clonezilla, I'm making an educated speculation here. I downloaded the 2.6.4 .iso file and mounted it. Its kernel's timestamp is approaching 4 years of age. I have to guess that the bootloader and/or the kernel and/or a Clonezilla binary app are out of sync about device names, so that each is making different assignments of device names to the devices found, mixing up sda, sdb...sde, possibly not even supporting the newer storage devices you have. Device enumeration order at POST and driver load can affect storage device naming when mixing removable and various types of "internal" storage. This kind of problem is why bootloaders, initrds and fstabs switched years ago to using UUIDs instead of device names by default. What you should be able to do is boot a newer live distro from which to run the Clonezilla software. Another option is to use one of the "testing" versions of Clonezilla.

Well... Supposedly the 64-bit version of Clonezilla was recently upgraded to incorporate Debian kernel version 5.3.7-1. This does not disagree with your observation, as v5 was first released in February of 2009. Still, I have to assume that the Clonezilla authors have been keeping-up with advances in storage tech. Otherwise there would be no point to the ongoing bugfixes and point releases. Your suggestion (to try a newer/experimental version of Clonezilla) is a good one. I'll do that. But these little "hocky puck" computers are not bleeding edge tech. For example: Intel "cherry trail" processors were released in 2015.

(Can I post a link to sourceforge? Let's try it...)
https://sourceforge.net/p/clonezilla...4-10-released/

V5 of what?

I just booted 2.6.4-10. Kernel is 4.2.0-27, Ubuntu 15.10 Wily.

That woud be "Debian kernel version 5.3.7-1".

Here's the link to the notice on the Clonezilla(dot)org web site.
https://clonezilla.org/downloads/sta...ease-notes.php

Wikipedia identifies the v5.0 release as codename "Lenny", and puts the release date as February, 2009.
https://en.wikipedia.org/wiki/Debian...2%80%93present)

I'm thinking that the specific linux distribution is not all that important...as long as it can load and run the Clonezilla code. For what it's worth, I did try using an older stable release of Clonezilla, and the error messages look the same, the failure sequence looks the same, and the log file looks the same.

-----
Update:

Current compiled version of Clonezilla is available with either an Ubuntu kernel or a Debian kernel.
https://clonezilla.org/downloads.php

It looks like there is confusion between kernel version and Debian version. Lenny is the Debian 5.0 release of 2009, which used kernel 2.6.26.

https://downloads.sourceforge.net/pr...wily-amd64.iso is what I downloaded and burned. It looks like Clonezilla's mirroring system is messed up and I somehow got an old version labeled as the current version by the sourceforge URL I reached. Now I've burned and booted https://downloads.sourceforge.net/pr...4-10-amd64.iso and it is indeed running Debian's 5.3.7 kernel.

Nevertheless, I've seen inconsistency in storage device names among components booting various distro's kernels going way back, as well as within recent months.

Posting images need not be done here directly if you cannot figure out how "Manage Attachments" works. Just use a pastebin and post its URL:

• http://susepaste.org/
• http://paste.opensuse.org/
• http://paste.centos.org/
• http://paste.debian.net/
• http://paste.fedoraproject.org
• http://pastebin.com/
• http://paste.ubuntu.com/
• https://gist.github.com/

Thoughts.

Source was a emmc I'd think. Most of those fanless would need to have uefi enabled to use it at all. Might have to be sure to select uefi boot for clonezilla to access it.

Not sure the naming is correct here. Better check /dev/sdb

If you are taking a single windows 10 image and trying to deploy it across hardware... well...

If I've loaded the images correctly, then you will see two photos of text left by a re-installation failure. Same failure...two views. Clonezilla is verbose...and the text scrolls rapidly during operation. The third photo is the logfile from /var. Sorry for the blurriness.

This particular failure is from CZ v2.6.4-10 with a Debian kernel. My earlier stable Debian CZ version...v2.6.2-15 fails in the same way. Original system has a single data store of approx 64 GBytes. For this attempt, I'm using an external fujitsu laptop drive with 320 GBytes capacity. (CZ keeps asking if the "disk is too small" and so I selected a target that was at least twice as large as the original capture.)

CZ executes a "dd if=/dev/zero..." command on /dev/sdb. My understanding is that this command wipes the legacy file structure info on /dev/sdb. This is the correct thing to do...near as I can tell...and seems to execute correctly. Subsequent attempt to create a partition table on /dev/sdb fails...which is my most recent/current barrier.

I'm puzzled by the references to /dev/sde. The "unrecognized disk label" errors appear to be meaningless. I've made several attempts after manually creating both MBR and GPT partitions, and inserting a disk label. If I pre-insert a disk label, the error messages vanish...but the partition creation failure does not.

For verification purposes...I created CZ backups of my desktop system. My desktop OS is also Win10-pro. I was able to restore the desktop backup to a spinning external drive, and to a SSD external drive. Both booted afterwards. (So...I now have three working copies of my desktop OS.) I'm thinking that the problem stems from the original "minisforum" OS implementation. To date, all the new "minisforum" systems have booted their pre-installed Win10-pro OS correctly and flawlessly...and so I concluded that the OS installations are/were conventional. I've never closely examined the internal file structures/partitions. (I foolishly thought that the CZ backups and "restorable image" checks were correct and reliable. Never had a CZ failure like this...in the past.)

Update:
-------------
The original (failed...dead...bricked) system is not currently available to me. I'll attempt the "enable UEFI boot" restoration next time I visit the client. If memory serves...I can still access the system's BIOS. Nevertheless...it seems that I should be able to restore the CZ OS backup to a non-emmc external drive...right?

Attached Thumbnails

     

I get the feeling you can find out more by going to a different console while booted to see tools like mount and parted and such for clues.

mc, efibootmgr, lsscsi, lsusb, parted, fdisk, gdisk, mount, lsblk, blkid, partprobe, grep, chroot, grub-mkconfig 2.04-3, which, systemctl, systemd, dpkg-reconfigure, all tested to open from live CZ 2.6.4-10 CD-ROM boot to shell, so it seems to be competent for performing text mode rescue activities. bootinfoscript, apropos, grub2 shell & man are missing though.

Try using "boot to shell" to run fdisk -l, to see if the device names match what you are expecting, as when booted normally from nvme or emmc or whatever.

1 members found this post helpful.

I don't currently have access to the "bricked" unit. I brought the CZ backups home last Monday, and have been trying to rstore them to various media...in order to recover my client's files. No joy, so far. I may be able to retrieve the "bricked" unit tomorrow/Saturday. In the mean time...I did run "fdisk -l" on the setup I've been using as a host.

#####
Disk /dev/sda: 298.9 GiB, 320072933376 bytes, 625142448 sectors
Disk model: TOSHIBA MK3259GS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x39126fa9

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 471246847 471040000 224.6G 7 HPFS/NTFS/exFAT

Disk /dev/sdb: 298.9 GiB, 320072933376 bytes, 625142448 sectors
Disk model:
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F38C912E-B6A5-46A5-930B-2E617E938C75

Device Start End Sectors Size Type
/dev/sdb1 2048 625141759 625139712 298.1G Microsoft basic data

Disk /dev/sdc: 7.22 GiB, 7744782336 bytes, 15126528 sectors
Disk model: Patriot Memory
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00161f93

Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 2048 15126527 15124480 7.2G c W95 FAT32 (LBA)

Disk /dev/sdd: 58.61 GiB, 62914560000 bytes, 122880000 sectors
Disk model: Flash Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x02295b0b

Device Boot Start End Sectors Size Id Type
/dev/sdd1 128 122879999 122879872 58.6G b W95 FAT32

Disk /dev/loop0: 229.18 MiB, 240304128 bytes, 469344 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
#####

I'm not much of a linux user. These look mostly OK to me. One outlier. /dev/sda is the host's boot drive. /dev/sdb is the target...spinning laptop drive. /dev/sdc is the boot-up flash stick with CZ live on it. /dev/sdd is the second flash stick, with the backup files/directories. I'm not sure about /dev/loop0.

A replacement "hocky puck" computer arrived from Amazon. Physical appearance is identical to the unit that my client "bricked". I tried using G-Parted to view the partitions in a factory-fresh unit. The unit immediately threw a security message and halted.

Quote:
[ 10.021740] efi: EFI_MEMMAP is not enabled.

I carefully searched through the unit's BIOS settings, and cannot find any switches that relate to this security message. I don't want to indiscriminately alter too many BIOS settings, since I need this unit to replace the "bricked" unit.

pprotus,

The Target drive doesn't need to have a partition table, partitions, or filesystem when restoring from a Clonezilla image.

There is no need to used GParted on the new Intel NUC’s drive.

The only thing that occurs to me is that GParted, just like Clonezilla stable, is also Debian-based and this may account for the "EFI_MEMMAP is not enabled" message.

Try using the alternative stable Clonezilla which is based on Ubuntu Eoan:
https://clonezilla.org/downloads.php

Then boot in UEFI mode.

I was able to replace the "bricked" system with a new unit, the day before Thanksgiving. Let's call it "comp-1". I brought comp-1 home, and tried booting it again...it was truly FUBAR. I was able to enter the BIOS screens, but Win 10 on the eMMC was totally non-functional. For grins, I tried booting G-Parted (Debian version). No joy. G-Parted threw a new and mysterious error message. (See attached image.) By chance, I had a Win 10 version update ZIP bundle, that used/uses EFI to install. I extracted the files and copied them to an external (spinning) drive. I set the BIOS to boot the external drive using EFI. The drive booted, and the update brought Win 10 Pro back to life. I will be able to repair the updated OS...I think. It's looking promising.

Sorry, but I did not use the ubuntu version of CZ to attempt recovery from a CZ backup. Once the Win 10 "five balls" started cycling, I went after a repair of the OS...which looks like it will succeed. For what it's worth, the Win 10 update appears to have deleted all of my client's files...assuming she did not delete them herself. Since the Win 10 OS looks recoverable, which saves me the cost of a system, I'm not planning to experiment with CZ any further. Although I will be looking for another backup application.

Thanks for all your help.

Attached Thumbnails

 

pprotus,

Glad to hear that you have made some progress.

Look no further than Macrium Reflect Free for imaging a Windows drive:
https://www.macrium.com/reflectfree

Review:
https://www.dedoimedo.com/computers/...reflect-7.html

Tutorial:
https://www.tenforums.com/tutorials/...m-reflect.html