mafredri / asustor_as-6xxt

All things ASUSTOR AS-6XXT sans ADM
20 stars 4 forks source link

Asustor 604T no bios or usb boot #9

Open Ogglord opened 11 months ago

Ogglord commented 11 months ago

Hi Mafredi, @mafredri

I've got an otherwise fully functional asustor 604t, I set out to install debian on it. But I can't enter bios or get it to boot from my USB, I've tried smashing ESC, F2, DEL during boot. But I get no HDMI output, i've tried numerous hdmi cables and two monitors. It just boots straight to ADM. I have removed my 4 spinning rusts and I'm only using an 2.5inch SSD at the moment, with a fresh ADM OS on it.

Any suggestions, am I missing something obvious

PS. Jag blir galen haha

mafredri commented 11 months ago

Hi @Ogglord, I feel your pain, unfortunately the AS-604T doesn't have a proper BIOS, it's basically a very dirty hacked-together EFI bootloader that has everything hard-coded. 😅 It's also impossible to get video out before the appropriate kernel module is loaded so you're limited to either doing things blind or hooking up to the serial port.

Have you seen my other repo https://github.com/mafredri/asustor_as-6xxt, and more specifically, https://github.com/mafredri/asustor_as-6xxt/blob/4bf6736ceb4cbe1675249cbefa91c570f289e12e/debian.md? Steps are quite abridged, but should give you a general idea of what to do. As long as you automate the install/live image bootup, and place your grub .efi in the correct location, it should work out just fine.

The preseed I used once-upon-a-time is here: https://github.com/mafredri/asustor_as-6xxt/blob/4bf6736ceb4cbe1675249cbefa91c570f289e12e/debian/preseed

Essentially, you just need to copy the files to a USB once you're done (1 partition formatted vfat), IIRC.

One step that might not be mentioned in that repo, and that you may need to do, is hold the [USB COPY]-button (front panel, bottom left) whilst booting. This should force the AS-604T to load asloader.efi from the USB instead of the internal flash.

Hoppas det hjälper, och lycka till!

Ogglord commented 11 months ago

Okay, that explains a lot. I was quite close to pulling the trigger.

The thing holding me back is that once I disable the asloader.efi on the built-in flash, there is no turning back. If I fail the first boot from USB, what are the options then? Do I just keep tweaking the USB file until it boots and I get ssh access? Also I was not sure where to place the preseed.cfg. Some guides online extracted the initrd.gz and put the preseed in there, and compressed it again. Other guides just seem to put it in the root of the usb. How did you go about that?

I have a serial to usb connector lying around somewhere (USB to DB9F serial cable), but that won't fit.

Many thanks for helping out. This is just a quest for me to get rid of the ADM OS and run btrfs. :)

mafredri commented 11 months ago

The thing holding me back is that once I disable the asloader.efi on the built-in flash, there is no turning back.

Yeah, that can be scary. That's why I mentioned the [USB Copy]-button work-around for forcing asloader.efi to be loaded from USB (USB drive needs to be put in a BACK-side USB port, though, front wont work). This way there's no need to disable the internal asloader.efi.

If you look at the debian.md document I shared, you can see examples of grub.cfg that use the preseed. Obviously there's no telling if my old preseed will work with the version you're using now, though.

Ogglord commented 11 months ago

Yes, but you had /cdrom/preeseed.cfg in the grub.cfg and then a comment saying /cdrom/preeseed.cfg = (usb)/preeseed.cfg that I don't fully understand. Is that a change I should do to my config (in verbatim) or is /cdrom/ a special path that actually points to the root of the USB? :) Cheers

mafredri commented 11 months ago

@Ogglord I don't remember the context anymore, but I do believe it's the latter, place it in the root of your USB (and keep /cdrom in the grub config) 👍🏻

mafredri commented 11 months ago

I moved this issue to the asustor_as-6xxt repo and I updated https://github.com/mafredri/asustor_as-6xxt/blob/3ff72034e6a08693789f52b0ddddbf5cd8286970/debian.md, perhaps it's a bit clearer now.

I can't fully recall what partition/fs layout I used on the USB drive when creating this. But I suspect formatting it vfat should do the trick, or you could try with fat32, ext (2 or 4). I'm pretty sure asloader.efi needs to be on vfat/fat32 for the firmware to be able to boot it, though. You could potentially have two partitions, first one (EFI) formatted fat32, and second one ext2.

Ogglord commented 11 months ago

Thanks! I will give this a go once I get my serial connection set up

Ogglord commented 11 months ago

I got my connection working today, serial working

I was surprised to see it's looking for /boot/grubx64.efi instead of /boot/asloader.efi first try boot

mafredri commented 11 months ago

Congrats, and thanks for sharing @Ogglord. Interesting find with the EFI path. Perhaps you’ve received a BIOS update at some point that changed it or then it’s because of a newer/different motherboard. If it was due to an update it must’ve happened later after I stopped using ADM.

But essentially, for all instructions that mention asloader.efi, you just need to change them for the filename you have there 👍

Ogglord commented 11 months ago

I'm running Debian 11 now, a boot takes roughly 4 minutes. It's slow but not near what you experienced with the cpu crawling on random boots, right? The installation was super sluggish, and apt update too. I wasn't expecting that.

To my real issue. I got grub on an USB stick but I can't for the life of me get grub to load the kernel + initram from my ext4 / partition (on an SSD in bay 1). I am stuck at the grub rescue, and when i try ls (hdx,gptx)/ it always says error: unknown filesystem..

I know it's more a classic grub issue. But I wonder if you have some experience of this? I have been reading forums for hours with no success.

The way I am able to boot into debian now is to have another external usb-stick with both grub2 and initram and the kernel on it. But for each kernel update I need to manually copy the new images.

PS. @mafredri after installing debian, it was very odd, on the first boot it ignored my new grub stick with grubx64.efi. I had to copy it again to asloader.efi for it to boot. I now always have these side-by-side...

mafredri commented 11 months ago

@Ogglord how much RAM do you have in the NAS? In my experience using the RAM expansion slot or >2GB of RAM in the NAS results in problems. I've had the best success when replacing the 1GB RAM in the internal RAM slot with a 2GB stick and nothing more than that. Otherwise I would usually experience the "slow system" behavior, either at boot or later.

(I tried many things to make more RAM work, including trying to prevent kernel from accessing certain areas, but nothing I tried worked.)

You may need to pull out the motherboard to replace the internal RAM, can't remember if that was necessary or not.

Very peculiar that the EFI changed from grubx64.efi to asloader.efi. 🤯

So one peculiarity about the shitty firmware on the AS-6XXT is that it doesn't properly initialize HDDs on boot, meaning grub won't be able to access them. So you have to boot the kernel/grub from either the USB or from the internal flash. Those drives will only be available once the kernel initializes them.

PS. Also check your boot options: https://github.com/mafredri/asustor_as-6xxt/blob/main/boot.md#now

Ogglord commented 11 months ago

I backed up the internal flash and repurposed it for my /efi and /boot and now I'm able to boot and update kernel etc without manual intervention at least.

I have 1GB + 2GB in the expansion slot. Will try your suggestion and put the 2GB stick in the primary slot.

Ogglord commented 11 months ago

You were spot on (as always). With only the 2GB stick the boot time reduced from 4 min to approx 40 sec. And its as snappy as I should expect a fresh debian 11 should be on this hardware.

mafredri commented 11 months ago

You were spot on (as always). With only the 2GB stick the boot time reduced from 4 min to approx 40 sec. And its as snappy as I should expect a fresh debian 11 should be on this hardware.

Fantastiskt! Do you recall btw if ADM was performant on 3GB RAM? I wonder if they had some kernel patches in place to make it alright. IIRC they had not at least fixed it in their grub bootloader even though they used a patched version of that as well. At one point I was experimenting with using that one for booting but that didn’t make a difference.

Ogglord commented 11 months ago

I was also thinking if this was the case when I ran ADM. Everyday stuff like opening a shell prompt took like 1.5 sec and felt slow. So in that sense the sluggishness was similar. I was not compiling stuff or doing compute the same way since that wasnt possible. But I am inclined to think they had not solved it either..

tehkillerbee commented 11 months ago

Out of curiosity, has anyone tried specifying the boot options mentioned in the boot.md docs?

mem=4G snd_hda_instel.bdl_pos_adj=8

The Thecus W4000 NAS, also using D2701 CPU apparently officially supports up to 4 GB RAM so there must be a way...

mafredri commented 11 months ago

I was also thinking if this was the case when I ran ADM. Everyday stuff like opening a shell prompt took like 1.5 sec and felt slow. So in that sense the sluggishness was similar. I was not compiling stuff or doing compute the same way since that wasnt possible. But I am inclined to think they had not solved it either..

Thanks for confirming, this was my suspicion as well (that it wasn't solved).

Out of curiosity, has anyone tried specifying the boot options mentioned in the boot.md docs?

mem=4G snd_hda_instel.bdl_pos_adj=8

The Thecus W4000 NAS, also using D2701 CPU apparently officially supports up to 4 GB RAM so there must be a way...

Yes, I've experimented a lot with different boot options and RAM combinations. You can totally use 4 GB of RAM by placing 2GB in each slot on the motherboard, but you will unfortunately suffer a very slow system. I don't think this is an issue with the CPU, I think it's the ASUSTOR firmware that's broken. Essentially my theory is that when using >2GB of RAM, some hardware is assigned memory addresses that conflict with the memory addresses that the kernel see as free. And as those are being used for the kernel, results in the hardware slowing to a crawl. I could be wrong and I never managed to prove my theory, though.

Ogglord commented 11 months ago

Yes, in short, that made no difference. I was booting the grub below before (with 3GB ram) and after (with 2GB ram) when I experienced the speed boost.

...
serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1
terminal_input serial
terminal_output serial

### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/15_zabbly ###

menuentry 'Debian (Zabbly 6.5.3)' {
    insmod ext2
    insmod fat
    insmod part_msdos
    insmod part_gpt
        set root='hd0,gpt2'
        echo    'Loading /boot/vmlinuz ...'
        linux   /vmlinuz-6.5.3-zabbly+ root=/dev/sda1 ro console=tty0 console=ttyS0,115200n8 acpi_enforce_resources=lax mem=4G snd_hda_instel.bdl_pos_adj=8
        echo    'Loading initial ramdisk ...'
        initrd  /initrd.img-6.5.3-zabbly+
}
### END /etc/grub.d/15_zabbly ###
dkpost3 commented 10 months ago

2023-10-03_14-53-54 4gb 1600Mhz - it works for six months without complaints - the flight is normal. 8gb - error read memory signal :)