Clonezilla: cannot create partition table (old 2013 problem returns!)
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Clonezilla: cannot create partition table (old 2013 problem returns!)
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.
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.
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.
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:
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?
Last edited by pprotus; 11-21-2019 at 04:50 PM.
Reason: Added UEFI comment and question.
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.
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
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.