6

I am triple booting Ubuntu, Debian, and Fedora. When I installed Fedora from a liveCD I got excited and kept hitting next, not realizing I was not installing GPT, but rather LVM.

After doing this I cannot boot from a hard disk. The EFI menu doesn't even show my hard drive as a boot option (although it detects it in hardware).

I have a work-around currently, which is odd in how it works, I use a liveboot USB (Yumi) and choose to run Linux from hard drive, and I can choose between the distros I have on my computer. However I need this USB to boot into a distribution.

I am unsure exactly how to restore my system.

My computer came with Ubuntu installed, ASUS XC200 (netbook). I called Asus tech support, they wanted to re-image.. I will not give up so easily.

My /dev/sda1 (fat32, with boot flag) has an EFI directory on it for Ubuntu (assuming Ubuntu was loading GRUB> chainloading Debian).

How do I start to fix this? And what information do people need?

(I have no CD/DVD Player)

Note with efibootmgr:

Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
Try 'modprobe efivars' as root.

When I run modprobe there is nothing with efivars.

Update/Things I tried so far:

I tried the answers posted below [1], [2] currently, good research, and in most cases I believe they would work. They did not however in my situation.

Current Tools

Disks--

  • Lost extra flashdrives with Kali
  • & Debian
  • & Ubuntu 14.04
  • still have Yumi with Ubuntu 12.04.

Steps taken recently (after following answers):

  • Ran Live Ubuntu
  • Wiped /dev/sda except the fat partition (GPT/ESP)
  • Tried to do install of Ubuntu, didn't work problem with grub and EFI on my GPT partition
  • Used fsck just in case (fine)
  • Used parted/gparted to wipe all then make GPT and other partitions(set boot flag on ESP)
  • Tried Install again (didn't work same error)
  • Partitions looked funny, (missing space)... Scratched Head
  • Wiped partitions/Made partition for LiveUSB onto Harddrive
  • Used dd to write LiveUSB to /dev/sda4 (believe this was number)
  • This booted, but needed my USB to be in place so was useless
  • Tried to use gfdisk, made me reboot lost session
  • Split my LiveUSB
  • Downloaded Arch .iso, and dd'd onto 2nd USB partition (LiveUSB)
  • Kept Ubuntu LiveUSB session up, went through partial install (up to chroot of Arch while in live session)
  • Had problems with things working right
  • Ran Arch Live, went through install (zapping and initial creation of partitions worked better than on parted/gparted)
  • Used directions to dosyslinux (from within Arch Install Guide)
  • Basically rewrote all my efi to brand new
  • Running great on Arch
  • Unsure whether/how to answer my own question
Community
  • 1
No Time
  • 1,167
  • 2
    Note that efibootmgr will only work if the system has been booted in EFI mode. Make sure your liveUSB supports EFI booting (it should have an EFI/boot/bootx64.efi file) and that you're actually booting it that way, not in legacy BIOS emulation mode. – Wyzard Nov 22 '14 at 22:08
  • @Wyzard Yeah I do not have an option to boot legacy, at this point I feel like this is fixed. I am just unsure as to how to answer my own question. I restored my EFI by doing a new one through a new Arch install. – No Time Nov 23 '14 at 04:50

6 Answers6

10

Forget grub entirely - it is nothing but a distraction. It isn't even a boot-loader anymore; on EFI systems the bootloader is built-in to the firmware. grub is just a boot-manager in that context - and almost definitely entirely redundant. What's more - it is probably the grub install that broke everything in the first place.

These are the things you need:

  1. A FAT-formatted GPT partition of type ef00.
  2. A UEFI-compatible system kernel located on that partition (such as the linux kernel).
  3. The path to that system kernel saved to a UEFI environment variable (commonly Boot0000-{UUID}, but this also depends on the value of BootOrder-{UUID}).

Strictly speaking, that is all. You can achieve the above setup with nothing more than gdisk and the efibootmgr command-line tools.

Pragmatically, a boot-manager does make sense - but grub is the most complicated of all of those available. As is elsewhere recommended, rEFInd is probably the best of the bunch.

I have written a step-by-step tutorial before on how to partition, format, and setup a rEFInd-enabled EFI system partition before here. Here also is another answer on this subject, in which you might find some further explanation about the assertions I make here.

Community
  • 1
mikeserv
  • 58,310
  • 1
    I ended up installing arch and using syslinux, so everything is pretty tidy on OS init. I just am not sure how to bring a step-by-step, how I did this except pointing to the Arch wiki. The main problem(s) seemed to be 1. I didn't know enough about the subject 2. My original EFI shell was/is gone 3. I had a complicated chainload all on grub, which was overwritten by Fedora LiveUSB (they don't like EFI I guess). I had just early that day said how I loved Debian because of how stable it was.. I guess I just had to break my system. Great links, I love your posts they always are informative. – No Time Nov 24 '14 at 02:46
  • @NoTime - the shell, at least, is easily fixed. You can just run it from your boot manager - or else you can create a separate boot-entry for it in the firmware bootloader proper. It's another UEFI-compatible kernel - and is freely downloadable. There is a link in the Arch wiki - but also, because the boot-loader is actually in the firmware, you can swap boot managers with ease once you get the hang of it. The shell is provided with the rEFInd cd image as well. Maybe give it a shot - also, install efibootmanager - I think its man page even covers a shell entry by example. – mikeserv Nov 24 '14 at 04:11
  • I haven't tried rEFInd yet. I might for my old iMac (1st intel, no longer supported). Right now I can't to mess too much with this one; I have to keep it up and running. When I was using efibootmanager(from my 3 OS's, and live) I kept getting problems loading my .efi files I don't know if they were corrupted or what. My actual EFI/"BIOS" screen is pretty basic, and I believe that whatever Fedora did messed with it, because I can't run the shell from in there (or add boot option where I would point to fsx:\foo\bar.efi)I used to be able to do tab autocompletes, but not sure now. I'm ok now tho – No Time Nov 24 '14 at 05:46
  • Grub is definitely a boot loader since it can load non EFI kernel images from filesystems the EFI firmware does not understand. It just also happens to provide much the same type of functionality as a boot manager in that it lets you choose different systems to boot and ways in which to boot them. A true EFI boot manager only allows you to choose which boot loader installed on your EFI system partition you want to load. Trying to bypass grub means you have to copy your kernel to the EFI system partition, and iirc, means you can't use an initrd. This will cause all sorts of pain. – psusi Nov 24 '14 at 20:12
  • @psusi - most of what you say is incorrect. A boot-manager passes the path to an EFI-executable kernel to the EFI firmware for execution. If it needs to, it can load EFI-filesystem drivers before doing so - many of these are freely available (to include the majority of grub's own filesystem drivers) - and an initramfs argument is no issue either. It is true though that in some cases grub might still be installed as a chainloading boot-loader - but that only makes it more redundant. Please read the links in the answer before commenting further. – mikeserv Nov 25 '14 at 02:10
  • While a boot manager can load EFI filesystem drivers, grub does not do so. It directly interprets the filesystem itself, locates the kernel, and initramfs, and loads and jumps to them, never returning to the EFI firmware. That is why it is not technically an EFI boot manager. It could be made to be, but it currently isn't. Also the initramfs is not just an argument; it is a separate module that is loaded in its own right ( by grub ). Also while you can build linux to be an EFI executable, you don't have to and grub is still capable of loading conventional vmlinux or multiboot images. – psusi Nov 25 '14 at 02:47
  • I had to do EFI. I don't have any other options my firmware doesn't allow anything but EFI (no legacy). It was using grub_x64.efi (or something to that effect) to chain load all of my OS's. It is much simpler now, I just boot to Arch (and option was added on actual EFI screen, versus as a boot option). Can I just keep calling it BIOS, because the EFI name for files, type of handler for booting, and the EFI "BIOS" portion name seems to get confusing. – No Time Nov 25 '14 at 06:47
  • @psusi - everything you say speaks of redundancy. It is my impression that grub's EFI version does not chainload and instead refers back to the EFI - but perhaps I am wrong. But to layer in such a complicated and wholly unnecessary loader between the firmware and a kernel it can execute is nonsense. Yes - the EFI stub loader is a build time option - a default one - along w/ everything else. I did not suggest grub loaded EFI filesystem drivers - but that grub's drivers are redundant. And, I'm sorry, but the initramfs is a kernel parameter no matter the linux loader. – mikeserv Nov 25 '14 at 08:14
  • @NoTime - The EFI BIOS thing is confusing. Though the world is slow to realize it - you got the longer end of the stick this time. BIOS - the old basic in/out - was a 16-bit stack built on assembly. It didn't - couldn't - load anything - hence grub and its ilk were created as go-betweens. An EFI firmware is both easier to manage and less likely to require management. The heart of the issue is that the boot process is so little understood - hopefully that gets better in time - and that devs are slow to adapt - that definitely must eventually. EFI and BIOS are two distinct animals though – mikeserv Nov 25 '14 at 08:26
  • grub's filesystem drivers are not redundant since without them you wouldn't have access to anything but the ESP. You are also wrong about the initramfs. It is not a parameter passed to the kernel, but a file that is loaded by grub, hence why it is given to grub as its own command instead of a kernel parameter. It has to be loaded by the boot loader since it usually contains the drivers the kernel needs to access the disk. – psusi Nov 25 '14 at 14:33
  • @psusi - I asked you please to read the links in the answer before commenting further but it is obvious you have not. You are completely mistaken here - the filesystem drivers are not bound to the ESP - and the initramfs image is a file the kernel loads - no loader does that. If you understood how it worked you would understand what a silly misconception that really is. The initramfs image is a CPIO image that the kernel unpacks into its own / - the only real / - in a RAM disk and it obviously cannot do so without first being executed. It is a parameter - nothing more. – mikeserv Nov 25 '14 at 14:53
  • You posted one link and it was about loading grub's filesystem drivers as EFI drivers. If you are going to do that, then those are redundant, not the other way around. Since virtually nobody dose this, EFI can't access anything other than fat32. The kernel does not load the initramfs, since it can't access the disk without the initramfs. If it could, you wouldn't need an initramfs in the first place. The kernel does unpack the image, but it is already in ram when grub jumps to the kernel. Trust me, I have read the code. – psusi Nov 25 '14 at 15:04
  • @psusi - there are two links in the answer - you're referring to a link in a comment. Regarding redundancy - if the firmware can load the kernel, and if the firmware can do so using the same filesystem drivers as those that come with a secondary kernel loader, then which is redundant: is it the firmware that loads the kernel straight-off or is it the secondary loader that the firmware calls to then load the kernel? And you're only partly right about initramfs - it is mapped to memory alongside the kernel - in the same way any loader does it. But that is all - the kernel does all the rest. – mikeserv Nov 25 '14 at 15:07
  • I think I figured out why you are confused. When they added the ability for the kernel to be built as a self loading EFI image, they gave it the ability to be passed the initramfs path as a command line argument and load it itself, since otherwise it would not be possible to have an initramfs without the boot loader. This however, is fundamentally pointless since if the kernel is capable of loading its own initramfs, you don't need one. Conversely, if you really need one, it is because the kernel can't access the disk without it, so you are back to having to use grub. – psusi Nov 25 '14 at 15:08
  • @psusi - this is again incorrect. The point of the initramfs - the reason it is a requirement - is to separate the kernel devs from having to handle the countless root configurations available. The initramfs is rootfs because it is easier for them. I am not confused - I boot several computers every day without grub directly from firmware. Again, this is detailed in the links. I'm fairly certain you're confused - you do not understand - as most do not - how the boot process works and why it does. grub is an anachronism - it was to deved to serve a purpose that is no longer relevant. – mikeserv Nov 25 '14 at 15:13
  • No, the reason it exists is to support complex configs like raid and lvm, which require a good deal of complex logic to set up and mount. Logic that the kernel devs did NOT want in the kernel itself. If you instead just have a plain regular partition on a regular disk, you can build all the drivers required to access your rootfs into the kernel, and then there is no reason to even bother having an initramfs in the first place -- you just go back to telling the kernel what device to mount as root= and it can do so without the initramfs just like it used to before initramfs was around. – psusi Nov 25 '14 at 15:19
  • @psusi - we have been over this before. You cannot do without initramfs - the image and the filesystem are separate things. The image is unpacked into the filesystem - which is always already there. The image is not even a true image - merely an archive - just a CPIO of / - unpack one and see for yourself. You can go without the image - but it matters not - the kernel always mounts initramfs first - it is rootfs. Regardless this doesn't support grub - any loader can map an initramfs and pass its pointers to the kernel - to include EFI. That is what happens here at every reboot. – mikeserv Nov 25 '14 at 15:24
  • If a tree falls in the woods and nobody is there to hear it, does it make a sound? That is the kind of hair splitting useless argument you are making by mentioning that the rootfs is still there even if you didn't load an initramfs. We're only talking about loading an image or not. EFI can not load and pass the kernel the initramfs image, which is why, as you pointed out, you pass its path as a command line argument to the kernel. If the kernel can't access that path, say, because it is on lvm, then it can't load it and so you can't boot. Just try your setup with lvm. It won't work. – psusi Nov 25 '14 at 16:30
  • @psusi - yes it can - I just told you, I do it every day... or, well, every reboot. You are absolutely incorrect - it is done all of the time - Will you please cease commenting until you have read the links? I have just told you I do it - my main machine boots to a btrfs-raid atop a bcache array of 2 3tb-WDs cached to an SSD. It does this in initramfs - loaded by EFI. There is no grub - I use rEFInd but only because I like the menu. I could also boot the same array without a manager at all - I would just write an EFI script. Stop being ridiculous - you are wrong. – mikeserv Nov 25 '14 at 17:01
  • I've read the bloody links already. You clearly are putting the kernel and initramfs on the EFI system partition in them, rather than loading them from the regular filesystem, which the efi firmware does not have access to. – psusi Nov 26 '14 at 02:18
  • @psusi - yes, I am. I do not have to - but it is very convenient. It is far more convenient to have a separate partition to which I can read and write at my leisure and mount anywhere I please than it is to have a block of assembly written raw to the first block of my harddisk to achieve the same purpose. I choose not to use the filesystem drivers - I dislike complication - but there is nothing stopping me from doing so. And with EFI I wouldn't even need that to do the raw block of assembly, either. – mikeserv Nov 26 '14 at 04:14
  • 1
    @mikeserv It appears I should have asked about intraramfs, and EFI... possibly the boot process as well. There is a lot of going back and forth here. And it appears you 2 had this argument before http://unix.stackexchange.com/questions/122100/why-do-i-need-initramfs#comment193542_122100 :) – No Time Nov 26 '14 at 07:16
  • There isn't an EFI bcache driver, so you do have to. My real point here has been that having to manually copy your kernel and initrd to the ESP and update refit each time your distribution updates the kernel, or go through all the trouble of setting up refit plus the efi filesystem drivers is a lot more work than just sticking with grub, for little to no gain, so it is inappropriate to claim that grub is "nothing but a distraction" and "not even a boot loader" ( the latter of which is false ) and suggest everyone not use it, even if you can manage to hack your system into not using it. – psusi Nov 26 '14 at 16:48
  • @psusi - I do not need an EFI bcache driver - why would I need such a thing? I do not manually copy anything, I do not update refind. I set a simple rule in my /etc/fstab at install time and from that point on it is completely hands-off - 100% automatic. In my config - which is not the way it must be done - the kernel bind mounts a folder on my esp to /boot - and that's it, nothing more. From there on its operation is completely transparent for all updates - and far more robust than the symlink alternatives most distros use to handle grub. Mine never breaks - it is atomic. – mikeserv Nov 26 '14 at 17:09
  • @psusi - also, a rEFInd install is a far more simple thing than is a grub install. w/ rEFInd you can just unzip a folder and copy it to your ESP. w/ grub you have to ensure that your partition table will support its raw write to the start of your disk. If a rEFInd install fails you just try again - you just once again copy the files. If a grub install fails you must attempt to rescue the filesystem which it just destroyed by remapping your partition table. The difference is fairly stark. – mikeserv Nov 26 '14 at 17:13
  • sigh... you would need a bcache driver to access your root fs instead of storing the kernel on the esp. And when you install a new kernel, don't you then need to edit the refind config to point to that new kernel? Also what distro is using symlinks with grub? Symlinks were used in the 90s with lilo, not with grub. You also seem to not understand that grub comes in an EFI flavor that gets installed as a regular file on the esp just like refind and instead you keep comparing it to bios based grub. – psusi Nov 26 '14 at 18:50
  • @psusi - no, you don't need to edit the refind config. It is automatic - by default it searches every disk (on nearly any kind of filesystem) for linux kernels in the usual place - (/boot) - or where you specify in its refind.conf. I confine its search to the esp - where I keep all of my installation's boot folders - and removable boot devices, if any. I know that grub can be compiled that way - I've done it (it's not easy, by the way) - but in that form doesn't it behave as a manager? And if not - why not? It's already on a readable disk - what is the point otherwise? – mikeserv Nov 26 '14 at 18:56
  • oh - and it would be madness not to have at least one accessible filesystem outside the bounds of an lvm array. Still though, bcache locates its superblock after most any other kind of filesystem - and its constituent disks are still readable by its component filesystems if necessary - though old cached data is always lost in that case if any change is made to its components in the meanwhile. And EFI can read btrfs. – mikeserv Nov 26 '14 at 19:01
  • @psusi - at least Redhat symlinks in /boot - but I thought it was the common behavior to do this - especially on efi systems where the /boot/efi/grub/... folder contains a bunch on indirections to and from /etc/grub and/or /boot/grub/... Is this not how the Debians do it? At the least the entire grub -mkconfig thing for every update which involves something along the lines of freshly evaling some chain of shell-scripts is completely confusing and ridiculously complicated. There is no point in that nonsense anymore. – mikeserv Nov 26 '14 at 19:16
4

When I reinstalled my ESP and grub I used rEFInd: http://sourceforge.net/projects/refind/files/?source=navbar (the flashdrive variant) to boot into my distribution.

After booting mount your ESP into /boot/efi

mount -t vfat /dev/yourESPdev /boot/efi

Then you should be able to reinstall grub with this EFI directory.

grub-install --efi-directory=/boot/efi

This should restore grub. If your ESP was deleted and you had to recreate it, then you will have to update it's UUID in /etc/fstab. Use blkid to list the UUIDs of your devices. After updating the UUID of your device in /etc/fstab, run update-grub.

You will probably also have to create a new efi entry for grub. Use something along the lines of:

efibootmgr -c -d /dev/yourHD -p ESP_PartionNumber -L "Boot Title" -l '\\EFI\\DIST\\grubx64.efi' -u "root=/dev/yourRootFS"

Where ESP_PartitionNumber is the number of your ESP on the hard drive (/dev/sda1 would be 1), and DIST is a folder whose name is specific to your distro unless you created it. The folder is in /boot/efi/EFI. Boot Title is simply the title you want for your EFI entry.

It has been some time since I reinstalled my ESP, so I can't test any of these commands again. You may need more parameters for some, but I am pretty sure this was all.

Josh
  • 41
  • 2
1

  • Depending on the distribution you boot from:

    • For Ubuntu/Debian:

      apt-get install --reinstall grub-efi-amd64

or alternatively: 
apt-get install --reinstall grub-efi
update-grub

should the above give you a grub, but not a bootable one

    • For Fedora (up to 16, may work for others):

      yum reinstall grub-efi

      In the following command, you have to replace sdX with the device which has the EFI partition you want to boot from. In --part Y you have to replace the Y with the number of the EFI partition (as in /dev/sdXY).

      efibootmgr -c --disk /dev/sdX --part Y
efibootmgr -v # verify a new record called Linux is there
      • Now type Ctrl+D to exit chroot, unmount everything and reboot:

      for i in /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done sudo umount /mnt/boot/efi #please do this. corrupted efi partitions are not nice sudo umount /mnt sudo reboot

You may need to adapt this to your needs

source: su

Community
  • 1
switch87
  • 926
  • The beginning of answer you did, did not include making the /mnt chroot. I am looking at the answer on su, I am having trouble chrooting from the commands in that answer. This may be dated.. or maybe I need to run everything from fedora, because some of these things are not on debian. Also nothing is showing up when I do modprobe efivars – No Time Nov 18 '14 at 03:41
  • why do you want to use chroot to solve this? Important is however that your boot from a uefi usb-drive. – switch87 Nov 18 '14 at 09:23
  • Also if you can do it in fedora it should indeed work, you do not have to install your bootloader 3 times, just 1 time. – switch87 Nov 18 '14 at 09:41
  • I am getting problems (running from an Ubuntu Live-USB) http://paste.ubuntu.com/9085912/. In the answer you linked from, it required that you chroot (and mount to different area) prior to doing the commands you posted. – No Time Nov 19 '14 at 03:59
  • you chould just use your live-boot usb to boot into your fedora installation and install grub2, you do not have to chroot or boot into debian or ubuntu, you have to install grub just 1 time and do not do the things from the link if I did not copy it! mor information for configuring grub2 after reboot and debian or ubuntu would not be included in the boot-menu you can find here: https://fedoraproject.org/wiki/GRUB_2?rd=Grub2 – switch87 Nov 19 '14 at 22:44
  • This is result from following commands you had. I do not have any EFI files, so I can't just add to current EFI/ESP. I was saying that in the answer you linked it had chroot, and I was wondering if I should do that prior, but as I am looking at things it appears my EFI part was formatted or EFI boot files were deleted, and using a live boot will just append to the folder, when it appears I need to get a brand new *.efi file – No Time Nov 20 '14 at 01:59
  • My booting was only working by using the USB efi (from liveboot Yumi boot loader) selecting an option from that boot loader to run from the hardrive. Grub and other boot loaders were not working as my hardware/firmware efi files disappeared, making grub unable to add itself as an entry in the efi files – No Time Nov 21 '14 at 19:42
1

When unsure with things like partitioning, try to salvage what you can and wipe the disk (or at least LVM/GPT metadata, at least some of that isn't just in the beginning of the block device IIRC). This well could save you some hair down the road (been there last century with BIOS, PTBL and MBR having three distinct ideas of what the drive geometry is).

If you really could roll back the situation, you wouldn't be asking here (don't take as offence, I've shot myself in a foot too with that book on "Next").

If you want to mess with it anyways, start with a rescue image (shameless plug: I'd use this one) and have a look at

  • efibootmgr
  • blkid /dev/sdX

You might find Rod's books on EFI useful too.

Good luck.

Michael Shigorin
  • 1,051
  • What appears to be the problem for me is everything is failing now. I have done repair-boot, I have done fresh install (fails once it gets to grub install), did the other answer here (and the one from the su link). Just is odd, going to try your suggestions (see note above for efibootmgr -- gives error). I'm going to run through the EFI guide as well. – No Time Nov 19 '14 at 04:15
  • Yes, if you can not boot into 1 of your installed systems, but you can. You only have to install a (u)efi compatible grub, like I posted. – switch87 Nov 19 '14 at 12:53
0

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.

underscore_d
  • 153
0

This is a small but important note:

Most of the times when you get Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables. is due that you didn't boot using UEFI. This variables only show when the running system was boot with UEFI, using the CSM they are not enabled... so this is a chicken/egg problem, for you to setup UEFI, you need to boot using UEFI! :)

So try to setup as much as you can then grab the rEFInd usb or CD image and use it to boot the system the first time. After this to finish the setup without any problem.

higuita
  • 585