Hi all,
I'm posing this under newbie 'cos it's a newbie type of error, I'm ashamed to say. I was attempting to create an image file of a Mint 20 (Ulyana) installation I have on my Thinkpad laptop using a Puppy live CD (which has always worked amazingly well for such purposes in the past) when something went very wrong so that I now cannot boot up my laptop (I just get a flashing cursor in the top left hand corner of the screen). I've been able to boot it up from a live CD and found that the file structure and user data is all intact on the hard drive (thank god) so that the only issue seems to be that the laptop won't boot up any more for some reason. I was using a bare command line instruction invoking dd and that seems to have caused the problem, whatever it may be.
It's very late in my part of the world now, so I'd like to know in advance to save me time what kind of additional info do I need to post to get advice on fixing this problem please?

Can you tell us the dd command?
Are the partitions all what you'd guess to be?

Exactly what do you mean by doesn't boot. Do you see anything? Can you press spacebar just after you think POST ended to try to access grub command line?
Any uefi here?

Others may have questions I'd hope too.

~/.bash_history should have that dd command you ran somewhere not too far from its end. Find it and show it to us if you can. Include several commands before and after as well to provide possible context for your intent and/or a possible solution. If you were using sudo or su at the time, possibly it would be in /root/.bash_history instead. Use code tags around your paste here ([ # ] above the input window).

Does Ctrl-Alt-F3 after all has gone quiet produce a command prompt?

Unfortunately it looks like the dd command was run from a liveCD and a reboot has been attempted. So no bash history - hopefully the OP can remember it; exactly.

Below are the instructions I was following, using a Puppy live CD. I kept getting a persistent "is a directory" error message, despite mounting and unmounting source and destination volumes in all combinations and trying each out. I finally got it to work ( or so I thought) by substituting the /dev/part of the commands with /mnt/ instead.

==================================================================================================== ==============================

Imaging a Linux drive or partition first requires minimizing the wasted space caused by imaging a drive which may be only 15% used:

Create an enormous file filled with zeroes to use up all the unused portion of the drive or partition:

sudo dd if=/dev/zero of=$HOME/zerofile.bin bs=1M

Check the size of the resulting file (zerofile.bin) is approx. correct, then delete it.

Now you can image the drive:

dd if=/dev/sda conv=sync,noerror bs=4096 | gzip -c > /destpath/imagename.img.gz

Be sure to replace the device names shown here for example purposes with the correct ones for the particular circumstance!

There are options you can use with gzip to increase the amount of compression if necessary should space on the destination drive be limited.

=======================================================================

I did notice one odd thing, though, when creating the zerobin file, it turned out to be only 1.6Gb in size instead of the 75Gb I would have expected. Not sure if there's a clue there somewhere.

No idea what a 'uefi' is, I'm afraid. All I'm getting when I attempt to boot is a flashing cursor top left of screen; that's all. I invoked Gparted from the live CD and the partitions at least *look* exactly as they did before the issue arose.

uefi is the modern way for computers to boot, replacing the old bios.

Booting is a sequence, not an event. It takes place in stages.
1) The bios or uefi is in charge and gives you a system message (usually a logo of some kind)
2) The bootloader takes charge. For Mint, that would be GRUB. It displays a menu or (if something has gone wrong), a prompt.
3) The Linux kernel is loaded and started. You get kernel messages.
4) The kernel messages give way to system messages as daemons and configuration programs start up.
5) Your graphical login manager appears.

At what point in this sequence do you get your flashing light?

PS: I've reported the spammer above.

It doesn't make as far as Grub. The cursor comes up immediately after then BIOS screen message: "press blue Thinkpad Vantage button to interrupt normal startup"
Would repairing Grub assist? I have a copy of the first 512 bytes of the hard drive somewhere on a thumbdrive.

Whether that helps or not depends on whether your computer has a BIOS or a UEFI. A BIOS reads GRUB Stage 1 from the mbr, and that loads GRUB Stage 2. But a UEFI reads Stage 2 directly from the EFI System Partition and never looks in the mbr. I suspect that is the kind of setup you have and you have damaged your ESP. That would cause the UEFI to hang because it can't find anything bootable (though most UEFIs do give you an error message at this point).

Boot from your live CD and use gparted or fdisk to check your partitions. In a UEFI setup the ESP is usually the first or second partition. It has a vfat filesystem on it and should contain a file called grub64.efi. If you don't have an ESP, then you are probably booting from a BIOS, and restoring the mbr might be an idea.

1 members found this post helpful.

So we now know what you were supposed to do - not what you actually did. Still.You cannot create a bootable image by dd'ing mount-points. Simple as that.
But simply dd'ing a drive (or anything else) to somewhere else doesn't affect it - certainly won't make it unbootable. So we aren't being told the entire story - pointless trying to continue to help with half, or less, of the applicable info.

Well I just managed to find the drive with the MBR on it and overwritten the hard drive and it's come back to life! Something must have damaged it in the first place, though. Anyway, I've made dozens of successful images in the past using dd but I think I need a refresher on the subject - or maybe a more user-friendly alternative. I should mention I'm not a techie, just a regular computer user who got sick of Windows 14 years ago, moved to Linux and never looked back.
Thanks, all.

Yes, it's definitely BIOS. This hardware is quite old. Anyway, restoring the MBR worked. THanks!