Closed ajshell1 closed 5 years ago
Here. I've replicated the issue in Virtualbox. Now you don't have to look at my awful phone picture.
This shows up immediately after the pacstrap appears to finish.
We have new ALEZ ISO releases auto-generated by a Travis CI script on every commit and sometimes they don't quite work and we're not sure what causes the occasional faulty ISO as most of them work fine.
I was having similar issues to you using what was the latest ISO release but I tried the previous release ( archlinux-alez-2019.03.29.21.10.56 ) and that worked so I deleted what was the latest.
Try again with archlinux-alez-2019.03.29.21.10.56
Thank you. I'll try that when I get home from work.
Installation still fails for me with the same error when booting from BIOS with archlinux-alez-2019.03.29.21.10.56.
It does NOT fail to install when booting from UEFI.
Unfortunately, my motherboard is a hunk of junk with only a UEFI V1 shell built in.
I've never been able to successfully boot any hard drives in UEFI mode with that mobo. I'm going to try and get it to boot in the meantime. I'd appreciate it if you would still try to investigate this bug.
I have yet to see this "/mnt is not a mount point" error. Have you tried any other older releases of ALEZ iso apart from what is currently the latest? The latest ALEZ ISO installs fine using BIOS/GRUB under qemu for me.
Have you got any SATA/AHCI disk settings in your UEFI/BIOS you can adjust?
Scratch that. I get the feeling that my UEFI install doesn't actually work on the grounds that running "zpool import -R /mnt zroot" after installing results in "cannot import 'zroot': no such pool available"
I'm getting the same issue for the four most recent releases. Can you try to replicate the issue in VirtualBox or something else instead of QEMU?
I've just successfully installed Arch using archlinux-alez-2019.03.29.21.10.56 under virtualbox.
I'm guessing you didn't read the bit in the README about having to use SATA (or VirtIO) disks for ALEZ when using VMs? vbox, like virt-manager/qemu, defaults to using IDE and grub-probe / grub-install chokes on IDE disks. You have to change the storage controller to SATA for at least the HD. The CD-ROM can remain as an IDE drive.
Up until now, the README said this was only the case for qemu/virt-manager but it actually applies to all VMs so I've updated the README to make this clearer and also added a note warning people about the occasional broken ALEZ ISO.
I've tested it in virtualbox with ONLY sata drives.
You know what? I'm going to try and do this myself. Thanks for looking into this issue anyway.
If its not working for you under VB with that ISO and you are using SATA drives then you must be going wrong somewhere because it works for me.
Fortunately, I managed to get my own custom ZFS Setup installed.
I'd like to thank you for providing the ISO. Even if the install script didn't work for me, it still made installing Arch with ZFS normally much easier.
So, after a failed attempt to install Arch with ZFS, and then a sucessful attempt with BTRFS, I decided to give this a shot.
I'm using an MSI Gaming 5 Z97 motherboard, with the target drive being a Samsung 850 EVO (which is currently listed as /dev/sde because I have 4 other HGST drives in my system and I can't be bothered to rearrange the SATA cables). I've burned the ISO (the one I downloaded from the releases page) to a nice verbatim CD-R (because I've never been able to successfully install any operating system from USB on this machine for some unfathomable reason), and I'm booting via BIOS (because I've also never been able to get UEFI to boot anything).
Anyway, when I start the ALEZ installation, everything seems to go fine. I select the drive, set it to be partitioned, and then it appears to be doing the pacstrap. However, it seems to fail at some point between then and the GRUB configuration.
The first time it failed, it looked like this: https://cdn.discordapp.com/attachments/389121244919889935/562640429091389471/20190401_171202.jpg
After doing df -h, I noticed that my cowspace or whatever you want to call it was completely full. Figuring that this was the issue, I changed the Arch boot behavior to now have 4 gigabytes of cowspace. This proved to be overkill in terms of this issue, but I found a second issue:
https://cdn.discordapp.com/attachments/389121244919889935/562640429091389470/20190401_193050.jpg
I'm not sure what to do now. This happens regardless of which kernel I choose, and it happens every single time I tried it with more cowspace.
I'm willing to cooperate in any way to get this issue fixed. Please let me know if you need more info.