guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GuixSD bootable ISO-9669 image


From: ng0
Subject: Re: GuixSD bootable ISO-9669 image
Date: Tue, 2 May 2017 12:53:02 +0000

Ludovic Courtès transcribed 5.2K bytes:
> Hi!
> 
> I just tested your patch, Danny (last version attached): I took the
> image at
> <http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-8.7.1-amd64-netinst.iso>
> and then did:
> 
> --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 = "Debian 8.7.1 amd64 1"
> scheme@(gnu build file-systems)> (iso9660-superblock-uuid sb)
> $3 = #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 = 17
> scheme@(gnu build file-systems)> (uuid->string $3)
> $5 = "32303137-3031-3136-3131-303130313030"
> --8<---------------cut here---------------end--------------->8---
> 
> Seems to work!
> 
> Could you clarify the two “See grub” in here:
> 
> --8<---------------cut here---------------start------------->8---
> (define (iso9660-superblock-uuid sblock)
>   "Return the Volume ID of a iso9660 superblock SBLOCK as a 4-byte 
> bytevector."
>   ;; 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))
> 
> ;; FIXME make result human-readable (See grub).
> ;(define (iso9660-uuid->string uuid)
> --8<---------------cut here---------------end--------------->8---
> 
> Should ‘iso9660-uuid->string’ be different from ‘uuid->string’?
> 
> 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=big-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!
> 
> Ludo’.
> 



-- 
https://pragmatique.xyz
PGP: https://people.pragmatique.xyz/ng0/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]