sheesh.  no error from grub-install, but it still boots into windows.

curious that i find these in /boot:
vmlinux-4.13.0-28-generic
vmlinux-4.13.0-36-generic
vmlinux-4.13.0-36-generic.efi.signed
vmlinux-4.13.0-37-generic
vmlinux-4.13.0-37-generic.efi.signed
vmlinux-4.13.0-38-generic
vmlinux-4.13.0-38-generic.efi.signed
vmlinux-4.13.0-39-generic
vmlinux-4.13.0-39-generic.efi.signed
vmlinux-4.13.0-41-generic
vmlinux-4.13.0-41-generic.efi.signed
vmlinux-4.13.0-43-generic
vmlinux-4.13.0-43-generic.efi.signed
vmlinux-4.13.0-45-generic
vmlinux-4.13.0-45-generic.efi.signed
vmlinux-4.15.0-29-generic
vmlinux-4.15.0-30-generic
vmlinux-4.15.0-32-generic
,,,
vmlinux-4.15.0-62-generic
vmlinux-4.15.0-64-generic
vmlinux-4.15.0-65-generic

curious that *.efi.signed doesn't exist for -28-, does for -36- thru -45-,
but then no others.  and curious that /boot/efi is empty.   but,
/boot/grub/x86_64-efi exists and is populated, and no other /boot/grub/*
directory exists, so it looks like it was installed as efi.  sort of.  i
don't have other EFI installations handy to inspect.  do y'all?  this is
xenial.  how does it look on yours?

well this is what i did, in a terminal in boot-repair-disk:
mkdir /mnt/boot-sav/sda7/mnt/a1
mount --bind /mnt/boot-sav/sd{,a7/mnt/}a1
mount -oro -tproc {,/mnt/boot-sav/sda7}/proc
mount -oro --bind {,/mnt/boot-sav/sda7}/sys
mount -oro,rbind {,/mnt/boot-sav/sda7}/dev
mount -oro,bind {,/mnt/boot-sav/sda7}/lib/modules
chroot /mnt/boot-sav/sda7
grub-install --uefi-secure-boot --target=x86_64-efi --no-nvram
--efi-directory=/mnt/a1 /dev/sda

it said something like:
Installing for x86_64-efi platform.
Installation finished. No error reported.

but it still boots into windows.  any ideas?


On Wed, Nov 13, 2019 at 7:09 PM gregrwm <tclug1 at whitleymott.net> wrote:

> thank you for the replies.  surprise, his linux partitions are still
> there.  but we're not out of the woods yet.  tried chroot and
> grub-install, got "error: /usr/lib/grub/i386-pc/modinfo.sh doesn't
> exist."  then downloaded boot-repair-disk and added it to my thumb drive
> of handy iso's.  it quickly identified a sensible repair, but failed to
> perform it, saying "The current session is in Legacy mode. Please reboot
> the computer, and use this software in an EFI session. This will activate
> the function. For example, use a live-USB of Boot-Repair-Disk-64bit, after
> making sure your BIOS is set up to boot USB in EFI mode."
>
> so i'm guessing that means my friend's disc was setup as an EFI boot,
> meanwhile my handy thumb drive didn't boot in EFI mode, either for the live
> ubuntu i used to chroot and try grub-install, nor for the boot-repair-disk
> iso, and i'm guessing the bios in it's unquestionable wisdom is entirely
> inflexible, like if it's booted one way, it can't perform any operation on
> the other format, regardless that they are two separate discs, and grub, in
> it's unquestionable wisdom, uses the bios instead of direct i/o.  have i
> got that about right?  if so i guess i need to get another thumb drive for
> booting in EFI mode?  or is there a way to tell grub to switch modes after
> grub boots up and before booting the iso?
>
>
> On Tue, Nov 12, 2019, 19:25 gregrwm <tclug1 at whitleymott.net> wrote:
>
>> a dear friend is bringing his laptop over tomorrow morning at 8:30am to
>> see if we can find anything he had on it (in ubuntu) before it died and he
>> took it to best buy for warranty service.  they replaced the motherboard
>> and installed windows 10.  how thoughtful.  for starters i'll look at the
>> partitioning and see what might be there, but i rather expect to find
>> windows 10 was told to take the whole disk for scratch.  i've never used
>> autopsy or anything like it so am entirely open to recommendations of what
>> approaches would be most likely (even if rather unlikely) to bring joy for
>> my friend.
>> tia,
>> greg
>>
>

-- 
this concludes test 42 of big bang inflation dynamics.  in the advent of an
actual universe, further instructions will be provided.
000000000000000000000042
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20191115/9233c246/attachment.html>