Closed KloudKoder closed 3 years ago
mmstick
commented
5 years ago The state of the hard drive really doesn't matter. When selecting a disk to install to, the installer executes wipefs -a ${DEVICE} to erase all signatures and then proceeds to use libparted to partition to the drive with a GUID partition table.
KloudKoder
commented
5 years ago That sounds good if it's really done that way. In any case, the swap can't be formatted via custom install because it's locked. That makes no sense because it shouldn't be in use.(I'm talking about the encrypted swap as it existed before the install, not some temporary swap created by the installer itself.) My colleague has been struggling with this for a while on a number of machines. The only way he got things to work was to format the drive with a Windows USB stick, then reboot the PopOS installer with CSM enabled. He tried to disable CSM after the install, but then PopOS would never boot. This is on a machine that previously was running another Linux flavor in UEFI just fine, and had been reinstalled many times with no issue. Any suggestions for a workaround would be appreciated.
I wonder if this is due to a recent change in the UEFI functionality dependencies of the installer (perhaps even upstream of PopOS). I say this because it gets 2/3 of the way through the setup, almost to the restart point, before it displays an error saying that the installation failed.
The partition formatting issue might be a red herring because it occurred when my colleague also happened to have CSM enabled as well.
He tested another Linux distro and hit the same issue. Common code to blame?
KloudKoder
commented
5 years ago @mmstick This is why it fails, according to installer.log:
[WARN distinst:crates/chroot/src/command.rs:89] rsync: change_dir "/cdrom/casper" failed: Not a directory (20) [ERROR disinst:src/installer/state.rs:37] configuring chroot error: error creating recovery partition: command failed with exit status: exit code:23
KloudKoder
commented
5 years ago @mmstick More details on the custom install problem: GParted does indeed lock the swap and/or the LUKS partition, preventing them from being deleted. (I can't delete a partition just because it's encrypted? Or worse, because the installer is mounting an untrusted old/stale/infected partition? I have no idea. It's understandable that they might get mounted (and therefore locked) within a normal OS context, but they should be ignored during clean (i.e. "delete everything") install.) I just went to Activities -> Terminal, then used the following command to destroy their partition signatures:
lsblk (to find the name of the drive, as opposed the USB stick, e.g. sda) sudo dd if=/bin/sh of=/dev/sda bs=1M; sudo sync
which corrupts the drive's partition table by overwriting it with the /bin/sh executable.
Then hold the power button til the machine turns off. Then restart the install. The drive will now be 100% unallocated space.
But again, it fails to install in UEFI.
KloudKoder
commented
5 years ago @mmstick This needs a docfix. It turns out that the technician who created the ISO image used a popular imaging utility which doesn't preserve the ISO layout, so the hash of the burned image was wrong even though the files may have been correct. (He tried 2 different such utilities and they both resulted in the same uninformative error message. He didn't use dd, however, which would have worked (just don't forget to append "; sudo sync" after the write command).) Instead of saying "can't install", it would be nice to have a little more info to remind the user that this could be the cause. "Did you verify the SHA256 of the image?" Lots of people are using crappy third party ISO utilities. This is bound to come up again.
user5145
commented
5 years ago I have the same problem. My asus UX433FA doesn't support csm and legacy bios so it's impossible to install pop os even though efi shell and gparted can boot. My old lenovo 100-15iby can boot pop os from the same pendrive from which Asus can't. I tried etcher, rufus and manually extracted it into fat32 everything gives the same result. When i run grubx64.efi from shell it freezes. Many people on r/pop_os report it.
KloudKoder
commented
5 years ago Just make sure that Rufus is writing the ISO correctly. Pull out the USB stick, insert it back, and read the ISO back. (If it reads the entire stick, then just truncate it to the ISO filesize prior to comparison.)
user5145
commented
5 years ago thanks for your help but there is no such option as read/check (is only for bad blocks) and what should i compare to what?
edit: and im really sure it's flushed to the USB stick i always sync as root before i pull it out.
KloudKoder
commented
5 years ago @user5145 But sync seems to be broken: https://github.com/pop-os/pop/issues/618
What you need to do (under Linux in a terminal, not on Windows) is:
vovchykbratyk
commented
5 years ago I am running into the bug with UEFI install hang as well.
b-hayes
commented
4 years ago I've been having this problem for nearly a week. I am unable to install and boot pop is. After reinstall after copy files I end up with two new Jedi entries get black screen or a grub consol depending which I choose.
shassard
commented
3 years ago Same issue with a Lenovo Yoga 920 here that doesn't offer any CSM support.
jacobgkau
commented
3 years ago I'm closing this generically-named issue because installing in UEFI mode does work, and it appears that in this case the problem was an incorrectly-flashed USB drive. Anyone experiencing issues installing on particular hardware may contact their hardware vendor or open a new issue specific to that hardware.
System76 customers can reach out to support for technical assistance. For non-System76 hardware, you can seek community support on Reddit or Mattermost.
Distribution (run
cat /etc/os-release):Intel/AMD LTS 53
Related Application and/or Package Version (run
apt policy $PACKAGE NAME):N/A
Issue/Bug Description:
On an Intel system and a completely different AMD system, it's impossible to install with UEFI enabled. Enabling CSM (and all its hazards) does work, but then you can only ever boot with CSM turned on. I remember back in the old days some Linux flavors required you to install in CSM, then disable it for normal boot. Of course, this is something the user needs to figure out over hundreds of random iterations because the UI provided no information about this. It would be nice to get a message saying "if the install fails, try enabling CSM in the firmware setup". Or "now that the installation has succeeded, you should disable CSM because it's a security hazard".
It gets mostly through the entire process, up almost to the restart point, when a message comes up indicating that the install failed.
One workaround that seems to work is to format all the drives using the custom install option. Why this works, and exactly under what circumstances, is unfortuneately a total mystery to me. In any event, it's rather disturbing that the state of the harddrive should matter at all. The installer should clobber it when I ask for erasure -- not interact with it and risk activating a security vulnerability. If you can't get this to work, try decrypting the harddrive before formatting. For some crazy reason, that seemed to help.
Sorry I can't be more precise. I'm relaying this second-hand. But I'm completely certain that the failure is persistent on different machines from different vendors with different CPU companies.
Steps to reproduce (if you know):
As above.
Expected behavior:
Can we make UEFI just work? And why does the installer's behavior depend on the state of the drive, when I'm not trying to do any kind of multiple boot install. Just overwrite it when I tell it to.
Other Notes: