3 ms·

I don't think GP is complaining because the procedure changed in the last 15 years, but precisely because it didn't. Surely, there's room for improvement.

by tux3 6y ago

vetinari 6y ago
Well, he still doesn't use UEFI. He could, it has been available for more than decade (i.e. better part of those 15 years), so the procedure didn't change because he has chosen so. Not that it is a bad thing, some people do prefer that kind of stability. But then, why complain about that? Btw, Intel did plan to remove CSM (legacy BIOS compatibility) with Tiger Lake and require UEFI class 3. We will see if they will follow through. Then the procedure WILL change, and we will hear from people who didn't expect it.
- yjftsjthsd-h 6y ago
  Wouldn't UEFI make it more complex, since you now potentially need to mount / and /boot and /boot/efi all separately before you can fully recover grub?
  - vetinari 6y ago
    Not more complex, but different. It does not have magic sectors on disk, in MBR for boot loader, on somewhere in dummy area of the filesystem for grubenv, everything happens on the EFI partition and with EFI variables (stored in nvram). Creating bootable EFI media means having vfat-formatted filesystem and copying files there. No need for tools like Rufus. Your firmware would find it at boot time, and allow you to boot from it; most UEFI implementation have boot manager built-in.
yjftsjthsd-h 6y ago
I think the issue boils down to the fact that it depends almost completely on exactly how the system is put together. I mean, the process is: 1. Boot into a working-enough live system - only way to improve this is to put a recovery system on the same system, but then you risk making it unbootable as well 2. Mount needed filesystems - depends completely on what filesystems there are, which is extremely variable; my only thought would be to use labels and hope that the installed system labels root/boot/efi the way you expect 3. Mount special filesystems - this is possible to automate; ex. arch-chroot (https://wiki.archlinux.org/index.php/Chroot#Using_arch-chroot https://wiki.archlinux.org/index.php/Chroot#Using_arch-chroo...) does it, but that requires that you know what you need, so it's going to be brittle unless you stick with distro-provided tools (hence, arch chroot) 4. Fix the system - again, totally depends on what happened and how it should be set up; yes, in the trivial case you could make a "just-reinstall-grub.sh", but it'll fall apart for non-trivial setups If every system looked the same, then yes you could make a livecd that automatically booted, set up mounts, chrooted in, fixed grub, and rebooted out, but this is the world of Linux-based systems so even within a single distro there's worlds of difference.
- the8472 6y ago
  Semi-automating the common cases with a GUI would probably help many of the less sophisticated users. E.g. scan the existing system for partitions and ask them which one they want to repair. Windows' repair mechanisms also only work in the common case and you have resort to quite similar CLI stepss when they don't.

I don't think GP is complaining because the procedure changed in the last 15 years, but precisely because it didn't. Surely, there's room for improvement.

by tux3 6y ago

I don't think GP is complaining because the procedure changed in the last 15 years, but precisely because it didn't. Surely, there's room for improvement.

vetinari 6y ago

Well, he still doesn't use UEFI. He could, it has been available for more than decade (i.e. better part of those 15 years), so the procedure didn't change because he has chosen so. Not that it is a bad thing, some people do prefer that kind of stability. But then, why complain about that? Btw, Intel did plan to remove CSM (legacy BIOS compatibility) with Tiger Lake and require UEFI class 3. We will see if they will follow through. Then the procedure WILL change, and we will hear from people who didn't expect it.

yjftsjthsd-h 6y ago
Wouldn't UEFI make it more complex, since you now potentially need to mount / and /boot and /boot/efi all separately before you can fully recover grub?
- vetinari 6y ago
  Not more complex, but different. It does not have magic sectors on disk, in MBR for boot loader, on somewhere in dummy area of the filesystem for grubenv, everything happens on the EFI partition and with EFI variables (stored in nvram). Creating bootable EFI media means having vfat-formatted filesystem and copying files there. No need for tools like Rufus. Your firmware would find it at boot time, and allow you to boot from it; most UEFI implementation have boot manager built-in.

yjftsjthsd-h 6y ago

I think the issue boils down to the fact that it depends almost completely on exactly how the system is put together. I mean, the process is: 1. Boot into a working-enough live system - only way to improve this is to put a recovery system on the same system, but then you risk making it unbootable as well 2. Mount needed filesystems - depends completely on what filesystems there are, which is extremely variable; my only thought would be to use labels and hope that the installed system labels root/boot/efi the way you expect 3. Mount special filesystems - this is possible to automate; ex. arch-chroot (https://wiki.archlinux.org/index.php/Chroot#Using_arch-chroot https://wiki.archlinux.org/index.php/Chroot#Using_arch-chroo...) does it, but that requires that you know what you need, so it's going to be brittle unless you stick with distro-provided tools (hence, arch chroot) 4. Fix the system - again, totally depends on what happened and how it should be set up; yes, in the trivial case you could make a "just-reinstall-grub.sh", but it'll fall apart for non-trivial setups If every system looked the same, then yes you could make a livecd that automatically booted, set up mounts, chrooted in, fixed grub, and rebooted out, but this is the world of Linux-based systems so even within a single distro there's worlds of difference.

the8472 6y ago
Semi-automating the common cases with a GUI would probably help many of the less sophisticated users. E.g. scan the existing system for partitions and ask them which one they want to repair. Windows' repair mechanisms also only work in the common case and you have resort to quite similar CLI stepss when they don't.