0

I had windows and debian installed alongside on the same SSD and working seamlessly. During my experiments I played with Windows installation from USB and (of course) it ended up with grub rescue mode.

I'm not certain, but it is possible that in frenzy I did:

grub-install /dev/sda6 # (where /dev/sda6 is my root linux partition)

because now, after some playing in terminal:

update-grub 

detects only Windows parition which resides on /dev/sda1. During my search I found this page and I would like to ask whether it is safe to zero out MBR as it is described in the link. I mean, (since I don't know when was the linked post written) are those numbers from commands:

dd if=/dev/zero of=/dev/hda bs=446 count=1
# and
dd if=/dev/zero of=/dev/hda1 bs=512 count=1

still correct? I wouldn't like to make things worse than they already are...

  • You have a really old example. They changed from hda to sda years ago. And all those only apply if BIOS/MBR not newer UEFI install. Lets see details, use ppa version with your live installer (2nd option) or any working install, not older Boot-Repair ISO: Please copy & paste the pastebin link to the Boot-info summary report ( do not post report), do not run the auto fix till reviewed. help.ubuntu.com/community/Boot-Repair & sourceforge.net/p/boot-repair/home/Home – oldfred Jul 28 at 23:30
  • Thanks. I wasn't aware of existance of Boot-Repair. Here's my report: paste.ubuntu.com/p/Zqjcv65gs9 I'm waiting for your suggestions... – martinoidar Jul 29 at 12:11
  • Best to never erase a PBR - partition boot sector. And Windows has essential boot info in its PBR or sda1. So do not erase that. You can just run the suggested fix to see if then grub works. – oldfred Jul 29 at 12:21
  • OK. I ran the fix but it didn't help. Here's the report: paste.ubuntu.com/p/md95yRDT2x I guess the crucial lines are those ones: "=================== linux-generic purge cancelled Please enable a repository containing the [linux-generic] packages in the software sources of Debian GNU/Linux 10 (buster) (sda6). Then try again." – martinoidar Jul 29 at 12:30
  • Not familiar with Debian updates. But it looks like grub updated. Perhaps Boot-Repair is looking for the Ubuntu kernel linux-generic and that is not how Debian names kernel? – oldfred Jul 29 at 14:12
0

In the end it turned out that the kernel was missing. So I had to reinstall it. What I did was:

  • booting via live usb and in the command line:

    mkdir /recovery
    mount -t ext4 /dev/sda6 /recovery
    mount -o bind /dev /recovery/dev
    mount -o bind /sys /recovery/sys
    mount -t proc none /recovery/proc
    
    chroot /recovery /bin/bash
    apt-get remove linux-image-4.19.0-9-amd64
    

At this point I had some problems because I had no internet connection in chrooted system and I couldn't do "apt-get install linux-image-4.19.0-9-amd64" so I downloaded manually linux-image-4.19.0-9-amd64.deb in live usb and then mounted it inside /recovery directory.

dpkg -i /recovery/download/linux-image-4.19.0-9-amd64.deb
update-grub

Then the grub menu was fixed and I could easily boot into the system, but it occured that /home partition was gone from fstab I could get into user account, so once again I booted via live usb and added appropriate line in fstab.

Now, system works fine apart from the fact that starting process takes a bit longer than it used to, but I can live with that.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.