Posted December 12, 2020
rojimboo: The removable flag syntax is wrong I think and from the Arch wiki :
You might note the absence of a device_path option (e.g /dev/ sda) in the grub-install command. In fact any devicepath provided will be ignored by the GRUB UEFI install script. Indeed, UEFI bootloaders do not use a MBR bootcode or partition boot sector at all." and "If you are trying to run grub-mkconfig in a chroot or systemd-nspawn container, you might notice that it does not work: grub-probe error failed to get canonical path of /dev/sdaX. In this case, try using arch-chroot as described in the BBS post. In addition, as it mentions aufs, it might be some dependency issue.
The wiki itself has errors? Great. Well I'll keep in mind what you've said here once I get the chance to read the wiki. You might note the absence of a device_path option (e.g /dev/ sda) in the grub-install command. In fact any devicepath provided will be ignored by the GRUB UEFI install script. Indeed, UEFI bootloaders do not use a MBR bootcode or partition boot sector at all." and "If you are trying to run grub-mkconfig in a chroot or systemd-nspawn container, you might notice that it does not work: grub-probe error failed to get canonical path of /dev/sdaX. In this case, try using arch-chroot as described in the BBS post. In addition, as it mentions aufs, it might be some dependency issue.
rojimboo: Also, I don't see why you couldn't copy all files from a MBR to a GPT one (though I don't see the point of doing it in MBR in the first place) but copying boot files from your currently running normal linux installation will of course not work due to different drives and partitions and entries in the bootloader.
The reason why I made the USB drive have an MBR is so that I'd be able to boot into Linux made from the Live Kit using CSM mode, and then once there, I could install GRUB onto the EFI partition, and then change the MBR to a GPT (which would probably require formatting a new drive and then just copying the partitions onto it), so that I could henceforth boot in UEFI mode. But I couldn't install GRUB while I was booted into the Live Kit one (maybe because it's live mode, though the default Mint live ISO has GRUB, so who knows?). So what I might be able to do is install GRUB onto the USB EFI partition while booted into the Linux on my HD, and even though it would put my HD Linux and Windows on the list, it could also put the Live Kit Linux on the list (if I first update GRUB while booted into my HD with the USB stick plugged in), so that it will then hopefully be possible to boot into it after that. Then once inside I could just update GRUB in such a way as to remove the reference to my HD Linux (I hope there's a way to do that, or maybe I'd have to do it on another computer which doesn't have Linux installed).
rojimboo: I think it's a bit of a mess again, to be honest, and we had already established the script for linux-live kit doesn't work very well or at all for UEFI, and that adding boot options manually in conjuction with the custom script doesn't work either. None of this would be an issue with a persistent install of course.
And no, customising the linux-live kit iso with Cubic will almost certainly not work due to custom scripts and differences in setups. You can however post-edit a Cubic live Iso, with Cubic.
I don't see why Cubic wouldn't be able to modify a Live Kit ISO, because it can modify Linux ISO files in general, including the Mint default ISO. But I don't know. And no, customising the linux-live kit iso with Cubic will almost certainly not work due to custom scripts and differences in setups. You can however post-edit a Cubic live Iso, with Cubic.
Please stop suggesting a persistent installation, because it's a moot point, UNLESS you can think of a way to do it such that:
- It's read-only, so as to NOT actually be persistent at all, even though it's installed (to prevent both reconfiguration and wear-and-tear).
- It runs as fast or nearly as fast as live mode does on a USB (and with all of the supposedly ridiculously mis-configured problems in my BIOS - though I doubt that's true, and I've looked at the settings myself - I don't have the slightest clue how I'd go about fixing all of that, but it's just one more hurdle in an endless stream of hurdles!).
- It's able to run in RAM mode (toram), and have the ability to perfectly self-duplicate for backups, even if it needs the aid of a program like GParted to do so.
rojimboo, I'm not necessarily saying that there's definitely nothing wrong, but I'm saying that once everything boots it all works fine and it's fast as hell, and I haven't the SLIGHTEST idea how to fix the boot time problem, and I'm not about to get sidetracked by months of work trying to figure out that puzzle, when I'm trying to work on THIS problem, which is a much higher priority for me. If I have to wait 4 minutes then I have to wait 4 minutes.
Orkhepaj, the 4-minute boot is for any Linux whether it's on the HD or USB (and the HD is a disk because I don't use solid state).
Darvond, yes it's 4 minutes, and using a traditional-style HD. So evidently they do take that long.
clarry, alright but what does that prove? I'm still not even entirely sure what aufs is, let alone why it would make a difference (again, I'm getting about 10000000 different ideas thrown at me, and for each one that I try, it takes me about a week to either make any progress or realize that I've hit a dead end from all possible angles, and in that time there have been about 10000 more suggestions, so forgive me if I'm having a bit of trouble keeping up with it all).
Post edited December 12, 2020 by HeresMyAccount