On Sat, Jul 13, 2013 at 11:50:40AM -0500, Dennis Gilmore wrote:
On Sat, 13 Jul 2013 11:36:00 +0200
Till Maas <opensource(a)till.name> wrote:
> On Fri, Jul 12, 2013 at 02:06:12PM -0500, Dennis Gilmore wrote:
> > we have a kernel and initramfs, that can be pxe booted or you can
> > boot and load, however we have not made it the primary mathod of
> > install for boards because they generally can only boot and run
> > from a sdcard you would need to install to the boot media. it quite
> > possibly works just fine other than not installing uboot to the
> > sdcard in the way needed, however for non omap systems that copy
> > the file into a partition it will likely work ok. so cubieboard
> > since you need to dd u-boot into a particular location of the
> > sdcard it should still be there post install. Its not tested at
> > all however.
> I cannot completely follow here. However, I guess the images you mean
> are the following:
> Is there any particular reason, why there is no signed CHECKSUM file
> for these? What is required for these images to be able to run
> anaconda and install packages? I assume that anaconda won't verify
> package signatures, therefore I guess a copy of manual verified RPMs
> is required?
We don't make and sign CHECKSUMS for the equivalent bits on any arch.
to have anaconda run you need to boot the kernel and initramfs. and
pass to it options to find the rest of the bits. exactly as is done on
primary. though you likely need to instrall u-boot to the sdcard then
setup a boot.scr that loads things for you. and hopefully anaconda will
let you destroy it when running. since you will be booting from the
> And what can be done with the live image:
> (It is also not signed)
Also true of all arches, we don't make CHECKSUMS or sign them
At least a while ago these files were available in signed iso images for
the primary arch. Nevertheless, what is (supposed to be) possible with
the LiveOS image for ARM?
> The raw disk images seem to be signed:
> But I noticed that here SHA1 is used instead of SHA256 for the GPG
> signature and the comment about sha256sum being used to generate the
> hashes is missing, e.g. the primary archs have files like these:
probably a difference in the setup of the sigul between primary and
secondary arches. the comment about sha256sum only ever exists in pungi
generated CHECKSUMS all the manually generated ones which includes Live
and Spins trees do not have it. if you want to change things i suggest
you join Release engineering and help me to make things better rather
than just complain that how I do things doesn't suit your needs.
Release Engineering is me with a lot of help from Kevin Fenzi and over
the last few releases a lot more has been asked from me which means
many things that could have been done have not been. as is Both Kevin
and I work a lot more than 40 hours.
Thank you, I will gladly help. I believe I already helped with releng
tasks in the past, back then when buildroot overrides had to be done
manually. If you give me any pointers to what I can do to get the things
signed, I will take a look. I found so far
but they are not up-to-date and only show the user POV for the sigul
system not the admin POV. So how do we proceed here? If you give me
access to the respective system, I can start with updating the
documentation and you can review them to verify I understand the
process. I guess this probably also helps to identify the reason for the
different hash algorithms used.
> Here is a ticket for this:
the ticket is for nothing mentioned in this email
It mentions the different hash method of the CHECKSUM files.