[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44101: Unable to use /dev/disk/by-id/ symlinks with u-boot and guix
From: |
Bengt Richter |
Subject: |
bug#44101: Unable to use /dev/disk/by-id/ symlinks with u-boot and guix system reconfigure |
Date: |
Fri, 23 Oct 2020 01:12:02 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hi,
On +2020-10-22 13:08:45 -0700, Vagrant Cascadian wrote:
> On 2020-10-22, Mathieu Othacehe wrote:
> > Hey Vagrant,
> >
> >> I'm writing this from memory now, but I can also boot the machines at a
> >> later point and get the exact configurations, if needed.
> >
> > Sorry for breaking your use-case. Recently I have split up the
> > bootloader installation in two distinct parts:
>
> Thanks for your work on it, even if it resulted in a regression. :)
>
>
> > - Installing a bootloader directly on a mounted directory.
> > - Installing a bootloader on a raw-image or device.
> >
> > Depending on the bootloader type, one or both of the methods are
> > supported. u-boot does not really support the first method, so the
> > patch you are mentioning is disabling this method.
> >
> > The problem is while reconfiguring, the first method only is used. The
> > attached patch tries to fallback to the second method if the first one
> > is not defined.
>
> I don't quite understand why that would be the issue here; guix system
> reconfigure works fine when /dev/mmcblkN is specified target in the
> system config.scm, just not when the target is /dev/disk/by-id/...
>
> My wild guess was something was checking for a literal block device, and
> failing with a symlink pointing to a block device.
>
IIUC [1] implies the contents of /dev/disk/by-id is populated on udev events,
so IIRC
the values can be stale. Maybe that's an eliminated race by now, or a clue
about old systems?
[1]
https://unix.stackexchange.com/questions/86764/understanding-dev-disk-by-folders
>
> Trying your patch gets me a backtrace, unfortunately...
>
> With the bootloader section...
>
> (bootloader (bootloader-configuration
> (target "/dev/disk/by-id/mmc-SDU64_0xbaf3002e")
> (bootloader u-boot-pinebook-bootloader)
> ))
>
> And your patch applied on top of 3e09453884efa82ef97b8ec6e34470c67a1206a7...
>
> $ sudo -E ./pre-inst-env guix system reconfigure --keep-going
> ~/pinebook-1080p-desktop.scm
> ...
> waiting for locks or build slots...
> building
> /gnu/store/n17lkvs6vhq0x16mk0rxnv4j5ifvrlyr-switch-to-system.scm.drv...
> making '/gnu/store/vc3bzajlv0yxrdjmqph4sikzqkywvfq1-system' the current
> system...
> setting up setuid programs in '/run/setuid-programs'...
> populating /etc from /gnu/store/gssnxbhwa9dygn1i6i46j81ww5gczzav-etc...
> The following derivation will be built:
> /gnu/store/s19y61jrdys760zccxm2qiiqjpcv1fcx-install-bootloader.scm.drv
>
> building
> /gnu/store/s19y61jrdys760zccxm2qiiqjpcv1fcx-install-bootloader.scm.drv...
> Backtrace:
> In guix/scripts/system.scm:
> 1339:8 19 (_)
> In guix/status.scm:
> 776:4 18 (call-with-status-report _ _)
> In guix/scripts/system.scm:
> 1172:4 17 (_)
> In ice-9/boot-9.scm:
> 1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/store.scm:
> 631:37 15 (thunk)
> 1300:8 14 (call-with-build-handler _ _)
> 1300:8 13 (call-with-build-handler _ _)
> 1300:8 12 (call-with-build-handler _ _)
> 1300:8 11 (call-with-build-handler _ _)
> 1300:8 10 (call-with-build-handler _ _)
> 1300:8 9 (call-with-build-handler #<procedure ffff658a29f0 at g…> …)
> 2042:24 8 (run-with-store #<store-connection 256.99 ffff67755d70> …)
> In guix/scripts/system.scm:
> 842:13 7 (_ _)
> 844:15 6 (_ _)
> 750:13 5 (_ _)
> In ice-9/boot-9.scm:
> 152:2 4 (with-fluid* _ _ _)
> In unknown file:
> 3 (primitive-load "/gnu/store/81w2h9zd6b5q0ddchc0wr6vph22…")
> In ice-9/eval.scm:
> 619:8 2 (_ #(#(#<directory (guile-user) ffff7c2c4f00> "//v…") #))
> In ice-9/boot-9.scm:
> 1669:16 1 (raise-exception _ #:continuable? _)
> 1669:16 0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> ERROR:
> 1. &i/o-filename: "/dev/disk/by-id/mmc-SDU64_0xbaf3002e"
>
>
> It also fails when target is /dev/mmcblk1.
>
> So, clearly this is some other issue...
>
>
> live well,
> vagrant
HTH, otherwise sorry for the noise :)
--
Regards,
Bengt Richter