Tried everything, install won't work if it installs at all

tzwcfq · May 27, 2022, 5:14pm

Don’t know about this. I never was interested in this distribution holy war topics.
For me the main drive in distribution selection would be the trust in the maintainers of these distributions. I’d rather use well known distribution with long and clean history rather than some new and unknown distribution the maintainers of which can plant some malware inside.

SteveC · May 28, 2022, 6:33am

Fedora downloaded quickly.

It also detected both the SSD that has Qubes (as installed onto thumdrive from the thumbdrive with the ISO on it), as well as an empty old hard drive; it looked willing to install Fedora on either.

It looks like this is a Qubes-specific problem. So I’ll restate (for anyone else joining now):

The Cubes installer doesn’t recognize any SATA drives (just USB ones), even at the fdisk level. Any HDD or SDD is totally invisible to the installer. I can install onto a thumb drive, but the install takes 2 1/2 to 3 hours and the boot is a good ten to fifteen minutes. I can only assume the system would be so slow as to be unusable, plus I wouldn’t trust a thumb drive for my main system anyway on simple reliability grounds (let alone security). [BIOS information given earlier in this thread.] This is NOT a RAID issue, I don’t have RAID enabled.
Conversely, any installation copied with dd to a SATA drive (or installed onto a SATA drive on another system and brought over) is not recognized as a bootable drive by my system. My bios can see it and certinaly lsblk on Ubuntu can see it; it just won’t boot and I’ll be told to insert bootable media.

[sorry it took so long to respond, I hit an upper limit on first day comments apparently instituted to guard against robo spam posts. I couldn’t even respond to a welcome message from the admins to ask them to relax the limit.]

SteveC · May 28, 2022, 6:34am

I have a temporary workaround. It runs fast enough for test driving, when run off a Western Digital Passport drive.

Given how much USB is frowned upon, no doubt having the OS installed on a USB drive is making someone spin in their sleep.

tzwcfq · May 28, 2022, 6:49am

Did you try to add EFI boot menu entry with efibootmgr?
Maybe if you dd from your Western Digital Passport drive to your SATA drive and add EFI boot menu entry then it’ll boot.

SteveC · May 28, 2022, 4:44pm

No, because when I went to do fdisk to get the device ID, it wasn’t even visible there. The method (as I understand it) depends on knowing that.

tzwcfq · May 28, 2022, 4:50pm

Did you try to do it from SystemRescue ISO or from Fedora ISO? Or you just tried from Qubes installer ISO?

SteveC · May 28, 2022, 5:17pm

Qubes installer.

tzwcfq · May 28, 2022, 5:22pm

Then you can try to do it from SystemRescue/Fedora since they should see your SATA drives.

SteveC · May 29, 2022, 2:03am

Don’t look now…but suddenly the USB Passport drive won’t boot either.

That’s about a day’s worth of work down the drain.

Qubes rescue says there are no linux partitions on the drive.

It will no no longer boot off the fedora thumb drive, either, so I can’t implement your suggestion at present.

tzwcfq · May 29, 2022, 4:22am

It’s probably the same problem with disappearing EFI menu entry that needs to be fixed with this:

Qubes 4.1: efibootmgr usage

If your device is /dev/sda and efi partition is 1 then :
efibootmgr -v -c -u -L MichaelA -l /EFI/qubes/grubx64.efi -d /dev/sda -p 1

If you use qubes os as external device, folow this (I assume that your device is /dev/sda and efi partition is 1) :
cp /boot/efi/EFI/qubes/* /boot/efi/EFI/BOOT
mv /boot/efi/EFI/BOOT/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi
mv /boot/efi/EFI/BOOT/grub.cfg /boot/efi/EFI/BOOT/boox64.cfg
efibootmgr -v -c -u -L MichaelB -l /EFI/BOOT/bootx.64efi -d /dev/sda -p 1

SteveC · May 29, 2022, 4:47am

No, because in this case, when I try to boot off the thing, it gives me the standard “insert bootable media and press any key” message.

The SSDs that I copied installations onto just cause the system to hang with a flashing cursor.

I notice your example still uselessly includes your name for the name of the bootable device rather than something like the name of the OS.

I wonder what else in here is obfuscative. If I can ever get the Fedora installer to boot maybe I’ll find out.

tzwcfq · May 29, 2022, 4:54am

I’ve already explained this here:

tzwcfq:

It’s just an example EFI entry name that you will see in EFI boot menu like ubuntu . You can name it Qubes for example:
efibootmgr -v -c -u -L Qubes -l /EFI/BOOT/bootx.64efi -d /dev/sda -p 1

SteveC · May 29, 2022, 5:25am

Yes, but that’s exactly the problem. You KNOW this is confusing yet you persist in using it.

Right now, I’ve managed to get into Fedora Live and (to my complete lack of surprise) there’s no such directory as /boot/efi/EFI/qubes. Clearly there’s something in there you didn’t explain.

I’m going to guess its because you have to perform those steps AFTER you manage to boot into the partition using the first command.

Which did work, entirely too well. I couldn’t boot into anything else no matter what. No F12 menu to choose from; I had to shut the system down.

And now I find myself in the situation where if I unplug everything else but ubuntu it still won’t boot into ubuntu without my going into my BIOS and disabling everything other than the one item named “ubuntu.”

So now my machine is bricked.

tzwcfq · May 29, 2022, 5:40am

From what OS did you do it? From ubuntu?
Boot from Fedora Live and paste here the output of this command:
sudo fdisk -l

tzwcfq · May 29, 2022, 6:16am

Here is what you had to do:
Boot from Fedora Live.
Find out your USB Passport drive device and EFI partition number on it with this command:
sudo fdisk -l
For example, it’s /dev/sda and partition number 1.

Device    Star  End Sectors   Size Type
/dev/sda1 xxx xxx xxx   100M EFI System
/dev/sda2 xxx xxx xxx   1G Linux filesystem
/dev/sda3 xxx xxx xxx   100G Linux filesystem

Then run this command for /dev/sda and partition 1:
sudo efibootmgr -v -c -u -L Qubes -l /EFI/qubes/grubx64.efi -d /dev/sda -p 1
Try to boot in Qubes installed on USB Passport drive.
If it’s successful then run these commands in Qubes dom0 terminal:

sudo cp -r /boot/efi/EFI/qubes/* /boot/efi/EFI/BOOT
sudo mv /boot/efi/EFI/BOOT/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi
sudo mv /boot/efi/EFI/BOOT/grub.cfg /boot/efi/EFI/BOOT/boox64.cfg
sudo efibootmgr -v -c -u -L Qubes -l /EFI/BOOT/bootx.64efi -d /dev/sda -p 1

tzwcfq · May 29, 2022, 6:39am

If you run these commands from ubuntu:

sudo cp /boot/efi/EFI/qubes/* /boot/efi/EFI/BOOT
sudo mv /boot/efi/EFI/BOOT/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi
sudo mv /boot/efi/EFI/BOOT/grub.cfg /boot/efi/EFI/BOOT/boox64.cfg

And you had /boot/efi/EFI/qubes/ directory there, then maybe you’ll be able to restore your boot with this:
Boot in ubuntu.
Run this command to backup files just in case:

sudo mkdir /boot/efi/EFI/BOOT-bak
sudo mv /boot/efi/EFI/BOOT/* /boot/efi/EFI/BOOT-bak

Run these commands to restore ubuntu grub as default EFI entry:

sudo cp -r /boot/efi/EFI/ubuntu/* /boot/efi/EFI/BOOT
sudo cp /boot/efi/EFI/BOOT/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi
sudo cp /boot/efi/EFI/BOOT/grub.cfg /boot/efi/EFI/BOOT/boox64.cfg

SteveC · May 29, 2022, 7:23am

OK now that makes more sense.

I was able to boot into Ubuntu, finally.

I did another install of Qubes onto a second passport, but this time I first made sure that there was a partition covering 3.5 TB (out of the 4) and nothing at all in the first half terabyte.

That free space is slightly smaller than the SSD I would like to use. Unfortunately the actual Qubes Installer just takes all of the available space, there’s no way to tell it please only take 500GB. (Lesson learned from the first Passport install.)

So right now I’m dding the passport with the new install, onto the SSD that formerly held a dd of the first thumbdrive.

After that, I’ll remove the passport, and try this procedure from inside Ubuntu then inside Qubes, assuming it boots off the SDD (which it should, until I power down). I’ll then see if the second part of the procedure makes the fix permanent.

Presuming for the moment that I have a functional SSD with Ubuntu and another functional one with Qubes, I’m going to want (for now) to boot into Ubuntu preferentially and Qubes with the F12 menu.

Right now there are according to efibootmgr, five entries in the bootloader menu. At least I assume that’s what typing efibootmgr by itself gives you.

Boot0008* UEFI OS
Boot000B GENERIC STORAGE DEVICE 0828
Boot000C* ubuntu
Boot000D* UEFI OS
Boot000E* Samsung SSD 860 PRO 1TB

As near as I can guess, UEFI OS might be telling it to display a menu. Ubuntu will display a menu, just the ubuntu menu. The other two refer to the same SSD ubuntu is on (certainly the Samsung one does, I’m not so sure about GENERIC STORAGE DEVICE), but may or may not work at all. But all five of these show up just from one dang disk, which is galling since I’m still working on getting the other disk to display once!

What do the asterisks mean?

tzwcfq · May 29, 2022, 7:51am

You need to create filesystem on this 3.5 TB partition so installer won’t try to use it.
For example you created two partitions /dev/sda1 500 GB and /dev/sda2 3.5 TB with fdisk.
Then you need to create filesystem for /dev/sda2 for example ext4:
sudo mkfs.ext4 /dev/sda2
Then installer won’t see /dev/sda2 as free space.

I’m not sure if it’ll work if you just dd from larger LVM partition to a small LVM partition.

If it’s only efibootmgr command then you can run it from ubuntu as well. But for a permanent fix you can’t just make changes in /boot/efi/EFI from your ubuntu system because it’s the ubuntu os EFI partition that is mounted in /boot/efi in ubuntu. You need to either move files in /boot/efi when running Qubes or you can mount the /boot/efi partiton from Qubes disk to some directory like /mnt in ubuntu and move files there.

Run this command to see more info about EFI entries:
efibootmgr -v

This should be your USB drive.

Five boot entries (0000 - 0004), along with the active/inactive flag (* means active) and the name displayed on the screen.

Summary

   [root@localhost ~]# efibootmgr
   BootCurrent: 0004
   BootNext: 0003
   BootOrder: 0004,0000,0001,0002,0003
   Timeout: 30 seconds
   Boot0000* Diskette Drive(device:0)
   Boot0001* CD-ROM Drive(device:FF)
   Boot0002* Hard Drive(Device:80)/HD(Part1,Sig00112233)
   Boot0003* PXE Boot: MAC(00D0B7C15D91)
   Boot0004* Linux

   Each of the above are boot variables, which are defined as follows:

          · BootCurrent - the boot entry used to start the currently running system

          · BootOrder - the boot order as would appear in the boot manager.  The boot manager
            tries  to boot the first active entry in this list. If unsuccessful, it tries the
            next entry, and so on.

          · BootNext - the boot entry which is  scheduled  to  be  run  on  next  boot.  This
            supercedes  BootOrder for one boot only, and is deleted by the boot manager after
            first use. This allows you to change the  next  boot  behavior  without  changing
            BootOrder.

          · Timeout - the time in seconds between when the boot manager appears on the screen
            until when it automatically chooses the startup value from BootNext or BootOrder.

          · Five boot entries (0000 - 0004), along with the  active/inactive  flag  (*  means
            active) and the name displayed on the screen.

https://manpages.ubuntu.com/manpages/focal/man8/efibootmgr.8.html

SteveC · May 29, 2022, 8:21am

Before I get to your last post, I spotted this in one of your lists of directions. I strongly suspect that that last file name should be bootx64.cfg not boox64.cfg.

As for the partitions, the passports come with a full-size partition (which appears to be ntfs, i.e., windows) and you have to tell the installer to wipe them.

Doing what I did (resulting in 500GB of blank space and a 3500GB ext4 partition) resulted in the installer saying “there’s 500GB of free space.” It ignored the 3500GB partition entirely, contrary to your expectation. I suppose it would have been able to delete it if I wanted.

Now it did call the 3500GB partition sdx1, and the three installed are sdx2, etc. rather than 1, 2, 3, but looking at the starting blocks I know that those three are first on the disk. (It’s not x, but what it is seems to partially depend on how many other things are plugged in at that particular boot, so consider x a variable.)

So what I am DDing is in fact smaller than the destination drive. My bigger concern is whether the boot record will still have them numbered funky or not. I’ll know in about an hour when the dd is done.

Playing with blkid, lsblk, efibootmgr -v (I tried it with -v a few minutes after my last comment) has been very educational.

I was even able to mount the EFI directory from the passport and go looking around…which means for once I anticipated a suggestion of yours.

Is there a particular reason to be renaming the grub files to boot files? Could we just tell the boot manager to use the grub files?

i tried relabeling some of the entries in the efi boot manager, but relabeling wouldn’t take for some reason (unless you do something else other than "efibootmgr -v -b 000C -L Ubuntu [just to get ubuntu capitalized].

OK to recap: Once the DD is done, I’ll try putting the SSD into the efibootmgr list, making it second in the order. I’ll increase the delay, too (I already have). If it works, great…I boot into it and move those files. If I understand correctly that should be a permanent fix. If it doesn’t work I’ll experiment with recovering the old installation though it’s too doggone big to move permanently (so maybe it’s just as well it went non-bootable).

efibootmgr -v shows me:
0008 active “UEFI OS” points to a master boot record…which in the last couple of days I realized is very old stuff; this is probably there for backward compatibility.
000B is inactive and it’s the generic storage device (USB, from what you tell me)
000C is active “ubuntu”, it points to Ubuntu’s grub stuff, giving a full id and file path.
000D is active “UEFI OS” and points to Ubuntu’s boot stuff, giving a full id and file path.
000E is active, the samsung drive by name, apparently if it works (and I am not sure it does) it follows some sort of default.

Part of the reason I have been so frustrated with this menu is two totally different options are both labeled UEFI OS and only the latter of the two apparently would actually DO something. Ideally the one named Ubuntu would be called Ubuntu Grub (meaning it presents a menu) and the second one named UEFI OS would be labeled Ubuntu. But I can’t figure out how to change the labels, -b 000C -L doesn’t change it.

tzwcfq · May 29, 2022, 8:53am

You’re right, it should be bootx64.cfg, I’ve copy-pasted and didn’t recheck.

Check the link to stackexchange from this post:

I think you can only set label when you create entry and can’t change it after this. You can delete old entry and create same entry with new label.

Yes, these should be the right steps.

You can try to first create new entry the same as “ubuntu” but with changed label to “Ubuntu Grub” for example and check if it works. If it works then delete old entry.