Check other drives and system logs first. If still unresolved, try formatting the boot drive or consulting a specialist.
Check other drives and system logs first. If still unresolved, try formatting the boot drive or consulting a specialist.
Encountered a peculiar problem I’m not confident about fixing. System: ASUS Z97-Deluxe, 32 GB RAM, i7-4790K, Samsung SSD as boot drive running Mint 19.3, with a second SSD paired with Windows 1 in DualBoot configuration. This configuration has operated smoothly for more than a year. Background: While preparing for a root partition expansion, I used a GParted Live CD to create backup copies (dding to an image file) of my root and home partitions, intending to reclaim space on the home drive. I didn’t actually perform any other actions except familiarizing myself with the Live CD. After removing the CD and restarting, I encountered issues—my system would freeze at the BIOS splash screen and refused to enter BIOS, preventing selection of the Live CD as boot device. Any attempt to troubleshoot failed. I opted to replace the drive entirely in case it was damaged and restore from backups. Current situation: I installed a new SSD (unformatted) and relocated the problematic drive to an external USB enclosure. A Mint Live CD is now on the DVD drive, and everything boots correctly from there. In GParted, the old drive appears intact—partitions are present and contents visible without issues. I’m thinking about running Boot Repair (default) to investigate further, though I’m unsure and have concerns. Two questions: 1) If I execute BootRepair using the original drive as /dev/sdc, will it reconfigure the system so that everything anticipates that drive as the boot source, and will it function properly when I return the drive to its original position? 2) If not, how should I (a) diagnose the root cause of the configuration error and (b) resolve it? I have the BootRepair report attached for reference. Any guidance would be extremely valuable. Thank you. Boot-Info_20200301_2300.txt
If you're unable to access BIOS, it's likely an issue with your motherboard rather than your storage device. A simple glitch during startup might have resolved itself by swapping drives or testing different SATA ports. Consider reinstalling your SSD to see if the same problem persists.
I previously inserted the old drive again and still faced the same issues. I'm a bit worried about testing another SATA connection, since my past experience with these ASUS boards suggests you often need to adjust several settings to have drives appear in the correct sequence. I'm not confident undoing it if it doesn't work. If I decide to try, I'll make sure the BIOS updates are clearly documented and won't cause further problems. I'll experiment now and let you know the outcome. In the meantime—could this be a feasible way forward?
1. Proceed with installing Mint on the new drive and verify it boots correctly while confirming your dual-boot setup is recognized.
2. If successful, consider using dd to wipe both root and home partitions from the old drive as a straightforward recovery method. This approach feels safer since I can always start fresh after reformatting.
I wouldn't suggest proceeding without first grasping the issue, though I think it doesn't really matter whether the new drive is empty. The main concern is that whatever is affecting this might be on the other drive, so using dd to transfer everything could just recreate the same issue on the new drive. You might also want to look at your old drive's SMART status to detect any odd readings.
Risks acknowledged, so I’ll probably perform a full Timeshift restore plus select components from the previous drive. In the worst scenario, I might lose time due to manual cleanup and unexpected issues, but without a solution to simply repair the old drive, restoring at least basic functionality is essential. SMART settings seem acceptable, though they include some older age values and a pre-fail indicator typical for an 18-month-old SSD—nothing alarming. Thanks for the time and suggestions.
The 510MiB partition is the boot area. With GParted it displays a 'boot' flag. The overwrite is evident since the used space is 4.66 MiB. When using GRUB, executing your commands would make GRUB believe the drive is SSD, indicating it's currently in an external enclosure—should be SATA if reinserted. Also, the current contents of sdd1 show EFI files alongside boot entries.
Oh no, don't execute those commands. I didn't notice the drive wasn't placed correctly on the machine. The system will rebuild your GRUB partition if needed. I'm not sure why your EFI partition has that AB50-6E49 format—it should just be EFI/BOOT (probably not changed before). I'd reinsert the drive into its proper spot, then run update-grub first. If that doesn't resolve the issue, use lsblk to check your SD card details and apply commands from the correct location.