Re: [LUG] System down...

Ok, 512 MiB

Sectors 512 bytes

Disk label type dos

Identifier 0x00000000

would definitely be possible - although unusual - to have GRUB installed on the sda MBR, a blank or non-used sda1 partition and /boot included in /dev/sda2 but that would be pretty weird. Still technically bootable and functional but weird.

At install in January I got something about installing grub to removable media path.

Now the installer reports itself unable to install grub to sda or sda1 or sda2

When you mount /dev/sda does it have an empty /boot directory (this means that /boot should be sda1) or is there stuff in it (this would mean that /boot is included on the sda2 root)?

Mounting /sda2 gives a /boot with the usual sort of stuff in it.

Mounting sda1 shows a directory called EFI with BOOT in it and debian/grubx6464.efi

Ok, now we're getting somewhere - your system is definitely UEFI based rather than BIOS based then, and your sda has a GPT label instead of MBR. All the same, normally fdisk will complain thusly when listing a GPT disk:

"WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted."

Strange that your system doesn't seem to do that. What does this give you:

sudo parted /dev/sda print

You *might* somehow have ended up with a MBR label on a UEFI system, which isn't impossible but is undesirable. I'd expect to see something like this (from my windows GPT-labeled sdb):

ghost@failbot:~$ sudo parted /dev/sdb print
Model: ATA Corsair Force 3 (scsi)
Disk /dev/sdb: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start   End    Size   File system Name                          Flags
1      1049kB 316MB 315MB ntfs         Basic data partition          hidden, diag
2      316MB   420MB 105MB fat32        EFI system partition          boot
3      420MB   555MB 134MB               Microsoft reserved partition msftres
4      555MB   120GB 119GB ntfs         Basic data partition          msftdata

The "Partition Table:" line will be the interesting one. Your system sounds mostly ok otherwise - /dev/sda1 is the expected FAT-formatted EFI partition required for an UEFI system and in these cases, you'd expect /boot to be under the main root partition on /dev/sda2 which in your case, it is. So far so good. The bad news is that you've only got one kernel present for some reason, and it's obviously a borked one (either that or the initramfs). That's weird 'cos as you say, there should be at least one old kernel for fallback and Debian never nukes your oldkernel unless you specifically remove it, which you presumably didn't.

I'll wait for the parted results but in your position, I'd be preparing to boot a Debian rescue USB device, mount and bind the required partitions and chroot into it. Once in, installing/reinstalling the current kernel and GRUB, installing an older kernel as well to be safe and dist-upgrading the system just to be sure will fix it unless Debian have accidentally really borked something (incredibly unlikely given their legendary stability, and I'm sure the internets would be full of near identical errors from other people if they'd inadvertently shipped a broken critical kernel package in the last couple of days).

We're nearly at the bottom of this now. You'll be on GRUB2 by the way as a current Debian 8 user unless again, you've manually forced it out and downgraded. Which is awkward as the manual boot from GRUB2 is considerably more complex than good old GRUB but you shouldn't be needing it anyway.

Cheers