FreeBSD/amd64 on ASUS Transformer T100 kconvertible tablet?
smithi at nimnet.asn.au
Mon Apr 28 05:26:04 UTC 2014
In freebsd-questions Digest, Vol 516, Issue 10, Message: 1
On Sat, 26 Apr 2014 15:08:51 +0200 "Alexander Shendi (Web.de)" <Alexander.Shendi at web.de> wrote:
> Hi all,
> On 25.04.2014 14:48, Matthias Apitz wrote:
> > El d?a Friday, April 25, 2014 a las 12:49:23PM +0200, Alexander.Shendi escribi?:
> > I would start this project with preparing a -CURRENT USB boot key with a
> > complete system on it; if you have not done this in the past, I could
> > help you with this and could send you a complete howto.
> > matthias
> I have downloaded
> from ftp.freebsd.org and copied it to an USB memory stick with dd(1).
> As expected the machine did not boot.
> I then examined the memory stick:
> Script started on Sa 26 Apr 2014 14:04:21 CEST
> root at alex-T100TA: ~root at alex-T100TA:~# fdisk -l /dev/sdb
> This disk has both DOS and BSD magic.
> Give the 'b' command to go to BSD mode.
Just to be clear for observers, this is output from Linux' fdisk ..
> Disk /dev/sdb: 1010 MB, 1010826752 bytes
> 255 heads, 63 sectors/track, 122 cylinders, total 1974271 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x90909090
> Device Boot Start End Blocks Id System
> /dev/sdb4 * 0 49999 25000 a5 FreeBSD
> root at alex-T100TA: ~root at alex-T100TA:~# gdik[K[K[K[K
> root at alex-T100TA: ~root at alex-T100TA:~# gdisk /dev/sdb
> GPT fdisk (gdisk) version 0.8.8
> Partition table scan:
> MBR: MBR only
> BSD: present
> APM: not present
> GPT: not present
> Found invalid GPT and valid MBR; converting MBR to GPT format
> in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
> typing 'q' if you don't want to convert your MBR partitions
> to GPT format!
> Warning! Main partition table overlaps the first partition by 34 blocks!
> You will need to delete this partition or resize it in another utility.
That is the key message .. see below.
> Command (? for help): p
> Disk /dev/sdb: 1974271 sectors, 964.0 MiB
> Logical sector size: 512 bytes
> Disk identifier (GUID): C096CAD9-9FDB-4978-AB1D-071C774593BE
> Partition table holds up to 128 entries
> First usable sector is 34, last usable sector is 1974237
> Partitions will be aligned on 2048-sector boundaries
> Total free space is 1924238 sectors (939.6 MiB)
> Number Start (sector) End (sector) Size Code Name
> Command (? for help): q
> root at alex-T100TA: ~root at alex-T100TA:~# lexit
> Script done on Sa 26 Apr 2014 14:06:14 CEST
> So to summarize:
> * The memory stick is not a GPT but an MBR disk.
> * Besides it contains only a single UFS partition
> * an MSDOS FAT parition with an "EFI" subdirectory is missing.
> So it is clear why the disk won't boot as the machine has no legacy BIOS
> which could boot an MBR disk.
Hopefully Matthew is right and you can work around that, but it needs
explaining that the FreeBSD bootable memsticks are peculiarly (and
unfortunately) made in what used to be called "Dangerously Dedicated"
mode, which Linux fdisk isn't going to be able to make any sense of.
Rather than it being an ordinary MBR disk with 4 slices (partitions to
DOS or Linux) where the first UFS partition would start at sector 63
(0-numbered), ie cyl 0, head 1, sector 1 in the old CHS view, instead
the bsdlabel overlaps the MBR so the UFS partition - here known not as
da0s1a but as da0a - actually starts right at sector 0 with the MBR
code, slice table and the bsd disklabel, boot code, everything.
The reasons for this are to do with the old sysinstall, in earlier days,
not being able to distinguish partitions on 'real' SCSI disks (da0s1, s2
etc) from memsticks (umass-sim) - though no such distinction has been
needed for many years - so this daXa format, derived from floppy disks,
was used to tell them apart so sysinstall's old USB code could be used
to read them rather than libdisk's code for SCSI disks, I understand.
I say this was and especially nowadays is still an unfortunate choice,
as it precludes being able to have up to 4 different bootable slices on
a single memstick, for example 9.2 and 10.0 releases for both amd64 and
i386, with boot0 in the MBR to select which to boot from. In that
format, your Linux fdisk could see it without problem - though I don't
know of any way to 'convert' an MBR slice/partition to a GPT one.
Equally unfortunately, nobody has yet written an equivalent to boot0
(also known as ezyboot) to allow GPT disks to select which of several
partitions to boot from - quite ironic when one of the stated reasons
for preferring GPT was the availability of many more partitions than the
6 x 4 slices = 24 (BSD) partitions, 4 bootable, available with MBR.
> So I have two more questions:
> * I know (by googleing) that a project to support UEFI Firmware boot
> FreeBSD exists.
> Can anyone point me to a ftp site or other resources.
Sorry, I've seen it mentioned but know nothing about it; all MBR here.
> * Can anyone enlighten me how to mount the memory stick, so I can extract
> the FreeBSD kernel (under Linux)? I tried:
> - mount -r -t ufs -o ufstype=old
> - mount -r -t ufs -o ufstype=sun
> - mount -r -t ufs -o ufstype=sunx86
> - mount -r -t ufs -o ufstype=bsd44
I don't think it will work under Linux, as it doesn't know about this
peculiar overlap. Once you can read it from another FreeBSD system (by
mounting /dev/da0a) then you could copy the partition, and perhaps copy
it back to its proper position on a memstick formatted as a normal MBR
disk; I don't think the boot code would be position-dependant, though I
can't state that with certainty. Anyone?
Hmm, I guess you could just use dd to copy it from sector 0 for as many
sectors as it occupies - noting that the 25000 blocks shown in MBR above
is also bogus, you should use the size of the memstick image divided by
512 bytes for sector count - and then dd it back to a properly formatted
MBR stick and use fdisk to set slice 1 active. I have NOT tried this ..
More information about the freebsd-questions