On Sat, 2015-05-02 at 16:35 +0100, Ian Campbell wrote: > (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 AFAIK it can only boot from ext2 or VFAT filesystems, but they can be on any partition (probably only MBR) on any drive (SATA or USB). > then Boot-Device > shouldn't be used and things will end up in /boot (separate or > otherwise). Right. > 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? Yes, this database entry works for me: Machine: Plat'Home OpenBlocks AX3-4 Kernel-Flavors: armmp armmp-lpae DTB-Id: armada-xp-openblocks-ax3-4.dtb DTB-Append: yes U-Boot-Kernel-Address: 0x2000000 U-Boot-Kernel-Entry-Point: 0x2000040 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage Boot-Initrd-Path: /boot/uInitrd Boot-DTB-Path: /boot/dtb Required-Packages: u-boot-tools > 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. If the boot images need to be in a specific subdirectory then it's not so unreasonable to expect that the subdirectory already exists, but still it might be helpful to add a 'mkdir -p "$(dirname "$path")"'. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less.
Attachment:
signature.asc
Description: This is a digitally signed message part