On Tue, 2 Feb 2021 15:29:12 +0100, Sebastien Marie <sema...@online.fr>
wrote:
> On Mon, Feb 01, 2021 at 08:30:17PM -0500, Daniel Jakots wrote:
> > On Mon, 01 Feb 2021 18:18:43 -0700, "Theo de Raadt"
> > <dera...@openbsd.org> wrote:
> >
> > > Should rdsetroot be able to edit gzip'd files? I am not sure
> > > about that.
> >
> > Yeah, I don't think so either. gzip(1) can be easily used to
> > uncompress it beforehand.
> >
> > But the result is still that rdsetroot on -current is not able to
> > extract a bsd.rd even when given an uncompressed bsd.rd (i.e. a "ELF
> > 64-bit LSB executable, x86-64, version 1" bsd.rd).
> >
>
> I looked at what it is done for amd64/ramdisk_cd
>
> bsd.rd target is made from bsd (kernel) + mr.fs (rdboot filesystem)
> with rdsetroot(8) bsd.gz target is made from bsd.rd with strip(1) +
> gzip(1).
>
> with current method, it is bsd.gz which is installed in RELEASEDIR as
> bsd.rd file.
>
>
> the problem is rdsetroot(8) doesn't support extracting the mr.fs part
> from image when the image is stripped: it expects to find
> "rd_root_size" and "rd_root_image" symbols to locate the size and the
> offset of the mr.fs part inside the image.
>
> It is possible to use strip with -K rd_root_size -K rd_root_image
> option to preserve these specifics symbols (and make rdsetroot -x to
> work again). I tested it successfully on i386.
>
> diff a6394f126ec0ed0606e8aac07a82ab1a4c4f2988
> /home/semarie/repos/openbsd/src blob -
> 77fdc3e10fc525e725a40528b728c06976eefc06 file +
> distrib/i386/ramdisk_cd/Makefile --- distrib/i386/ramdisk_cd/Makefile
> +++ distrib/i386/ramdisk_cd/Makefile
> @@ -56,8 +56,8 @@ MRMAKEFSARGS= -o
> disklabel=${MRDISKTYPE},minfree=0,den
> bsd.gz: bsd.rd
> cp bsd.rd bsd.strip
> - strip bsd.strip
> - strip -R .comment -R .SUNW_ctf bsd.strip
> + strip -K rd_root_size -K rd_root_image bsd.strip
> + strip -K rd_root_size -K rd_root_image -R .comment -R
> .SUNW_ctf bsd.strip gzip -9cn bsd.strip > bsd.gz
>
> bsd.rd: mr.fs bsd
>
> Please note that the second strip call need -K option too, else the
> symtab is removed. I am a bit surprised by this behaviour.
>
> I am unsure I will be able to provide a patch for all
> architectures. Please comment if the direction is right or not.
>
> Thanks.
Thanks for looking at it!
I built a release (without the xenocara part) to test a similar diff to
yours for amd64 (I didn't know which bsd.rd was which, so I did both):
Index: ramdiskA/Makefile
===================================================================
RCS file: /cvs/src/distrib/amd64/ramdiskA/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- ramdiskA/Makefile 18 May 2020 06:20:43 -0000 1.10
+++ ramdiskA/Makefile 5 Feb 2021 19:01:06 -0000
@@ -36,8 +36,8 @@ MRMAKEFSARGS= -o disklabel=${MRDISKTYPE}
bsd.gz: bsd.rd
cp bsd.rd bsd.strip
- strip bsd.strip
- strip -R .comment -R .SUNW_ctf bsd.strip
+ strip -K rd_root_size -K rd_root_image bsd.strip
+ strip -K rd_root_size -K rd_root_image -R .comment -R .SUNW_ctf
bsd.strip
gzip -9cn bsd.strip > bsd.gz
bsd.rd: mr.fs bsd
cvs server: Diffing ramdisk_cd
Index: ramdisk_cd/Makefile
===================================================================
RCS file: /cvs/src/distrib/amd64/ramdisk_cd/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- ramdisk_cd/Makefile 5 Jan 2021 15:10:42 -0000 1.24
+++ ramdisk_cd/Makefile 5 Feb 2021 19:01:06 -0000
@@ -59,8 +59,8 @@ MRMAKEFSARGS= -o disklabel=${MRDISKTYPE}
bsd.gz: bsd.rd
cp bsd.rd bsd.strip
- strip bsd.strip
- strip -R .comment -R .SUNW_ctf bsd.strip
+ strip -K rd_root_size -K rd_root_image bsd.strip
+ strip -K rd_root_size -K rd_root_image -R .comment -R .SUNW_ctf
bsd.strip
gzip -9cn bsd.strip > bsd.gz
bsd.rd: mr.fs bsd
And it works:
$ doas cp /home/RELEASEDIR/bsd.rd .
$ mv bsd.rd bsd.rd.gz
$ gunzip bsd.rd.gz
$ doas rdsetroot -x bsd.rd disk.fs
$ file disk.fs
disk.fs: Unix Fast File system [v1] (little-endian), last mounted on , last
written at Fri Feb 5 18:06:46 2021, clean flag 1, number of blocks 7360,
number of data blocks 7071, number of cylinder groups 1, block size 4096,
fragment size 512, minimum percentage of free blocks 0, rotational delay 0ms,
disk rotational speed 60rps, SPACE optimization
Thanks,
Daniel
