GNU bug report logs -
#47723
Boot failure with u-boot on cubietruck
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47723 in the body.
You can then email your comments to 47723 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#47723
; Package
guix
.
(Mon, 12 Apr 2021 11:19:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Julien Lepiller <julien <at> lepiller.eu>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Mon, 12 Apr 2021 11:19:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Guix!
This week-end, I had to reboot my server and it couldn't boot anymore.
It's a Cubietruck, an armhf machine that's in my parents' basement.
They helped me debug the issue (though that was not easy, since they
only have windows machines and not a lot of knowledge about Linux).
At boot, the machine loads the kernel and initramfs, and gets stuck at
"Starting kernel...". We tried booting various generations, including
the very firts generation (as I never had to run guix gc on the
machine, I kept all the generations around, that's 129 of them!). None
of them worked, and they all get stuck at the same message.
I suspect something might have changed in u-boot recently (maybe the
upgrade to 2021.01, since I didn't have to reboot this year yet). The
board might not be initialized as expected and all kernels from 4.19 to
the latest 5.11 fail to boot.
In the end, I reinstalled a foreign distribution (that uses u-boot
2017.01) and can SSH to the machine, but I haven't reinstalled Guix
yet. Guix was installed on an external disk, so I haven't lost anything
other that the bootloader it installed. I can chroot to the Guix system:
mount -v --bind /dev /mnt/dev
mount -v --bind /dev/pts /mnt/dev/pts
mount -vt proc proc /mnt/proc
mount -vt sysfs sysfs /mnt/sys
chroot /mnt /run/current-system/profile/bin/bash
. /etc/profile
What should be my next step?
I tried running guix from inside the chroot:
/root/.config/current/bin/guix-daemon --build-users-group=guixbuild &
But when I try to use it:
guix system build /etc/config.scm
guix system: error: while setting up the build environment: cannot
pivot old root directory onto
'/gnu/store/brkm5bb59w9i4kmyznk0k4ndsz6dzq95-system.drv.chroot/real-root':
Invalid argument
My hope was to run "guix system reconfigure" from the chroot, so I
would not loose my previous generations, and would not have to build
too much, since there are almost no substitutes for armhf.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#47723
; Package
guix
.
(Tue, 13 Apr 2021 19:15:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 47723 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Julien,
On Mon, 12 Apr 2021 13:18:30 +0200
Julien Lepiller <julien <at> lepiller.eu> wrote:
> I suspect something might have changed in u-boot recently (maybe the
> upgrade to 2021.01, since I didn't have to reboot this year yet).
[...]
> board might not be initialized as expected and all kernels from 4.19 to
> the latest 5.11 fail to boot.
Yeah, that happens sometimes with u-boot. It sucks--but I suspect there's just
not a lot of people updating their u-boot installation all the time (or at all
ever).
I'm not sure whether it's better to just provide the old u-boot or to figure
out what exactly broke (the latter is probably gonna take quite some time).
> In the end, I reinstalled a foreign distribution (that uses u-boot
> 2017.01) and can SSH to the machine, but I haven't reinstalled Guix
> yet. Guix was installed on an external disk, so I haven't lost anything
> other that the bootloader it installed. I can chroot to the Guix system:
>
> mount -v --bind /dev /mnt/dev
> mount -v --bind /dev/pts /mnt/dev/pts
> mount -vt proc proc /mnt/proc
> mount -vt sysfs sysfs /mnt/sys
> chroot /mnt /run/current-system/profile/bin/bash
> . /etc/profile
>
> What should be my next step?
>
> I tried running guix from inside the chroot:
> /root/.config/current/bin/guix-daemon --build-users-group=guixbuild &
Try
unshare -m /root/.config/current/bin/guix-daemon --build-users-group=guixbuild &
It should work then.
[Message part 2 (application/pgp-signature, inline)]
Reply sent
to
Julien Lepiller <julien <at> lepiller.eu>
:
You have taken responsibility.
(Sat, 17 Apr 2021 18:24:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Julien Lepiller <julien <at> lepiller.eu>
:
bug acknowledged by developer.
(Sat, 17 Apr 2021 18:24:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 47723-done <at> debbugs.gnu.org (full text, mbox):
Le Tue, 13 Apr 2021 21:14:49 +0200,
Danny Milosavljevic <dannym <at> scratchpost.org> a écrit :
> Hi Julien,
>
> On Mon, 12 Apr 2021 13:18:30 +0200
> Julien Lepiller <julien <at> lepiller.eu> wrote:
>
> > I suspect something might have changed in u-boot recently (maybe the
> > upgrade to 2021.01, since I didn't have to reboot this year yet).
> [...]
> > board might not be initialized as expected and all kernels from
> > 4.19 to the latest 5.11 fail to boot.
>
> Yeah, that happens sometimes with u-boot. It sucks--but I suspect
> there's just not a lot of people updating their u-boot installation
> all the time (or at all ever).
>
> I'm not sure whether it's better to just provide the old u-boot or to
> figure out what exactly broke (the latter is probably gonna take
> quite some time).
Thanks for the help, I finally managed to boot it with the newer
2021.04 u-boot. Maybe 2021.01 did something wrong that was fixed later?
>
> > In the end, I reinstalled a foreign distribution (that uses u-boot
> > 2017.01) and can SSH to the machine, but I haven't reinstalled Guix
> > yet. Guix was installed on an external disk, so I haven't lost
> > anything other that the bootloader it installed. I can chroot to
> > the Guix system:
> >
> > mount -v --bind /dev /mnt/dev
> > mount -v --bind /dev/pts /mnt/dev/pts
> > mount -vt proc proc /mnt/proc
> > mount -vt sysfs sysfs /mnt/sys
> > chroot /mnt /run/current-system/profile/bin/bash
> > . /etc/profile
> >
> > What should be my next step?
> >
> > I tried running guix from inside the chroot:
> > /root/.config/current/bin/guix-daemon
> > --build-users-group=guixbuild &
>
> Try
>
> unshare -m /root/.config/current/bin/guix-daemon
> --build-users-group=guixbuild &
>
> It should work then.
Ah, I found another workaround, not sure how it works but, from the
foreign system I could "mount --make-rprivate /" and it would work.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 16 May 2021 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 346 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.