#434 Recovery of Debian13 image fails because /dev isn't created

[shh]

Hi,
I'm using Ubuntu-based testing images, a Plucky from June and 20251005-questing.
Both of them do not create the /dev folder on the destination drive, resulting in a kernel panic, because Debians 6.12.48+deb13-amd64 cannot mount the dev filesystem.
I had to manually create /dev to fix this (booted to bash, mount sda2, mkdir /dev)
Partition scheme is: 1 MB empty, 300 MiB EFI/vfat, ~470MiB ext4.
Images about a year ago worked flawlessly.

[shh]

I realize, that even an old 20230903-LU image doesn't create a /dev folder after restoring the partition. Hmm.
Restoring an old Debian 12(!) image creates this /dev folder, so no problem.

So this brand new Debian 13 Trixie isn't capable of creating /dev itself for mounting the udev-filesystem. And /dev doesn't seem to be imaged by Clonezilla.

However, /dev afaik is a real folder on a source system, nothing virtual like /proc or /sys. And kernel/initrd seems to need it. So I think Clonezilla should create /dev after restoring the root partition of a linux system.

[Steven Shiau]

Clonezilla actually does not deal with "file" or "directory" in the file system. It just save and restore the used blocks. Hence I have no idea about why you mentioned it does not create "/dev/".
Maybe you can share more info why you think Clonezilla fails there is due to lacking /dev?

[shh]

So used blocks should contain all metadata, including the complete directory structure, right?

The src ext4-filesystem contains a /dev folder - I just checked again, via external booting from a different system, and mounting the partition.
Process is:

• I take a complete image of the whole disk (=EFI(nvme0n1p1)+ext4(nvme0n1p2)
• I restore this image completely, but after the completion go into /tmp/root**** (that's where nvme0n1p2 is mounted) and see what what restored.
• in the restored partition all other folders are restored, exept the /dev folder - it's just missing.

I can of course provide log files or info about the image, if you tell me which ones.

[Steven Shiau]

That's very weird... We never had this issue, and no one reported this issue before.
No idea actually...

[shh]

Some tests later:

• 20251017-plucky: I created a new image and did a recovery. /dev is present on the src ext4-partition nvme0n1p2. After recovery, the /dev folder is missing
• 20230903-lunar: I created a new image and did a recovery. /dev is present on the src ext4-partition nvme0n1p2. After recovery, the /dev folder is missing. I also did a recovery of an image created with the newer 20251005, (without any resulting /dev afterwards).

This is weird, I don't know how this could happen.
The old 20230903-lunar worked fine for a long time with any distribution combinations (also multi-boot Debian12 with Win10) on these computers (and others also).
Now I have this fresh Debian 13 install with grub 2.12. Ext4 is error free and definately contains a /dev directory before imaging.
But the old clonezilla version fails also, so I think the /dev directory block isn't even copied into the saved images ...
(or something went wrong after the copying back all ext4 blocks. I'm thinking of /dev being deleted afterwards somehow by the chroot-process (resizing ext4, recreating the initramfs, checking efiboot stuff).... perhaps some faulty unmounting ... but I'm just guessing and why did all that work before. It must be this Debian installation itself.)

The old version doesn't do a better job upon this system/image so I'm going to stay at 25251017 for further tests.
How can I further check if /dev is even located in my image files? And, perhaps, if some /dev deletion occurred afterwards?

• Debian created some funny image here, is this /dev some magical non-copyable directory? :-(

Attached are some logs to this processes. Hope it helps.

Best regards...

[Steven Shiau]

As I mentioned, the file system imaging engine we use is Partclone. It's a block-based tool. It has nothing to do with the files or directories. I totally have no idea where went wrong there.
Like I mentioned here:
https://sourceforge.net/p/clonezilla/bugs/435/#0af7
If you can reproduce this issue in a VM, please share the files of VM so that we can try to reproduce the issue here.

[bufulo]

I just ran into what appears to be the same exact problem. I created a full disk image of a drive containing a Debian 13 installation using Clonezilla. I immediately wiped the drive to test using Clonezilla to restore. The restored drive was missing the /dev directory and would not boot. I got the same kernel panic failure after init-bottom failed trying to mount /dev on /root/dev because the directory /root/dev did not exist. Apparently the directory wasn't restored. I did the same thing the OP did (mkdir /dev) and was able to boot normally.

I wasn't using a VM but I'm sure the problem is easy to reproduce. I did nothing special and chose the default settings all the way thru using Clonezilla. I'll be doing the same thing again very soon so I'll confirm and post here when the same thing happens again.

[Steven Shiau]

Thanks for your feedback. As I have mentioned, we never encountered this issue here. The restored Debian 13 works well here.
If you can reproduce this issue in a virtual machine, please share the VM with us.
If the issue is reproducible here, definitely there is a chance this issue can be fixed.

[shh]

Hello,
I just tested clonezilla-live-20260525-resolute-amd64 and the bug is gone!
Image creation & restore works now (again), and /dev is properly created upon restore. Restoring an old image also worked. Thanks for whatever you did! :)

[Steven Shiau]

Thanks for your feedback.
This is interesting... Somehow it's fixed by some newer packages from upstream? Maybe...