Skip to main content
Unix & Linux

Return to Answer

added 30 characters in body
Source Link
underscore_d
underscore_d
  • 153
  • 13

This is high on Google, but all of the other answers seem only partially complete, at least for someone in my situation.

My computer has now twice (and more to come, knowing my luck) lost awareness that my Debian 8.2 installation exists. This might somehow be caused by a bug in my UEFI firmware and/or my use of a SATA slot that doesn't officially exist... or maybe some program is interfering with the partition, or the SSD itself is suspect... I dunno.

Anyway, the first time, I was so early in the process of getting everything set up - that I just reinstalled altogether. That fixed it. But it did feel a bit sledgehammerish.

This time around, that isn't an option. I've invested too much time in my configuration!

Today, my more diagnostic approach indicated that (at least this time) the cause was not - or not only - the firmware 'forgetting' the EFI partition existed - but also said partition had somehow gotten corrupted. Again, I can't explain this: it may be a shoddy firmware, unrelated filesystem horror, or something else entirely. I just have to deal with it, I guess.

The symptoms were:

  • My UEFI was suddenly totally unaware the debian EFI boot partition existed
  • The handy efibootmgr now reported the disk as ye olde BIOS type, not EFI
  • I couldn't just mount as /boot/efi since...
  • ...the trusty fsck complained about the boot sector being different from the intention/backup and a corrupted root FAT node (dat lingo) or something
  • Pretty much everything was stuffed, overall, is what I'm saying.

So, here's a full and reasoned list of what I did to fix it (for now?):

  • downloaded the exciting rEFIt @ http://refit.sourceforge.net/
  • used the quality Win32 Disk Imager a.k.a. "unamed sequel" @ http://sourceforge.net/projects/win32diskimager/ on a borrowed PC to write rEFIT to a USB pen drive
  • which brought the very welcome news that my / partition was still intact
  • booted said partition
  • reformatted the errant EFI partition as mkdosfs -F 32 /dev/sdXN - substitute your own KNAME - and avoid them in anything except transient runtime situations because they're asking for trouble if disks are shuffled
  • reinstalled GRUB to the newly formatted partition by grub-install /dev/sdXN
  • rebooted from my resurrected EFI partition - stuck in rescue mode because it was still filed in /etc/fstab by its old UUID, causing systemd to fall over on dependencies
  • rewrote /etc/fstab to refer to the /dev/disk/by-id/ata-EVILCORP-C3PO-partN pathtype paths for all disks - since (A) KNAME is risky and (B) UUIDs change if you suddenly have to reformat, like poor me...
  • magically returned to the adequacy of a normally bootable Debian. for now.

As they say, "until next time" - perhaps literally. Maybe this will help some other lost soul, frantically searching Google on some failing borrowed PC.

This is high on Google, but all of the other answers seem only partially complete, at least for someone in my situation.

My computer has now twice (and more to come, knowing my luck) lost awareness that my Debian 8.2 installation exists. This might somehow be caused by a bug in my UEFI firmware and/or my use of a SATA slot that doesn't officially exist... or maybe some program is interfering with the partition, or the SSD itself is suspect... I dunno.

Anyway, the first time, I was so early in the process of getting everything set up - that I just reinstalled altogether. That fixed it. But it did feel a bit sledgehammerish.

This time around, that isn't an option. I've invested too much time in my configuration!

Today, my more diagnostic approach indicated that (at least this time) the cause was not - or not only - the firmware 'forgetting' the EFI partition existed - but also said partition had somehow gotten corrupted. Again, I can't explain this: it may be a shoddy firmware, unrelated filesystem horror, or something else entirely. I just have to deal with it, I guess.

The symptoms were:

  • My UEFI was suddenly totally unaware the debian EFI boot partition existed
  • The handy efibootmgr now reported the disk as ye olde BIOS type, not EFI
  • I couldn't just mount as /boot/efi since...
  • ...the trusty fsck complained about the boot sector being different from the intention/backup and a corrupted root FAT node (dat lingo) or something
  • Pretty much everything was stuffed, overall, is what I'm saying.

So, here's a full and reasoned list of what I did to fix it (for now?):

  • downloaded the exciting rEFIt @ http://refit.sourceforge.net/
  • used the quality Win32 Disk Imager a.k.a. "unamed sequel" @ http://sourceforge.net/projects/win32diskimager/ on a borrowed PC to write rEFIT to a USB pen drive
  • which brought the very welcome news that my / partition was still intact
  • booted said partition
  • reformatted the errant EFI partition as mkdosfs -F 32 /dev/sdXN - substitute your own KNAME - and avoid them in anything except transient runtime situations because they're asking for trouble if disks are shuffled
  • reinstalled GRUB to the newly formatted partition by grub-install /dev/sdXN
  • rebooted from my resurrected EFI partition - stuck in rescue mode because it was still filed in /etc/fstab by its old UUID, causing systemd to fall over on dependencies
  • rewrote /etc/fstab to refer to the /dev/disk/by-id path for all disks - since (A) KNAME is risky and (B) UUIDs change if you suddenly have to reformat, like poor me...
  • magically returned to the adequacy of a normally bootable Debian. for now.

As they say, "until next time" - perhaps literally. Maybe this will help some other lost soul, frantically searching Google on some failing borrowed PC.

This is high on Google, but all of the other answers seem only partially complete, at least for someone in my situation.

My computer has now twice (and more to come, knowing my luck) lost awareness that my Debian 8.2 installation exists. This might somehow be caused by a bug in my UEFI firmware and/or my use of a SATA slot that doesn't officially exist... or maybe some program is interfering with the partition, or the SSD itself is suspect... I dunno.

Anyway, the first time, I was so early in the process of getting everything set up - that I just reinstalled altogether. That fixed it. But it did feel a bit sledgehammerish.

This time around, that isn't an option. I've invested too much time in my configuration!

Today, my more diagnostic approach indicated that (at least this time) the cause was not - or not only - the firmware 'forgetting' the EFI partition existed - but also said partition had somehow gotten corrupted. Again, I can't explain this: it may be a shoddy firmware, unrelated filesystem horror, or something else entirely. I just have to deal with it, I guess.

The symptoms were:

  • My UEFI was suddenly totally unaware the debian EFI boot partition existed
  • The handy efibootmgr now reported the disk as ye olde BIOS type, not EFI
  • I couldn't just mount as /boot/efi since...
  • ...the trusty fsck complained about the boot sector being different from the intention/backup and a corrupted root FAT node (dat lingo) or something
  • Pretty much everything was stuffed, overall, is what I'm saying.

So, here's a full and reasoned list of what I did to fix it (for now?):

  • downloaded the exciting rEFIt @ http://refit.sourceforge.net/
  • used the quality Win32 Disk Imager a.k.a. "unamed sequel" @ http://sourceforge.net/projects/win32diskimager/ on a borrowed PC to write rEFIT to a USB pen drive
  • which brought the very welcome news that my / partition was still intact
  • booted said partition
  • reformatted the errant EFI partition as mkdosfs -F 32 /dev/sdXN - substitute your own KNAME - and avoid them in anything except transient runtime situations because they're asking for trouble if disks are shuffled
  • reinstalled GRUB to the newly formatted partition by grub-install /dev/sdXN
  • rebooted from my resurrected EFI partition - stuck in rescue mode because it was still filed in /etc/fstab by its old UUID, causing systemd to fall over on dependencies
  • rewrote /etc/fstab to refer to the /dev/disk/by-id/ata-EVILCORP-C3PO-partN type paths for all disks - since (A) KNAME is risky and (B) UUIDs change if you suddenly have to reformat, like poor me...
  • magically returned to the adequacy of a normally bootable Debian. for now.

As they say, "until next time" - perhaps literally. Maybe this will help some other lost soul, frantically searching Google on some failing borrowed PC.

deleted 83 characters in body
Source Link
underscore_d
underscore_d
  • 153
  • 13

I was originally thinking of leaving this as a commentThis is high on mikeserv's answerGoogle, but then I saw the stateall of the comment sectionother answers seem only partially complete, and - yeahat least for someone in my situation.

IMy computer has now twice (and more to come, knowing my luck) lost awareness that my Debian 8.2 installation exists. This thinkmight this may be somehow be caused by a bug in my UEFI firmware, perhaps related to and/or my use of a SATA slot that doesn't officially exist... Either way, my computer has now twice (and many more to comeor maybe some program is interfering with the partition, knowing my luck) lost its awareness that my Debian 8or the SSD itself is suspect.2 installation exists.. I dunno.

TheAnyway, the first time, I was so early in the process of getting everything set up - that I just reinstalled altogether. That fixed it. But it did feel a bit sledgehammerish.

Today, my less crude/moremore diagnostic approach indicated that (at least in this casetime) the cause was less ofnot - or not only - the firmware just overlooking'forgetting' the EFI partition and more thatexisted - but also said partition washad somehow gotten corrupted. Again, I can't explain this, except maybe just: it may be a shoddy firmware that only barely supports U/EFI, unrelated filesystem horror, or something else entirely. I just have to deal with it, I guess.

  • My UEFI was suddenly totally unaware that the stock debian EFI boot partition existed
  • The handy efibootmgr now reported the disk as ye olde BIOS type, not EFI
  • I couldn't just mount as /boot/efi since...
  • ...the trusty fsck complained about the boot sector being different from the intention/backup and a corrupted root FAT node (dat lingo) or something
  • Pretty much everything was stuffed, overall, is what I'm saying.

Here'sSo, here's a full and reasoned list of what I did to fix it - for(for now, at least...?):

  • downloaded the qualityexciting rEFIt @ http://refit.sourceforge.net/
  • used the excitingquality Win32 Disk Imager a.k.a. "unamed sequel" @ http://sourceforge.net/projects/win32diskimager/ on a borrowed PC to write rEFIT to a USB pen drive
  • which brought the very welcome news that my main/ partition was still intact
  • booted said partition
  • reformatted the errant EFI boot partition as mkdosfs -F 32 /dev/sdXN - substitute your own KNAME - and avoid them in anything except transient runtime situations because they're asking for trouble if disks are shuffled
  • reinstalled GRUB to the newly formatted partition by grub-install /dev/sdXN
  • rebooted from my resurrected EFI partition - stuck in rescue mode because it was still filed in /etc/fstab by its old UUID, causing systemd to fall over on dependencies
  • rewrote /etc/fstab to refer to the /dev/disk/by-id path for all disks - since (A) KNAME is risky and (B) UUIDs change if you suddenly have to reformat, like poor me...
  • magically returned to the adequacy of a normally bootable Debian. for now.
  • come here to report the full details of this ideally unnecessary, very nerve-wracking, and ultimately dubiously rewarding procedure.

I was originally thinking of leaving this as a comment on mikeserv's answer, but then I saw the state of the comment section, and - yeah.

I think this may be somehow caused by a bug in my UEFI firmware, perhaps related to my use of a SATA slot that doesn't officially exist... Either way, my computer has now twice (and many more to come, knowing my luck) lost its awareness that my Debian 8.2 installation exists.

The first time, I was so early in the process of getting everything set up - that I just reinstalled altogether. That fixed it.

Today, my less crude/more diagnostic approach indicated that (at least in this case) the cause was less of the firmware just overlooking the EFI partition and more that said partition was somehow corrupted. I can't explain this, except maybe just a shoddy firmware that only barely supports U/EFI.

  • My UEFI was suddenly totally unaware that the stock debian EFI boot partition existed
  • The handy efibootmgr now reported the disk as ye olde BIOS type, not EFI
  • I couldn't just mount as /boot/efi since...
  • ...the trusty fsck complained about the boot sector being different from the intention/backup and a corrupted root FAT node (dat lingo) or something
  • Pretty much everything was stuffed, overall, is what I'm saying.

Here's what I did to fix it - for now, at least...

  • downloaded the quality rEFIt @ http://refit.sourceforge.net/
  • used the exciting Win32 Disk Imager a.k.a. "unamed sequel" @ http://sourceforge.net/projects/win32diskimager/ on a borrowed PC to write rEFIT to a USB pen drive
  • which brought the very welcome news that my main partition was still intact
  • booted said partition
  • reformatted the errant EFI boot partition as mkdosfs -F 32 /dev/sdXN - substitute your own KNAME - and avoid them in anything except transient runtime situations because they're asking for trouble if disks are shuffled
  • reinstalled GRUB to the newly formatted partition by grub-install /dev/sdXN
  • rebooted from my resurrected EFI partition - stuck in rescue mode because it was still filed in /etc/fstab by its old UUID, causing systemd to fall over on dependencies
  • rewrote /etc/fstab to refer to the /dev/disk/by-id path for all disks - since (A) KNAME is risky and (B) UUIDs change if you suddenly have to reformat, like poor me...
  • magically returned to the adequacy of a normally bootable Debian. for now.
  • come here to report the full details of this ideally unnecessary, very nerve-wracking, and ultimately dubiously rewarding procedure.

This is high on Google, but all of the other answers seem only partially complete, at least for someone in my situation.

My computer has now twice (and more to come, knowing my luck) lost awareness that my Debian 8.2 installation exists. This might somehow be caused by a bug in my UEFI firmware and/or my use of a SATA slot that doesn't officially exist... or maybe some program is interfering with the partition, or the SSD itself is suspect... I dunno.

Anyway, the first time, I was so early in the process of getting everything set up - that I just reinstalled altogether. That fixed it. But it did feel a bit sledgehammerish.

Today, my more diagnostic approach indicated that (at least this time) the cause was not - or not only - the firmware 'forgetting' the EFI partition existed - but also said partition had somehow gotten corrupted. Again, I can't explain this: it may be a shoddy firmware, unrelated filesystem horror, or something else entirely. I just have to deal with it, I guess.

  • My UEFI was suddenly totally unaware the debian EFI boot partition existed
  • The handy efibootmgr now reported the disk as ye olde BIOS type, not EFI
  • I couldn't just mount as /boot/efi since...
  • ...the trusty fsck complained about the boot sector being different from the intention/backup and a corrupted root FAT node (dat lingo) or something
  • Pretty much everything was stuffed, overall, is what I'm saying.

So, here's a full and reasoned list of what I did to fix it (for now?):

  • downloaded the exciting rEFIt @ http://refit.sourceforge.net/
  • used the quality Win32 Disk Imager a.k.a. "unamed sequel" @ http://sourceforge.net/projects/win32diskimager/ on a borrowed PC to write rEFIT to a USB pen drive
  • which brought the very welcome news that my / partition was still intact
  • booted said partition
  • reformatted the errant EFI partition as mkdosfs -F 32 /dev/sdXN - substitute your own KNAME - and avoid them in anything except transient runtime situations because they're asking for trouble if disks are shuffled
  • reinstalled GRUB to the newly formatted partition by grub-install /dev/sdXN
  • rebooted from my resurrected EFI partition - stuck in rescue mode because it was still filed in /etc/fstab by its old UUID, causing systemd to fall over on dependencies
  • rewrote /etc/fstab to refer to the /dev/disk/by-id path for all disks - since (A) KNAME is risky and (B) UUIDs change if you suddenly have to reformat, like poor me...
  • magically returned to the adequacy of a normally bootable Debian. for now.
Source Link
underscore_d
underscore_d
  • 153
  • 13

I was originally thinking of leaving this as a comment on mikeserv's answer, but then I saw the state of the comment section, and - yeah.

I think this may be somehow caused by a bug in my UEFI firmware, perhaps related to my use of a SATA slot that doesn't officially exist... Either way, my computer has now twice (and many more to come, knowing my luck) lost its awareness that my Debian 8.2 installation exists.

The first time, I was so early in the process of getting everything set up - that I just reinstalled altogether. That fixed it.

This time around, that isn't an option. I've invested too much time in my configuration!

Today, my less crude/more diagnostic approach indicated that (at least in this case) the cause was less of the firmware just overlooking the EFI partition and more that said partition was somehow corrupted. I can't explain this, except maybe just a shoddy firmware that only barely supports U/EFI.

The symptoms were:

  • My UEFI was suddenly totally unaware that the stock debian EFI boot partition existed
  • The handy efibootmgr now reported the disk as ye olde BIOS type, not EFI
  • I couldn't just mount as /boot/efi since...
  • ...the trusty fsck complained about the boot sector being different from the intention/backup and a corrupted root FAT node (dat lingo) or something
  • Pretty much everything was stuffed, overall, is what I'm saying.

Here's what I did to fix it - for now, at least...

  • downloaded the quality rEFIt @ http://refit.sourceforge.net/
  • used the exciting Win32 Disk Imager a.k.a. "unamed sequel" @ http://sourceforge.net/projects/win32diskimager/ on a borrowed PC to write rEFIT to a USB pen drive
  • which brought the very welcome news that my main partition was still intact
  • booted said partition
  • reformatted the errant EFI boot partition as mkdosfs -F 32 /dev/sdXN - substitute your own KNAME - and avoid them in anything except transient runtime situations because they're asking for trouble if disks are shuffled
  • reinstalled GRUB to the newly formatted partition by grub-install /dev/sdXN
  • rebooted from my resurrected EFI partition - stuck in rescue mode because it was still filed in /etc/fstab by its old UUID, causing systemd to fall over on dependencies
  • rewrote /etc/fstab to refer to the /dev/disk/by-id path for all disks - since (A) KNAME is risky and (B) UUIDs change if you suddenly have to reformat, like poor me...
  • magically returned to the adequacy of a normally bootable Debian. for now.
  • come here to report the full details of this ideally unnecessary, very nerve-wracking, and ultimately dubiously rewarding procedure.

As they say, "until next time" - perhaps literally. Maybe this will help some other lost soul, frantically searching Google on some failing borrowed PC.