D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] System down...

 

/Deb/sda
ATA Kingston 60GBytes

Partition table gpt

Flags

1. 538 MBytes. Fat32  .......ÂBoot, esp

2. 59.5 GBytes. Ext4.  ÂRootÂ




On Thursday, 26 May 2016, mr meowski <mr.meowski@xxxxxxxx> wrote:
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
Â

Â



--
Adrian Midgley  http://defoam.net/ Âhttp://photo.defoam.net/
-- 
The Mailing List for the Devon & Cornwall LUG
https://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq