On 02/24/2013 04:46 PM, Adam D. Barratt wrote: > Even as a filtered diff, that's still a reasonably large set of > changes. :-(
Sorry about that. > A few comments / queries: > > --- live-tools.orig/bin/live-persistence 1970-01-01 01:00:00.000000000 > +0100 > +++ live-tools/bin/live-persistence 2013-02-15 10:42:34.619868805 +0100 > [...] > > +Most options correspond to the persistence-* options of live-boot, and will > +override the corresponging options parsed from the kernel command-line. > > "corresponding" Fixed in git. Thanks. > > --- live-tools.orig/bin/live-update-initramfs 1970-01-01 01:00:00.000000000 > +0100 > +++ live-tools/bin/live-update-initramfs 2013-02-15 09:38:30.324657057 > +0100 > [...] > + # FIXME: needs to exclude initrd backup files > + if [ "$(ls /boot/initrd.img-* | wc -l)" -gt 1 ] > + then > + _NUMBER="1" > + > + for _INITRD in /boot/initrd.img-* > > "FIXME"s in apparently final(ish) code always make me slightly wary. > What's the real-world effect of the loop picking up backup files? It would appear the intent of this code is to ensure when running in a live system, results of a real update-initramfs are copied to the live medium safely (i.e. copied first to ensure we have space, then renamed to a shorter name, presumably because some supported filesystems are limited in length of filename that is supported). If a backup filename exists (i.e. initrd.img-* with some additional suffix), then assuming there is no corresponding vmlinuz-* with the same suffix, the cp of that kernel will fail and no further kernels will be processed. Real-world effects: - any initrd/kernel pairs for kernel versions preceding encountering the initrd backup will have been successfully copied (at least the first "real" initrd/kernel will have been copied) - any initrd/kernel pairs including the backup and following will not be copied to the live media Please note that prior to introduction of this code, it was not possible for users to update their kernel and initrd in a live system with writable live media. Also, the code will not run except on a live system. Also, the failure does not leave the system unbootable, just without second and subsequent kernels actually updated. Possible user recovery: - removal of the backup files (I have not seen any of these. Who creates such files?) should allow live-update-initramfs to operate properly The other questions are harder. I will investigate further and get back to you. Thanks, Ben -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512b75cc.1040...@sanctuary.nslug.ns.ca
