Ludovic Courtès <l...@gnu.org> writes: > Hello! > > Divan Santana <di...@santanas.co.za> skribis: > >> Then do the install with this guile code: >> >> #+BEGIN_SRC scheme >> ;; two devices in raid0 striped with LUKS full disk encryption. >> (bootloader (grub-configuration (device "/dev/vdb"))) >> (mapped-devices (list >> (mapped-device >> (source (list "/dev/vdb1" "/dev/vdc1")) >> (target "/dev/md0") >> (type raid-device-mapping)) >> (mapped-device >> (source (uuid "fb29c6f6-b2c0-4c87-8651-4962b7125dc0")) >> (target "crypt") >> (type luks-device-mapping)))) >> #+END_SRC >> >> >> And this too: >> >> #+BEGIN_SRC scheme >> (file-systems (cons (file-system >> (device "root") >> (title 'label) >> (mount-point "/") >> (type "ext4")) >> %base-file-systems)) >> #+END_SRC >> >> >> The above fails. So tried another install with device like so > > Do you know how it fails?
No unfortunately I didn't document it at the time. Though I'll do a better job of it next time I give it a go and give feedback. > My guess is that you’d need to explicitly mark one of the mapped device > as depending on the other; this cannot be guessed. > > If you run “guix system shepherd-graph” on your config you’ll probably > see that there’s no such dependency. > > Currently dependencies among mapped devices cannot be expressed, but > that’s easy to fix (by providing a ‘dependencies’ field as in > ‘file-system’.) I'll give this a try thanks. >> That failed, I then tried the UUID method, via =blkid >> /dev/mapper/crypt=, get the UUID and did another install with this >> snippet instead: >> >> #+BEGIN_SRC scheme >> (file-systems (cons (file-system >> (device (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")) >> (title 'uuid) >> (mount-point "/") >> (type "ext4")) >> %base-file-systems)) >> #+END_SRC >> >> This fails with waiting for root device. > > Probably same problem as above. > > For now, using just RAID or just LUKS will work; it’s the combination > that’s not supported yet. >> * How to recover a failed install. How to chroot a broken system and >> fix? >> >> You can see why I'm asking this. When my failed crypt install fails, I >> sometimes just want to reconfigure the system to try another method. >> >> Now when I run =guix system init /mnt/etc/config.scm /mnt= to recover >> the install to the same preveiously install disk it re-downloads, >> re-compiles and redoes the whole install, instead of just perhaps >> changing grub to (attempt to) fix my crypt issue. >> >> Ideally I want to chroot into the installed (and broken) environment and >> do a =guix system reconfigure /etc/config.scm=. >> >> How can one do this? > > I guess you could boot the install image, mount the target file system, > chroot in it, run guix-daemon in there, and run ‘guix system > reconfigure’ there. > > That should work though that’s inconvenient at best. I'll give it a try and let you know. >> * How to use a proxy to do the install >> >> This is from the boot install media. >> >> I've read the docs on using proxy though it's not working like I expect. >> Prob doing something wrong. >> >> I've done the following >> >> On tt1 I did =herd stop guix-daemon= >> Then exported proxy like so: >> export http_proxy=http://server.domain.co.za:8080/ ; export >> ftp_proxy=$http_proxy ; export https_proxy=$http_proxy >> >> =herd start guix-daemon= > > The ‘http_proxy’ variable needs to be set in the environment of the > ‘guix-daemon’ process itself, which is why this doesn’t work. We should > make it easier to choose a proxy, for instance by having the daemon > honor client-provided proxy settings. Hmm, so what exactly do I need to do to get the http_proxy variable set in the guix-daemon environment? I've tried exporting on command line, then starting the daemon but that didn't work. > Thanks a lot for your detailed feedback! Thanks a lot for the awesome work on GuixSD!
