[How-To] Boot Entirely from SATA

This forum is for all other ARMv5 devices

Re: [How-To] Boot Entirely from SATA

Postby WarheadsSE » Fri Jan 03, 2014 2:35 pm

I have the 900Mhz in the tarball for sata boot.
Core Developer
Remember: Arch Linux ARM is entirely community donation supported!
WarheadsSE
Developer
 
Posts: 6807
Joined: Mon Oct 18, 2010 2:12 pm

Re: [How-To] Boot Entirely from SATA

Postby niedi74 » Tue Jan 14, 2014 8:52 pm

just look in again , i only see 700 - 850 in ./stage1 folder ... ?

how can i get the 900, this would help for my little project ;)

thx
karsten
niedi74
 
Posts: 14
Joined: Mon Dec 23, 2013 7:32 am

Re: [How-To] Boot Entirely from SATA

Postby mrhuge » Wed Jan 15, 2014 3:09 am

[EDIT: You can pretty much ignore this post in favor of the much longer one beneath it]

I'm afraid this might be a pretty dumb question, but here goes...

I'm trying to follow these instructions to SATA-boot a "classic" POGO-B01. I have Arch installed on it (via USB stick) using moonman's oxnas-rootfs-2013-06.tar.gz from the "last best rootfs" thread. I'm wondering if I should be using that tarball again instead of ArchLinuxARM-oxnas-latest.tar.gz that's linked in this thread's OP.

Or is the modified rootfs only needed for USB stick installations?


[EDIT: After posting that question I decided to just give it a try with the (newer, I think?) oxnas-rootfs-2013-06.tar.gz. It didn't work at first, but after applying the fix that glombus(?) posted (re-doing the dd write of uImage.nopci), I'm up and running just fine as far as I can tell. I'll leave the post here in case someone wants to warn me that I've just done something stupid (or pointless), but right now I think I'm in good shape. Yay.]


thanks for everything in this thread -I'm learning a lot...
Last edited by mrhuge on Thu Jan 16, 2014 5:23 am, edited 1 time in total.
mrhuge
 
Posts: 15
Joined: Sat Jan 19, 2013 8:56 pm

Re: [How-To] Boot Entirely from SATA

Postby mrhuge » Thu Jan 16, 2014 5:22 am

OK, I have succeeded in booting my POGO-B01 from an old 320G SATA drive. I then tried to get it to boot with my 3TB SATA, and I could get it to boot, but only with the drive formatted with fdisk, hence only 2TB available. I'm using a Tt BlacX dock, which others seem to be having good luck with, and has been working fine with 3TB on Windows for a year or so.

I've tried a *lot* of the suggestions and fixes that have worked for people in this and several other threads, and I think I have to just start over from scratch. I have some basic questions about which of the different threads/posts I have seen apply to me or are the right things to try ... I realize this is not an exact science and everyone is doing a bit of trial & error, but I'm guessing that some of the choices that freeze me up are obvious to more experienced modders (ie 95% of you)...

1. I'm booting from SATA and bypassing the NAND, so I need to follow Warhead's instructions here, correct? But it seems that some adjustments need to be made, both for the passage of time and because I'm trying to boot from 3TB...

2. Warhead gives instructions for creating a dos-compatible partition table using "fdisk -c=dos", but I need a Hybrid setup to boot with a 3TB drive, right? The instructions I've found here for creating a hybrid MBR use "GPT FDisk", and I don't see anything in there about dos-compat. I can open the device in fdisk after partitioning and enter the "c" command, but it doesn't seem to "stick", and I'm not sure it's correct to set it after the fact anyway. Also there's a post from moonman saying "Gdisk works fine", which makes me wonder if the whole issue is moot. Can anyone offer guidance about the dos-compatibility issue?

3. I've been using the oxnas-rootfs-2013-06.tar.gz from the "last best rootfs" thread, and it seems to be working - is that the right choice for a b01?

4. In this thread, which is quite recent and specifically deals with the POGO-B01, the poster had success by taking lib/* & uImage.nopci (kernel) from the update-oxnas.tar.gz tarball, as described in this thread. I don't know whether I should follow his lead - I didn't when I first got my small SATA drive to boot, and I wonder if that step is not needed with the "last best rootfs".


Yikes! That's a lot of hyperlinks & threads.

I think if I went to Burger King and worked for $5/hr for as many hours as I've put into this I would have enough to buy a super-fancy one-button NAS enclosure requiring zero configuration. Where's the fun in that?


Thanks for all the information in this forum that is making my brain explode - and thanks in advance for any assistance you might offer...
mrhuge
 
Posts: 15
Joined: Sat Jan 19, 2013 8:56 pm

Re: [How-To] Boot Entirely from SATA

Postby WarheadsSE » Thu Jan 16, 2014 12:41 pm

Ignore the dos compatibility flag.
Core Developer
Remember: Arch Linux ARM is entirely community donation supported!
WarheadsSE
Developer
 
Posts: 6807
Joined: Mon Oct 18, 2010 2:12 pm

Re: [How-To] Boot Entirely from SATA

Postby mrhuge » Thu Jan 16, 2014 11:58 pm

OMFG it boots! IT BOOTS!

I'm not entirely sure why it worked this time and not before, and I'm not entirely sure that I haven't done something that will come back to bite me in the ***** later. I *am* entirely sure that this is *not* the most efficient, elegant or probably safe way to make this work, but here's what I did in case it helps anyone (or in case someone more knowledgeable sees something I did wrong that is likely to cause me a problem) :

I had a 320G SATA drive that I had working as a boot drive, due to the instructions and suggestions and hard work of WarheadSE and others in this (and other) threads. That drive was entirely MBR, and only had three small partitions: sda1 (kernel) unformatted, 29MiB; sda2 (rootfs) ext3, 3.0GiB; sda3 (data) ext3, 2.7GiB (sizes completely arbitrary & could be smaller).

Using a desktop Arch system, I cloned that drive onto my 3TB drive using dd. I used count= so that I wouldn't have to wait for 320G to transfer since I only cared about 6G - but got the units wrong so it copied 50G, oh well. (This is OK, right? With a drive freshly formatted to use 6G, I can be confident that if I use dd to clone the "first" 10G, I will get everything I care about? Not exactly an expert on physical disk design/architecture)

I took it over to my POGO-B01 and verified that it booted just fine. Opening it with fdisk gave the usual error about the disk being too large, but showed the partitions as expected. gdisk complained about a CRC error, which I'm guessing was due to me cloning a partition table onto a different and bigger disk, but also showed the partitions. gdisk wanted to write a GPT but I exited without writing anything.

I took it back to my desktop Arch and ran gdisk (where I got no complaints about CRC errors - maybe running gdisk on the pogo did some repair even though I didn't write?), converting it to a hybrid GPT/MBR, "hybridizing" partitions 1 & 2. gdisk asks several questions at this point and I really had to just make my best guess at some of them (with a little help from this page): whether to put the 0xEE partition at the start of the MBR (chose no), set the bootable flag (chose yes for both), enter an MBR hex code (chose the default for both), whether to use unpartitioned space to protect more partitions (chose no, but in retrospect it's probably better to choose yes - not sure if it matters).

I then ran disk_create on the disk, thinking that maybe the kernel and Stage1 data was not surviving the conversion to hybrid partition table. It occurs to me that I could be making a dangerous assumption here - that the kernel which is written into the MBR (?) will not get corrupted somehow on a hybrid MBR/GPT disk. Please inform me if I've created a disaster waiting to happen, but for the moment things look good.

Here is the gdisk & fdisk output:

$this->bbcode_second_pass_code('', '[root@alarm ~]# gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
MBR: hybrid
BSD: not present
APM: not present
GPT: present

Found valid GPT with hybrid MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): D71FC530-8ED5-42FA-9320-FB7D68D64255
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 7387 sectors (3.6 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 61440 29.0 MiB 8300 Linux filesystem
2 63488 6291456 3.0 GiB 8300 Linux filesystem
3 6293504 12000000 2.7 GiB 8300 Linux filesystem
4 12001280 5860533134 2.7 TiB 8300 Linux filesystem

')

$this->bbcode_second_pass_code('', '

[root@alarm ~]# fdisk /dev/sda

WARNING: The size of this disk is 3.0 TB (3000592982016 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID
partition table format (GPT).


The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
Welcome to fdisk (util-linux 2.23.1).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p

Disk /dev/sda: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x00008000

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 61440 29696+ 83 Linux
/dev/sda2 * 63488 6291456 3113984+ 83 Linux
/dev/sda3 1 2047 1023+ ee GPT
Partition 3 does not start on physical sector boundary.

Partition table entries are not in disk order

')

As always, thanks heaps for the work put in to this great resource, and for the replies to my fumbling questions.
mrhuge
 
Posts: 15
Joined: Sat Jan 19, 2013 8:56 pm

Previous

Return to Community Supported

Who is online

Users browsing this forum: No registered users and 6 guests