Greetings

is there any fast way to switch from sda boot disk to another disk without loosing any data?

say from sda to sdc?

I don't use RAID currently.

Thank you.

are you swapping your drives around and keeping the system on the same drive - just moving it to be your third disk? UUID in fstab, BIOS controlled to search all of your attached drives for a bootable system?

yes is the answer but, without knowing the particulars it is hard to tell you how.

actually I have a problem with the boot disk sda and need to replace it, so I need a way to switch completely and safely to another disk and boot from there

where is the operating system located? how damaged is the "boot" disk?

if you can access it, then having the os on sda, install grub on another disks mbr, update your grub, the set that drive as your boot drive in BIOS.

If this is a EFI boot, then that is going to be another situation, as I do not know EFI well enough other than theoretically.

theoretically, you should be able to set up another disk with your partitions needed and/or just the boot partition put the efi files in there then rework the efi grub to boot your OS on a different drive.


you might even be able to fix it. what happened to your drive to make it no longer bootable, other then total melt down.

os is located in sda, and I want to move to sdd (os and everything in the disk), both disks same type/model/size

the errors in the disks are:

---------------
Aug 10 22:41:54 dr kernel: [1455175.138946] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Aug 10 22:41:54 dr kernel: [1455175.139311] ata1.00: failed command: FLUSH CACHE EXT
Aug 10 22:41:54 dr kernel: [1455175.139502] ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 15
Aug 10 22:41:54 dr kernel: [1455175.140060] ata1.00: status: { DRDY }
Aug 10 22:41:54 dr kernel: [1455175.456591] ata1.00: supports DRM functions and may not be fully accessable.
Aug 10 22:41:54 dr kernel: [1455175.458181] ata1.00: supports DRM functions and may not be fully accessable.
Aug 10 22:41:54 dr kernel: [1455175.458291] ata1.00: configured for UDMA/133
---------------

I'm not sure how bad is the error?

Still applies. Getting those details seems to be like pulling teeth.

Edit: Finally getting somewhere. I tend to swap disks and chase the problem at my leisure. Copying to the other disk is relatively trivial - the easiest way to fix grub is to chroot into the second system once it is copied and do grub-install, update-grub.
After that pull the first disk out to save BIOS issues. For EFI the firmware should find the EFI partition ok.

1 members found this post helpful.

Thank you for the useful info.

Regards.

I've never done/tried this before, Copying the entire OS onto another drive, but this link #19 shows a dd method on it.

https://askubuntu.com/questions/7417...-another-drive

then as stated, boot a live UBS stick Linux os, chroot and install your grub, update then reboot. you can also switch cables or how ever it is done on a desktop now days to make it sda again. before chroot.


As far as that error, I do not know, I'd put a line of it in the search bar then see what "google" comes up with.

1 members found this post helpful.

Just to note, dd has NO confirmations, checks or are you sure - it's nickname DiskDestroyer is true. That said, it is powerful, handy and has purposes. A minor typo can render everything useless, this may not be the best case to try it out, your choice.


consider clonezilla, live boots from USB or old CDs. It's command line driven, so it's a bit advances, but plenty of guides, and I "think" it keeps things in tack for grub... maybe.


Not for disk, but partitions copying is possible with gparted live. The friendly GUI gparted you may already be comfortable with, copy and past from the menu.


But, yea, dd will get the job done, as with all these, the drive needs to be readable.

I would go even further - dd is the last tool you should be considering. Especially if the disk - and maybe filesystem(s) - are suspect. I would suggest you (royal plural) limit your dd usage to forensic situations, or copying iso to USB key.

A filesystems aware tool like rsync or cp will tell you if it is unable to read the data due to filesystem corruption. Maybe gparted too, although I haven't used it for copying like that.

As suggested, web search for your error message(they can be informative)
some rarity issues suggest cables, even so, you may still have issues.

alternatively, you could do a fresh install of your OS onto another drive, copy over your home, rsync, or cp, and get your customized config files as well.

I seen something on that error as MAYBE relaying to the kernel version, I did not look into it too far to completely verify that.

Before you go moving things around, I'd also suggest finding out what is causing that error on your hard drive, then see if there is a fix for it first.

Given the above, the easiest way is to clone sda to sdd using clonezilla:

https://clonezilla.org/clonezilla-live.php

It's faster than using straight dd for cloning and it will clone your bootloader, grub, to sdd in the process. Then you just need to shift your boot drive to sdd in your bios. Also, clonezilla will more gracefully deal with possible hard drive read issues from sda.

I also agree with djk44883's comments about checking your cabling to sda. Try swapping out the data cable if you have an extra one handy and also try using another power cable to the drive.