Bug#783278: patch v2
Thanks, I'll take a look when I finally get a spare moment! On Sun, 2015-05-03 at 13:24 -0500, David Lechner wrote: Yes, you guessed correctly. The v2 patch is the good one. On 05/03/2015 03:19 AM, Ian Campbell wrote: Hi David, On Fri, 2015-04-24 at 21:25 -0500, David Lechner wrote: Tags: patch I botched the first patch. This one fixes it correctly. Thanks for the patch(es). The buglog at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783278 has somehow ended up with the message ordering confused. I'm pretty certain that the patch which should be correct is this one labelled in the subject as v2 at Message #10 and not what I suppose is v1 which for some reason didn't arrive until Message #15. The date headers match this interpretation. I suppose the first mail got delayed somehow on its way to the BTS so they appear in the opposite order in the log. I thought I ought to double check! Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783278: patch v2
Hi David, On Fri, 2015-04-24 at 21:25 -0500, David Lechner wrote: Tags: patch I botched the first patch. This one fixes it correctly. Thanks for the patch(es). The buglog at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783278 has somehow ended up with the message ordering confused. I'm pretty certain that the patch which should be correct is this one labelled in the subject as v2 at Message #10 and not what I suppose is v1 which for some reason didn't arrive until Message #15. The date headers match this interpretation. I suppose the first mail got delayed somehow on its way to the BTS so they appear in the opposite order in the log. I thought I ought to double check! Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783278: patch v2
Yes, you guessed correctly. The v2 patch is the good one. On 05/03/2015 03:19 AM, Ian Campbell wrote: Hi David, On Fri, 2015-04-24 at 21:25 -0500, David Lechner wrote: Tags: patch I botched the first patch. This one fixes it correctly. Thanks for the patch(es). The buglog at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783278 has somehow ended up with the message ordering confused. I'm pretty certain that the patch which should be correct is this one labelled in the subject as v2 at Message #10 and not what I suppose is v1 which for some reason didn't arrive until Message #15. The date headers match this interpretation. I suppose the first mail got delayed somehow on its way to the BTS so they appear in the opposite order in the log. I thought I ought to double check! Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783278: patch v2
Tags: patch I botched the first patch. This one fixes it correctly. From 6eb082b42ad9a7c22f08ecb9f18fab7f8891be95 Mon Sep 17 00:00:00 2001 From: David Lechner da...@lechnology.com Date: Fri, 24 Apr 2015 19:13:00 -0500 Subject: [PATCH] Handle case when kernel == kfile check in boot_kernel_path handler. This only applies to Method: generic. Old behavior: If the db entry specifies Boot-Kernel-Path, one of Dtb-Append, Machine-Id or U-Boot-Kernel-Address must be specified which changes the value of $kernel. When checking what to do wht Boot-Kernel-Path, the script checks to see if $kernel was changed from the original value ($kfile). If it did not change, it does nothing. There is a TODO comment about handling symlinks, but this does not make sense since this is the generic method, not the symlink method. New behavior: If $kernel was not changed, copy it to a temporary file before calling backup_and_install. backup_and_install moves the temporary file, effectivly deleting it. Also applied same fix to initrd. Use case: On Raspberry Pi, the boot loader uses the vmlinux-* file directly, but it needs to be renamed to kernel.img, which flash-kernel should be doing. --- functions | 20 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/functions b/functions index a7ff6de..6579b18 100644 --- a/functions +++ b/functions @@ -684,13 +684,11 @@ case $method in if [ -n $boot_kernel_path ]; then boot_kernel_path=$boot_mnt_dir/$boot_kernel_path # don't mv the original kernel - if [ $kernel != $kfile ]; then -backup_and_install $kernel \ - $boot_kernel_path - else -# TODO add support for kernel symlink -: + if [ $kernel = $kfile ]; then +cp $kernel $tmpdir/kernel +kernel=$tmpdir/kernel fi + backup_and_install $kernel $boot_kernel_path elif [ -n $kmtd ]; then flash_kernel $tmpdir/uImage $kmtd rm -f $tmpdir/uImage @@ -706,13 +704,11 @@ case $method in if [ -n $boot_initrd_path ]; then boot_initrd_path=$boot_mnt_dir/$boot_initrd_path # don't mv the original initrd - if [ $initrd != $ifile ]; then -backup_and_install $initrd \ - $boot_initrd_path - else -# TODO add support for initrd symlink -: + if [ $initrd = $ifile ]; then +cp $initrd $tmpdir/initrd +initrd=$tmpdir/initrd fi + backup_and_install $initrd $boot_initrd_path elif [ -n $imtd ]; then ipad=0 # padding isn't needed for U-Boot images -- 1.9.1
Bug#783278: patch
Here is how I have fixed the problem (attached patch). There was an if statement with a TODO that was not implemented, so I just took it out. From 20cea9a9506575a40a439766fb3e9d4bbb7587cb Mon Sep 17 00:00:00 2001 From: David Lechner da...@lechnology.com Date: Fri, 24 Apr 2015 19:13:00 -0500 Subject: [PATCH] remove kernel != kfile check in boot_kernel_path handler. This only applies to Method: generic. Old behavior: If the db entry specifies Boot-Kernel-Path, one of Dtb-Append, Machine-Id or U-Boot-Kernel-Address must be specified which changes the value of $kernel. When checking what to do wht Boot-Kernel-Path, the script checks to see if $kernel was changed from the original value ($kfile). If it did not change, it does nothing. There is a TODO comment about handling symlinks, but this does not make sense since this is the generic method, not the symlink method. New behavior: The check to see if $kernel changed is removed. As long as Boot-Kernel-Path is specified, flash-kernel will copy the kernel to the specified path. Use case: On Raspberry Pi, the boot loader uses the vmlinux-* file directly, but it needs to be renamed to kernel.img, which flash-kernel should be doing. --- functions | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/functions b/functions index a7ff6de..34e7536 100644 --- a/functions +++ b/functions @@ -684,13 +684,7 @@ case $method in if [ -n $boot_kernel_path ]; then boot_kernel_path=$boot_mnt_dir/$boot_kernel_path # don't mv the original kernel - if [ $kernel != $kfile ]; then -backup_and_install $kernel \ - $boot_kernel_path - else -# TODO add support for kernel symlink -: - fi + backup_and_install $kernel $boot_kernel_path elif [ -n $kmtd ]; then flash_kernel $tmpdir/uImage $kmtd rm -f $tmpdir/uImage -- 1.9.1
