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>