Yes, and it acts the exact same, failing to load ldlinux.c32

My system is 64 bit, FWIW, with legacy booot/BIOS mode, no UEFI

Well, I am now using my preferred setup. Giving the job to my dell inspiren1545 which finally connected to wifi, so no more using usb tether. This is much better.

Hi, the timer high-pitch beep is fenrir's optional autotime function, which announces the time every 15 minutes. This is configurable in fenrir's settings.conf near the end of the file.

To make it be quiet, hit windows or caps lock+enter to disable autoread. You appear to be using the pi installation script, which, according to the second value, 467M, is downloading the base arch linux arm image. After the first number, which indicates percentage, reaches 100, the base image will be extracted and the payload for your selected preset will be downloaded and executed.

Still flashing the pi3 Arch64bit image, now it seems to be in a fix again. It seems to restart  syncing packages databases again and again, with about 6 packages (core is up to date, Jenux is up to date, Alarm is up to date, Blackheart is up to date.) then all these package warnings/skipping warnings. Every time I interrupt with windows+i or any of the line review commands, it restarts back at syncing package databases. Is this normal?

@Hacker:

Tried with formatting on a Windows box with Rufus. Same result, failed to load ldlinux.c32. Tried formatting as FAT32 despite other people saying oh, you gotta format it as FAT16, same result. It all comes back to, least for me, ldlinux.c32 failing to load.

I've tried 4 or 5 different USB sticks and now have tried Arch, Talking Arch, Antergos, Manjaro, Jenux, even Sonarr and all consistently fail to load.. ALl with the same ldlinux.c32 error.

never mind, the virtual machine was just not connected to the internet. sorry for the double posting.

As always, well done Nash. Keep them dirty-ass hacks comin'.

the drive unplugged maybe?

Hi, since the command to reread the partition table is run directly after the partitioning step, the partitions on the flash drive are not touched. To verify, run parted, fdisk/gdisk, or whatever partitioning tool you are most comfortable with. If the drive was touched, the partition layout, excluding size differences, would be the same on both the installed system and the flash drive. As for the squashfs error, this most likely indicates that the drive was either jostled during the installation, or powered off in some way, which will cause reading of sfs blocks to fail. To fix this problem, do one of the following:
1: if using isolinux in csm mode, after the beep, hit tab, end, type a space, and type copytoram=y, hit enter. Once you hear speech, it should be safe to unplug the drive.
2: Use the netboot script mentioned above to boot the target over the network, which does not require a flash drive, downloading the kernel, initramfs, and rootfs into the target's ram and running from there.
Since the package download and installation is complete, you have a working system. To fix the unconfigured system problem, either manually follow the arch install guide after the install the base system section, or for automatic configuration, use the post-install tarball for your specific selected software preset, replacing /dev/sda with your hard drive, sda3 with whatever you made your root partition, and sda2 with whatever you made your boot partition. Here's how to do it:
1: If using encryption, unlock your LUKS by typing:
cryptsetup luksOpen /dev/sda3 root
If not using encryption, replace step two's mount command with your root partition, i.e. instead of /dev/mapper/root, put /dev/sda3
2: mount your root partition:
mount /dev/mapper/root /mnt
3: mount your boot partition:
mount /dev/sda2 /mnt/boot
4: cd to /mnt, download and extract the post-installation tarball, replacing preset with your preset name, such as base, gnome, mate, kodi, or all, and run the script:
cd /mnt
curl https://nashcentral.duckdns.org/autobui … tar.gz|tar -xz
arch-chroot /mnt /etc/postinstall.sh /dev/sda
Hope this helps.

Okay....

No, the drive was not jostled or powered off in any way. It installed the packages, and stated main OS installed. After that point, it asked if I wanted to remove packages...and locked up when I went to hit N, after picking LTS/Mate preset.

Note: I did not, at all, touch the drive at all. Three people can and did verify this. I ended up with a system that installed okay, did all the packages...then broke after installation. I even left it for an hour and nothing changed. Just a screen full of squashfs errors that even hitting any key wouldn't clear.

So, umm, I found at least one reason Jenux isn't working on some people's systems, at least mine anyway. In fact, if anyone is running it on bare metal and it worked right out of the box, I'd be interested to hear about it since what I found is, well...

OK, so if you let it partition your drive for you, it creates two boot partitions, one of which is an EF00, and the other an EF02. They are EFI and BIOS boot partitions. Not only that, but upon installation of Grub, the script installs three versions it looks like. How its doing that, I have no idea, but its installing i386_pc i386_EFi or something and another oen which is X86-64. So now you have two partitions and three bootloaders. I didn't really look in depth to see what was going on, in fact, this is edging outside my knowledge base a bit, but I'm just reporting what I saw. The EFI spec basically says that finding bootable devices and so forth is basically up to the vendor. I therefore, posit that in some cases, and I would estimate the likelihood to be quite high, that the EFI is just failing to find a possible boot situation amidst the mess.

There are ways to detect which mode you're booted into and have the script install the appropriate bootloader and create the correct partition type.

So, getting the software to work in a VM is less headachy because if all else fails, you can just modify your VMX file and get it up and running, but I actually would like to run this on a physical machine. That's why I'd be curious if anyone's actually gotten it working, because I'd be amazed. The only way I could see that it would be possible is to boot into legacy mode and the BIOSboot partition appears first, then maybe it has a chance lol, other than that... meh.

The installation script also doesn't attempt at all to catch errors. I saw several failures, and the script moved right along as though nothing had happened. First thing, after the prompt about encrypting, and I answered no (I have a story about how encryption failed me badly) It went on later to start encrypting home directory, which by the way, I did not want to do. Anyway, that failed because of CHOWNing some file, but the installer just went on about its merry way. I also recall something else, but it escapes me now. Let it suffice to say that installing Arch is an intricate process. I wouldn't entirely say It's difficult, as all that you need is on the wiki, and you can cross-reference to find what you need among the articles. Sure, for the Linux newbie it would be, but isn't that why Jenux exists, or is the mission statement to be something else. At any rate, it is intricate. A lot of things  need to happen, and they need to be done at the right time and in the right way. So an installation script can't just ignore errors. I also find it a bit disconcerting that it does so, in hopes that no one would notice? It's not as if I keep the speech on, but if something crops up, I want to know about it. And if it's too much to provide backup routines to try to actually fix the error, the script should be suspended and allow the user to drop to a shell, then correct the problem. If that happens, and whatever issue cropped up is now fixed, the user could then resume the script and all would go along as it should.

I'm also a bit concerned that none of this is mentioned that I've seen. In other words, to let someone know this isn't production ready (it clearly isn't) and that it's alpha software.

I want to put it out there that I respect what the author is doing here, and that I"m not writing this to bash the product, but to try and make it better. If all the kinks could be ironed out, this could definitely be cool, but right now, it's really not ready for daily production use, there are just too many loose ends.