@Thematic

Your vars are set the same as mine where it counts. Some things I noticed though:

Quote:

boot1=ssii boot2=ssiicdrom

This will boot your HD and if that fails your CD ROM.

Quote:

boota_scan_all_HDD=on rescan_bootunits=on

I don't have these set.

Apart from that I wonder if SLB can read a menu off an SATA 3112 controler. Where are the docs for SLB!?

Last edited by Hypex on 19-Nov-2012 at 01:21 PM.

@Hypex

SLB does work with a SATA 3112. I have used on on my Sam460ex.


Quote:

Apart from that I wonder if SLB can read a menu off an SATA 3112 controler. Where are the docs for SLB!?

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Spectre660

To boot Linux? Using the a1boot method?

@Hypex

I'm probably repeating myself but the HDD used to be on the SATA controller, and that worked fine.

_________________
: AmigaOneXE (unmod.) 750FX/512 MB +stuff & AmigaOS 4.(0|1)
: A1200/68060&96MB/SCSI/EM1200-Voodoo3 & OS 3.5
: A500/1MB
: Pegasos (ff) 512 MB & MorphOS
Praise seitan.

@Thematic

So where is the HDD now? Is your preferred layout using just the SATA drives?

I just checked my volumes and I have Automount set for my Linux volume. So perhaps try that as well.

Apart from that, I think we went over it, but check that the HDD with the Linux volume on it is the only one with the A1 SLB booter. IIRC the SLB will only check for Linux on the HDD it is installed onto.

@Thematic

This problem may be solved. Thanks to Geri and Scabit working at it to sort it out. Looks like an inode setting. See here:

http://sourceforge.net/p/amigaone-linux/wiki/AmigaOne_Linux_Bootloader_Specification/

@Hypex

Grand! So this stemmed from using a "too new" kernel. For which a workaround is presented (it worked!).

Thanks.

Last edited by Thematic on 05-May-2013 at 10:57 PM.

_________________
: AmigaOneXE (unmod.) 750FX/512 MB +stuff & AmigaOS 4.(0|1)
: A1200/68060&96MB/SCSI/EM1200-Voodoo3 & OS 3.5
: A500/1MB
: Pegasos (ff) 512 MB & MorphOS
Praise seitan.

@Thematic

It looks like it. Of course a filesystem must be destroyed and recreated in order to fix it but at least now we know.

It is also hard to fix as generally a SLB will use the UBoot routines to read an Ext2 filesystem. So we have to work around dated routines. It also means I need make sure my installer formats using this method.

@Thematic

Quote:

Thematic wrote: @Hypex Grand! So this stemmed from using a "too new" kernel. For which a workaround is presented (it worked!).

Not directly from a too new kernel, but from a wrongly configured mke2fs program.

@Hypex

Quote:

Hypex wrote: @Thematic It looks like it. Of course a filesystem must be destroyed and recreated in order to fix it but at least now we know.

Exactly!

Quote:

It is also hard to fix as generally a SLB will use the UBoot routines to read an Ext2 filesystem. So we have to work around dated routines. It also means I need make sure my installer formats using this method.

Yes, the installer needs to reformat the boot partition. For this we have to make sure that the installer can actually detect the right boot partition (otherwise it could destroy important data).

I was thinking about using disk labels to allow the user to mark a partition as a Linux boot partition. This way the installer has nothing more to do then simply retrieve its device name and reformat it, if it is not yet formatted with an inode size of 128 bytes. Otherwise it may already contain boot images for other Linux installation.

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -