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’.
next prev parent 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.