all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: guix-devel@gnu.org
Subject: Re: Installer, ISO9660, etc.
Date: Sun, 09 Jul 2017 22:08:46 +0200	[thread overview]
Message-ID: <877ezhv0dt.fsf@gnu.org> (raw)
In-Reply-To: <20170707181315.2f998f1d@scratchpost.org> (Danny Milosavljevic's message of "Fri, 7 Jul 2017 18:13:15 +0200")

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Fri, 07 Jul 2017 13:34:52 +0200
> ludo@gnu.org (Ludovic Courtès) wrote:
>
>> Danny Milosavljevic <dannym@scratchpost.org> skribis:
>> 
>> > 95% done.  If would actually work if we came to a consensus about the volume label (it must be uppercase; see bug# 27520 in guix-patches).  Also, UUID boot support is still mostly missing - same as in the non-iso9660 case.  
>
>>I hope I’m not holding anything back in this area!
>
> Oh, not at all.  I'm just not clear on which way we chose (if any?).
>
> What was the string-upcase solution?  Even if it's created with (string-upcase "GuixSD") (and it is - if you don't override it) the boot code as it is now will still fail to find the root - because it matches labels case-sensitively.  The string-upcase is buried deep within the image creation procedure.

Right.

> Or do you mean I should put (string-upcase "GuixSD") in system-disk-image in gnu/system/vm.scm as well ? That would work, I guess... although the finished image (iso9660 or not!) would still have "GUIXSD" then.  I don't see that as a big deal, though :)
>
> There's still the following places:
>
> ./gnu/build/vm.scm:                    search --set=root --label gnu-disk-image~@
> ./gnu/system/install.scm:              (device "gnu-disk-image")
> ./gnu/system/vm.scm:    "gnu-disk-image")
>
> Or do you mean we should just match case-insensitively in gnu/build/file-systems.scm ?
>
> I.e. use
>
>  (define partition-label-predicate
>   (partition-predicate read-partition-label string-ci=?))
>
> That would mean match case-insensitively for both iso9660 and non-iso9660.  I would very much prefer this fix.

What about this not-so-bad solution:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 974 bytes --]

diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index 3e722d081..662fd0085 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -335,11 +335,18 @@ the image."
 system described by OS.  Said image can be copied on a USB stick as is.  When
 VOLATILE? is true, the root file system is made volatile; this is useful
 to USB sticks meant to be read-only."
+  (define normalize-label
+    ;; ISO labels are all-caps (case-insensitive), but since
+    ;; 'find-partition-by-label' is case-sensitive, make it all-caps here.
+    (if (string=? "iso9660" file-system-type)
+        string-upcase
+        identity))
+
   (define root-label
     ;; Volume name of the root file system.  Since we don't know which device
     ;; will hold it, we use the volume name to find it (using the UUID would
     ;; be even better, but somewhat less convenient.)
-    "gnu-disk-image")
+    (normalize-label "gnu-disk-image"))
 
   (define file-systems-to-keep
     (remove (lambda (fs)

[-- Attachment #3: Type: text/plain, Size: 396 bytes --]


That way we preserve case-sensitivity for the other file systems.

If that’s fine with you, let’s do that!

Longer-term we should probably create <file-system> records for each
file system in (gnu build file-system); this would include, for each
file system, the ‘superblock?’ procedure, the ‘label’ procedure, and,
probably, a ‘label=?’ procedure.

Thanks,
Ludo’.

  reply	other threads:[~2017-07-09 20:08 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27 22:16 Looking to contribute cinder88
2017-06-28 13:49 ` Danny Milosavljevic
2017-06-28 15:01   ` Leo Famulari
2017-06-29 15:49     ` Danny Milosavljevic
2017-06-29 17:02       ` Mekeor Melire
2017-07-01 13:15         ` Deleting system generations Ludovic Courtès
2017-07-01 15:32           ` Thomas Danckaert
2017-07-02 20:22             ` Ludovic Courtès
2017-06-29 13:22   ` Looking to contribute cinder88
2017-06-29 13:46     ` Katherine Cox-Buday
2017-06-29 15:25     ` Alex Vong
2017-06-29 16:42     ` Pjotr Prins
2017-07-02 23:30     ` Binding generator, for Guile, to C libraries Danny Milosavljevic
2017-07-04  0:41       ` Installer development Danny Milosavljevic
2017-07-05 21:53       ` Binding generator, for Guile, to C libraries Ludovic Courtès
2017-07-06 19:57         ` Danny Milosavljevic
2017-07-07 11:41           ` Ludovic Courtès
2017-07-05 13:20   ` Looking to contribute Danny Milosavljevic
2017-07-07 11:34     ` Installer, ISO9660, etc Ludovic Courtès
2017-07-07 16:13       ` Danny Milosavljevic
2017-07-09 20:08         ` Ludovic Courtès [this message]
2017-07-10 13:41           ` Danny Milosavljevic
2017-07-10 21:02             ` Ludovic Courtès
2017-07-10 21:27               ` Danny Milosavljevic
2017-07-11  9:23                 ` Ludovic Courtès
2017-07-11 10:13                   ` Danny Milosavljevic
2017-06-28 13:56 ` Looking to contribute Alex Vong
2017-06-28 17:41 ` James Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877ezhv0dt.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=dannym@scratchpost.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.