Re: armv7: newfs efi-partition in when choosing manual-fdisk mbr
On Sun, Nov 12, 2017 at 03:17:54PM +1100, Jonathan Gray wrote:
> On Fri, Nov 10, 2017 at 10:27:36AM +0200, Artturi Alm wrote:
> > Hi,
> >
> > currently, just editing the mbr to give more room for u-boot env growth,
> > will result in unbootable system, as the installer will fail to mount it,
> > and naturally things won't work beyond u-boot after reboot either.
> >
> > i'm not really sure about this diff, but it does seem like it might do,
> > what i think it should? might take a while, before i can test myself, so
> > i thought i'd mail and ask, if there's a reason for how it is atm.? :)
> >
> > -Artturi
>
> 0x0C is only used due to the broadcom boot rom not understanding
> EFI System partition (0xEF). That should not be set outside of arm*.
>
> As it is the partition is larger than it needs to be as kernels
> are no longer stored there.
>
> There is no reason to force MBR as both U-Boot and EDK2 should be able
> to cope with GPT.
>
ok, that explains a lot, so diff withdrawn, thanks.
maybe we could use some of the now-unused EFI-partition size for bigger
default partition offset? (ie. *2 to 4096(2MiB))
-Artturi
> >
> >
> > diff --git a/distrib/armv7/ramdisk/install.md
> > b/distrib/armv7/ramdisk/install.md
> > index 23d574e4e7a..1639e06c221 100644
> > --- a/distrib/armv7/ramdisk/install.md
> > +++ b/distrib/armv7/ramdisk/install.md
> > @@ -141,8 +141,14 @@ partition on the disk.
> > $(fdisk ${_disk})
> > __EOT
> > fdisk -e ${_disk}
> > - disk_has $_disk mbr openbsd && return
> > - echo No OpenBSD partition in MBR, try again. ;;
> > + disk_has $_disk mbr efi ||
> > + { echo No EFI(FAT id 0C) partition in MBR, try
> > again.; continue; }
> > + disk_has $_disk mbr efi_bootable ||
> > + { echo No bootable EFI partition in MBR, try
> > again.; continue; }
> > + disk_has $_disk mbr openbsd ||
> > + { echo No OpenBSD partition in MBR, try again.;
> > continue; }
> > + newfs -t ${bootfstype} ${newfs_args} ${_disk}i
> > + return ;;
> > esac
> > done
> > }
> > diff --git a/distrib/miniroot/install.sub b/distrib/miniroot/install.sub
> > index ef8c069588d..e204dd49d27 100644
> > --- a/distrib/miniroot/install.sub
> > +++ b/distrib/miniroot/install.sub
> > @@ -368,6 +368,8 @@ disk_has() {
> > local _p_mbr_openbsd='^..: A6 '
> > local _p_mbr_dos='^..: 06 '
> > local _p_mbr_dos_active='^\*.: 06 '
> > + local _p_mbr_efi='^..: 0C '
> > + local _p_mbr_efi_bootable='^\*.: 0C '
> > local _p_mbr_linux='^..: 83 '
> > local _p_sr='OPENBSD, SR'
> > local _p_sr_crypto='OPENBSD, SR CRYPTO'
> >
Re: armv7: newfs efi-partition in when choosing manual-fdisk mbr
On Fri, Nov 10, 2017 at 10:27:36AM +0200, Artturi Alm wrote:
> Hi,
>
> currently, just editing the mbr to give more room for u-boot env growth,
> will result in unbootable system, as the installer will fail to mount it,
> and naturally things won't work beyond u-boot after reboot either.
>
> i'm not really sure about this diff, but it does seem like it might do,
> what i think it should? might take a while, before i can test myself, so
> i thought i'd mail and ask, if there's a reason for how it is atm.? :)
>
> -Artturi
0x0C is only used due to the broadcom boot rom not understanding
EFI System partition (0xEF). That should not be set outside of arm*.
As it is the partition is larger than it needs to be as kernels
are no longer stored there.
There is no reason to force MBR as both U-Boot and EDK2 should be able
to cope with GPT.
>
>
> diff --git a/distrib/armv7/ramdisk/install.md
> b/distrib/armv7/ramdisk/install.md
> index 23d574e4e7a..1639e06c221 100644
> --- a/distrib/armv7/ramdisk/install.md
> +++ b/distrib/armv7/ramdisk/install.md
> @@ -141,8 +141,14 @@ partition on the disk.
> $(fdisk ${_disk})
> __EOT
> fdisk -e ${_disk}
> - disk_has $_disk mbr openbsd && return
> - echo No OpenBSD partition in MBR, try again. ;;
> + disk_has $_disk mbr efi ||
> + { echo No EFI(FAT id 0C) partition in MBR, try
> again.; continue; }
> + disk_has $_disk mbr efi_bootable ||
> + { echo No bootable EFI partition in MBR, try
> again.; continue; }
> + disk_has $_disk mbr openbsd ||
> + { echo No OpenBSD partition in MBR, try again.;
> continue; }
> + newfs -t ${bootfstype} ${newfs_args} ${_disk}i
> + return ;;
> esac
> done
> }
> diff --git a/distrib/miniroot/install.sub b/distrib/miniroot/install.sub
> index ef8c069588d..e204dd49d27 100644
> --- a/distrib/miniroot/install.sub
> +++ b/distrib/miniroot/install.sub
> @@ -368,6 +368,8 @@ disk_has() {
> local _p_mbr_openbsd='^..: A6 '
> local _p_mbr_dos='^..: 06 '
> local _p_mbr_dos_active='^\*.: 06 '
> + local _p_mbr_efi='^..: 0C '
> + local _p_mbr_efi_bootable='^\*.: 0C '
> local _p_mbr_linux='^..: 83 '
> local _p_sr='OPENBSD, SR'
> local _p_sr_crypto='OPENBSD, SR CRYPTO'
>
Re: armv7: newfs efi-partition in when choosing manual-fdisk mbr
On Fri, Nov 10, 2017 at 10:35:30PM +, Robert Peichaer wrote: > On Fri, Nov 10, 2017 at 10:27:36AM +0200, Artturi Alm wrote: > > Hi, > > > > currently, just editing the mbr to give more room for u-boot env growth, > > will result in unbootable system, as the installer will fail to mount it, > > and naturally things won't work beyond u-boot after reboot either. > > > > i'm not really sure about this diff, but it does seem like it might do, > > what i think it should? might take a while, before i can test myself, so > > i thought i'd mail and ask, if there's a reason for how it is atm.? :) > > > > -Artturi > > I do not know enough about the needed/supported armv7 filesystem layout. > The install notes talk about GPT and MBR partitioning, but the install.md > script only offers MBR. Obviously EFI boot is supported reading install.md > but from MBR. I thought that's only possible from a GPT partition. > > Anyways. I will happily help to get this right scripting wise. > But right now I don't know if this is the correct way to fix this. > > -- > -=[rpe]=- I don't think there's more to it than what can be seen from install.md md_prep_fdisk(): local bootparttype="C" local bootsectorstart="2048" local bootsectorsize="32768" and fdisk sd0: Disk: sd0 geometry: 1887/255/63 [30318592 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- *0: 0C 0 32 33 - 2 42 40 [2048: 32768 ] FAT32L 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: A6 2 42 41 - 1887 62 31 [ 34816:30283776 ] OpenBSD i'd be surprised, if anyone is currently running with anything different. i think one would have to know the exact bounds of whatever bootarm.efi was loaded from, to keep the fat partition working after MBR is written? if there is such usecase as preserve-efi-boot-partition_and_area-before-it, it should be behind (currently non-existing) oO-case, which would check only for the disk_has mbr openbsd, right? or? my diff was slightly inspired by macppc, which does newfs -t msdos unconditionally, for all cases, fwiw.. -Artturi
Re: armv7: newfs efi-partition in when choosing manual-fdisk mbr
On Fri, Nov 10, 2017 at 10:27:36AM +0200, Artturi Alm wrote: > Hi, > > currently, just editing the mbr to give more room for u-boot env growth, > will result in unbootable system, as the installer will fail to mount it, > and naturally things won't work beyond u-boot after reboot either. > > i'm not really sure about this diff, but it does seem like it might do, > what i think it should? might take a while, before i can test myself, so > i thought i'd mail and ask, if there's a reason for how it is atm.? :) > > -Artturi I do not know enough about the needed/supported armv7 filesystem layout. The install notes talk about GPT and MBR partitioning, but the install.md script only offers MBR. Obviously EFI boot is supported reading install.md but from MBR. I thought that's only possible from a GPT partition. Anyways. I will happily help to get this right scripting wise. But right now I don't know if this is the correct way to fix this. -- -=[rpe]=-
armv7: newfs efi-partition in when choosing manual-fdisk mbr
Hi,
currently, just editing the mbr to give more room for u-boot env growth,
will result in unbootable system, as the installer will fail to mount it,
and naturally things won't work beyond u-boot after reboot either.
i'm not really sure about this diff, but it does seem like it might do,
what i think it should? might take a while, before i can test myself, so
i thought i'd mail and ask, if there's a reason for how it is atm.? :)
-Artturi
diff --git a/distrib/armv7/ramdisk/install.md b/distrib/armv7/ramdisk/install.md
index 23d574e4e7a..1639e06c221 100644
--- a/distrib/armv7/ramdisk/install.md
+++ b/distrib/armv7/ramdisk/install.md
@@ -141,8 +141,14 @@ partition on the disk.
$(fdisk ${_disk})
__EOT
fdisk -e ${_disk}
- disk_has $_disk mbr openbsd && return
- echo No OpenBSD partition in MBR, try again. ;;
+ disk_has $_disk mbr efi ||
+ { echo No EFI(FAT id 0C) partition in MBR, try
again.; continue; }
+ disk_has $_disk mbr efi_bootable ||
+ { echo No bootable EFI partition in MBR, try
again.; continue; }
+ disk_has $_disk mbr openbsd ||
+ { echo No OpenBSD partition in MBR, try again.;
continue; }
+ newfs -t ${bootfstype} ${newfs_args} ${_disk}i
+ return ;;
esac
done
}
diff --git a/distrib/miniroot/install.sub b/distrib/miniroot/install.sub
index ef8c069588d..e204dd49d27 100644
--- a/distrib/miniroot/install.sub
+++ b/distrib/miniroot/install.sub
@@ -368,6 +368,8 @@ disk_has() {
local _p_mbr_openbsd='^..: A6 '
local _p_mbr_dos='^..: 06 '
local _p_mbr_dos_active='^\*.: 06 '
+ local _p_mbr_efi='^..: 0C '
+ local _p_mbr_efi_bootable='^\*.: 0C '
local _p_mbr_linux='^..: 83 '
local _p_sr='OPENBSD, SR'
local _p_sr_crypto='OPENBSD, SR CRYPTO'
