Re: Installing Debian Buster on Cubox-i4 with eSATA drive.

2021-01-28 Thread Rick Thomas



On Thu, Jan 28, 2021, at 12:08 AM, Rick Thomas wrote:
> On Wed, Jan 27, 2021, at 11:15 PM, Vagrant Cascadian wrote:
> > On 2021-01-27, Rick Thomas wrote:
> > > I'm trying to install Debian Buster [1] on my Cubox-i4P with an eSATA
> > > drive. Everything seems to be fine, but when it comes time to reboot,
> > > it boots into the installer again, rather than the installed system.
> > >
> > > Here's what I did, and what I observed:
> > >
> > > *) I downloaded the two parts of the SDcard install image from [1] and 
> > > followed the instructions in the README to create a 4GB (I didn't have 
> > > anything smaller) SDcard installer.
> > > *) I connected the eSATA disk and plugged the SDcard into the Cubox and 
> > > powered it up.
> > > *) It booted off the SD-card into the installer as expected.
> > ...
> > > *) But when the reboot happened, I found myself back in the installer.
> > > *) I tried removing the SDcard and rebooting, but it failed to boot -- 
> > > after power-on nothing happened.
> > 
> > > What I hoped would happen with the eSATA drive was that the installer
> > > would write the boot firmware (u-boot, etc) to the SDcard, and
> > > configure it to get /boot, root, /home, swap off the eSATA.
> > 
> > U-boot can only be loaded from microSD on that platform, as far as I'm
> > aware.
> > 
> > You can use the bootloader from the installer image, just delete the
> > boot.scr and/or extlinux.conf from the partition on the installer image,
> > or make another partition on the microSD card, and mark it bootable, but
> > don't put anything on it. Then u-boot should fall back to loading the
> > kernel+initrd+device-tree off of the eSATA.
> > 
> > If you interrupt the boot process and get to a u-boot prompt, you should
> > be able to see the order of devices u-boot tries to boot from with:
> > 
> >   printenv boot_targets
> > 
> > 
> > Now that bullseye is in the early phases of freeze, please consider
> > testing bullseye, too, if you can! :)
> 
> Thanks!  This sounds like it ought to work.  I'll give it a try.
> 
> For bullseye, where should I download the latest installer image from?  
> I'd love to give it a try as well!
> Rick

That worked!

Specifically, what I did was:
*) on a different machine, I mounted the installer SDcard first partition
*) renamed boot.scr to oboot.scr
*) sync and umount the SDcard.
*) inserted it in the Cubox
*) powered up and watched it boot from the eSATA disk.

Whoopie!

Observations:
*) => printenv boot_targets
   boot_targets=mmc0 sata0 usb0 pxe dhcp

*) It located the /boot partition on the eSATA drive without any help from me.  
I assume that means it goes down the list of boot_targets one by one looking 
for an active bootable partition containing a file called "boot.scr" which it 
then executes to perform the remainder of the boot process (mostly to load the 
kernel and initrd , then pass control to them).

*) I wonder if it would be possible to change the "boot_targets" environment 
variable to put "sata0" first?  Would that work, if it could be done?  If that 
were done, would it mess up booting from the SDcard when there was no eSATA 
drive?

So now, the next question is: how do we convince the debian installer to 
recognize that it's installing to the eSATA drive and either set "boot_targets" 
appropriately, or mark the boot partition on the SDcard as not bootable.

I've added "debian-boot" to the CC list of this email.  Should I file a bug 
report?  If so, what package should I file it against?

Next thing to test -- can I install bullseye the same way?

Thanks very much to everyone for all your help!
Rick



Re: bootcmd for buster on TS-209

2021-01-28 Thread Martin Michlmayr
* Luigi Bai  [2021-01-27 14:21]:
> So I think that can be done?

Karsten Sperling posted a message on how he made it work.  It seems
the message never made it to debian-arm but I'll forward it to you.

> If not, is there a reference for the u-boot commands so I can see how to
> put together a bootcmd using TFTP?

It's documented here: https://cyrius.com/debian/orion/qnap/ts-109/uboot/
You just need to set bootcmd accordingly.

-- 
Martin Michlmayr
https://www.cyrius.com/



Re: Re: Status of Debian on QNAP

2021-01-28 Thread Martin Michlmayr
It seems that message from Karsten Sperling never made it to
debian-arm.

* Karsten Sperling  [2020-12-30 13:33]:
> Thanks,
> 
> turns out overriding the MTD layout via the kernel command line works. In
> case anyone else finds this useful, these are the U-Boot environment
> settings I'm using to merge RootFS1 and RootFS2. I'm setting both mtd2 and
> mtd3 to be the combined RootFS1+2 (i.e. the two partitions overlap) so that
> mtd4 and 5 also keep their numbers / device names and no change is needed
> to fw_env.config or flash-kernel.
> 
> bootargs_mtdparts cmdlinepart.mtdparts="physmap-flash.0:512K@7680K
> (U-Boot)ro,2M@0(Kernel),5M@2M(RootFS1),5M@2M(RootFS2),128K@7552K(U-Boot
> Config),384K@7M(NAS Config)ro"
> fsargs setenv bootargs console=ttyS0,115200n8 root=/dev/ram rw
> initrd=0x80,0x50 $(bootargs_mtdparts)
> prefs cp.b 0xff20 0x80 0x50
> 
> It's probably a good idea to zero out RootFS2 (mtd3) before applying this
> as I'm not sure the kernel tolerates trailing garbage in the initrd.
> 
> For some reason the system still doesn't boot up correctly with the stock
> 4.19.0-13-marvell kernel though, but I didn't have time to look into why
> yet.
> 
> On Mon, 21 Dec 2020 at 22:44, Martin Michlmayr  wrote:
> 
> > * Karsten Sperling  [2020-12-16 12:06]:
> > > By pinning lvm to the stretch version I got the initrd to just below 5M,
> > so
> > > it would fit into a combined RootFS1+RootFS2 partition. It looks like on
> > > the u-boot side I would just need to bump the initrd size from 0x3f
> > > to 0x4f in the cp command and the kernel command line, but is there a
> > > way to override the partition table the kernel uses? The TS-209 doesn't
> > use
> > > a device tree.
> >
> > You'd have to edit arch/arm/mach-orion5x/ts209-setup.c and compile
> > your own kernel, but I'm not sure it's worth it.
> >
> > OTOH, since RootFS2 is right behind RootFS1, you could manually split
> > the ramdisk and write the first 4 MB to RootFS1 and the remaining 1 MB
> > to RootFS2.  This way, you could keep the Debian kernel and just need
> > to change u-boot.
> >
> > --
> > Martin Michlmayr
> > https://www.cyrius.com/
> >

-- 
Martin Michlmayr
https://www.cyrius.com/



Re: Installing Debian Buster on Cubox-i4 with eSATA drive.

2021-01-28 Thread Rick Thomas
On Wed, Jan 27, 2021, at 11:15 PM, Vagrant Cascadian wrote:
> On 2021-01-27, Rick Thomas wrote:
> > I'm trying to install Debian Buster [1] on my Cubox-i4P with an eSATA
> > drive. Everything seems to be fine, but when it comes time to reboot,
> > it boots into the installer again, rather than the installed system.
> >
> > Here's what I did, and what I observed:
> >
> > *) I downloaded the two parts of the SDcard install image from [1] and 
> > followed the instructions in the README to create a 4GB (I didn't have 
> > anything smaller) SDcard installer.
> > *) I connected the eSATA disk and plugged the SDcard into the Cubox and 
> > powered it up.
> > *) It booted off the SD-card into the installer as expected.
> ...
> > *) But when the reboot happened, I found myself back in the installer.
> > *) I tried removing the SDcard and rebooting, but it failed to boot -- 
> > after power-on nothing happened.
> 
> > What I hoped would happen with the eSATA drive was that the installer
> > would write the boot firmware (u-boot, etc) to the SDcard, and
> > configure it to get /boot, root, /home, swap off the eSATA.
> 
> U-boot can only be loaded from microSD on that platform, as far as I'm
> aware.
> 
> You can use the bootloader from the installer image, just delete the
> boot.scr and/or extlinux.conf from the partition on the installer image,
> or make another partition on the microSD card, and mark it bootable, but
> don't put anything on it. Then u-boot should fall back to loading the
> kernel+initrd+device-tree off of the eSATA.
> 
> If you interrupt the boot process and get to a u-boot prompt, you should
> be able to see the order of devices u-boot tries to boot from with:
> 
>   printenv boot_targets
> 
> 
> Now that bullseye is in the early phases of freeze, please consider
> testing bullseye, too, if you can! :)

Thanks!  This sounds like it ought to work.  I'll give it a try.

For bullseye, where should I download the latest installer image from?  I'd 
love to give it a try as well!
Rick