From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: GuixSD bootable ISO-9669 image Date: Tue, 2 May 2017 12:53:02 +0000 Message-ID: <20170502125302.kczt4pflooesikx4@abyayala> References: <20170418141719.llp77itz7vyq5rij@abyayala> <87k26hwxt0.fsf@gmail.com> <8760i0m7vg.fsf@gnu.org> <87pog3u3ms.fsf@gmail.com> <87k26afl07.fsf_-_@gmail.com> <20170427190840.79bcaa76@scratchpost.org> <20170427220009.1d0d4607@scratchpost.org> <20170428101844.540ce399@scratchpost.org> <87efw7igen.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5XIy-0007Dc-Tw for guix-devel@gnu.org; Tue, 02 May 2017 08:53:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d5XIu-0007KP-B8 for guix-devel@gnu.org; Tue, 02 May 2017 08:53:24 -0400 Content-Disposition: inline In-Reply-To: <87efw7igen.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org Ludovic Court=C3=A8s transcribed 5.2K bytes: > Hi! >=20 > I just tested your patch, Danny (last version attached): I took the > image at > > and then did: >=20 > --8<---------------cut here---------------start------------->8--- > scheme@(guile-user)> ,m (gnu build file-systems) > scheme@(gnu build file-systems)> (define sb (read-iso9660-superblock "/= tmp/debian-8.7.1-amd64-netinst.iso.part")) > scheme@(gnu build file-systems)> (iso9660-superblock-volume-name sb) > $2 =3D "Debian 8.7.1 amd64 1" > scheme@(gnu build file-systems)> (iso9660-superblock-uuid sb) > $3 =3D #vu8(50 48 49 55 48 49 49 54 49 49 48 49 48 49 48 48 0) > scheme@(gnu build file-systems)> (bytevector-length $3) > $4 =3D 17 > scheme@(gnu build file-systems)> (uuid->string $3) > $5 =3D "32303137-3031-3136-3131-303130313030" > --8<---------------cut here---------------end--------------->8--- >=20 > Seems to work! >=20 > Could you clarify the two =E2=80=9CSee grub=E2=80=9D in here: >=20 > --8<---------------cut here---------------start------------->8--- > (define (iso9660-superblock-uuid sblock) > "Return the Volume ID of a iso9660 superblock SBLOCK as a 4-byte byte= vector." > ;; Note: The field is the volume creation time. > ;; FIXME Use only certain parts (See grub). > ;; FIXME treat "all 0" as invalid. > (sub-bytevector sblock 813 17)) >=20 > ;; FIXME make result human-readable (See grub). > ;(define (iso9660-uuid->string uuid) > --8<---------------cut here---------------end--------------->8--- >=20 > Should =E2=80=98iso9660-uuid->string=E2=80=99 be different from =E2=80=98= uuid->string=E2=80=99? >=20 > Anyway, I think we should polish and commit real soon. :-) Perhaps we > can add a note about endianness and assume little endian for now. Excuse me if I didn't pay much attention to the thread, I just flipped through all of it. Isn't that (little endian) the most common assumption most operation system have? I know that Gentoo defaults to little endian. https://packages.gentoo.org/useflags/search?q=3Dbig-endian And we don't support SuperH or similar Big Endian hardware. Or am I thinking about different reasons why the endianness here matters? > Thank you Danny! >=20 > Ludo=E2=80=99. >=20 --=20 https://pragmatique.xyz PGP: https://people.pragmatique.xyz/ng0/