[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#783323: Broken configuration for OpenBlocks AX3-4



(CCing Nobuhiro who contributed the flash-kernel db entry for this
device)

On Sat, 2015-05-02 at 15:40 +0100, Ian Campbell wrote:
> On Sun, 2015-04-26 at 00:39 +0100, Ben Hutchings wrote:
> > On Sat, 25 Apr 2015 23:39:44 +0100 Ben Hutchings <ben@decadent.org.uk> wrote:
> > > Secondly, if the installation uses LVM, /dev/sda1 is the /boot
> > > partition, not the root partition.  After fixing the first problem,
> > > flash-kernel fails like this:
> > 
> > Actually, this doesn't depend on LVM.  The installer always creates a
> > separate /boot partition using the ext2 filesystem, and this makes sense
> > as u-boot generally doesn't support ext4.  So I think that the /boot
> > prefix should be removed from the paths for this entry.  (And maybe many
> > other entries.)
> 
> I think you are likely correct.
> 
> I'm considering declaring that all such db fields are always relative
> to /boot and having f-k decide if it needs to prepend /boot or not,
> perhaps based on "stat -c %m /boot" or something similar.

Actually, thinking a bit harder...

Looking back at your original error:
mv: cannot move '/tmp/flash-kernel.3ft8lyny/uImage' to '/tmp/flash-kernel.V2iwAjyz//boot/uImage': No such file or directory

I think this is because the db entry includes a Boot-Device. This is
supposed to be used for devices where the firmware boots from a
partition which is not typically mounted (i.e. a special VFAT
partition), hence things in /tmp before copying there.

For device which can boot from a sensible filesystem then Boot-Device
shouldn't be used and things will end up in /boot (separate or
otherwise).

Essentially if Boot-Device is set then Boot-*-Path should be relative to
that device, if Boot-Device is not set then Boot-*-Path are relative
to /.

I think /dev/sda1 is your actual /boot and using Boot-Device in that
case is wrong. If you remove it do things improve?

It seems that the code which handles the Boot-Device case is buggy in
the face of a firmware partition which has some hierarchy to it.

Ian.


Reply to: