Installation of our nightly build of our custom distribution failed with the error message:
"The OURDIST installation tree in that directory does not seem to match your boot media."
After some serious debugging, I found out the problem: In minstg2.img, there were *two* buildstamps:
-rw-r--r-- 1 root root 61 27 jan 12.51 squashfs-root/.buildstamp -rw-r--r-- 1 root root 61 28 jan 12.52 squashfs-root/.buildstamp_1
Only the second one matches the initrd buildstamp. Any idea why this happens? My guess is that this is some kind of intermittent problem, but those gives me a bad feeling...
Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00
Peter Åstrand wrote:
Installation of our nightly build of our custom distribution failed with the error message:
"The OURDIST installation tree in that directory does not seem to match your boot media."
After some serious debugging, I found out the problem: In minstg2.img, there were *two* buildstamps:
-rw-r--r-- 1 root root 61 27 jan 12.51 squashfs-root/.buildstamp -rw-r--r-- 1 root root 61 28 jan 12.52 squashfs-root/.buildstamp_1
Only the second one matches the initrd buildstamp. Any idea why this happens? My guess is that this is some kind of intermittent problem, but those gives me a bad feeling...
Best regards,
Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00
-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
This is kinda strange. The buildstamp file gets created by mk-image (anaconda scripts) to create the buildstamp the mk-image script erases buildstamp and then creates a new file. Additionally I could not find any trace of replacing the name of buildstamp with `buildstamp_$count`. What are you using to make your tree? on what is your distro based on, fedora, centos? what versions? I *think* what is happenning is that you are compossing on top of an already composed tree, and your compose tool does not want to replace the existing .buildstamp file, so it makes another with a similar name. I could be wrong though. In any case you should check the compose tool and the anconda scritps from the version you are using.
regards
On Mon, 28 Jan 2008, Joel Andres Granados wrote:
This is kinda strange. The buildstamp file gets created by mk-image (anaconda scripts) to create the buildstamp the mk-image script erases buildstamp and then creates a new file. Additionally I could not find any trace of replacing the name of buildstamp with `buildstamp_$count`.
Strange it is. I haven't found any traces of buildstamp_$count neither.
Perhaps I should mention that we are using mksquashfs to append a few files to minstg2.img. I'm certain that .buildstamp is not one of those, but perhaps we are looking at some kind of mksquashfs bug.
What are you using to make your tree? on what is your distro based on, fedora, centos? what versions?
Pungi, Fedora 8.
I *think* what is happenning is that you are compossing on top of an already composed tree, and your compose tool does not want to replace the existing .buildstamp file, so it makes another with a similar name. I could be wrong though. In any case you should check the compose tool and the anconda scritps from the version you are using.
Another theory is that there's a name clash in /tmp. It seems like Pungi and the other tools does not clean up its build directories. Instead, they are left to tmpwatch, which has a 30 day limit by default. So we have always have 30 directories of each in /tmp.
I've done another build now and it looks OK. Perhaps we just had bad luck and hit the same sequence (pid?) number of an existing dir.
Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00
Peter Åstrand wrote:
On Mon, 28 Jan 2008, Joel Andres Granados wrote:
This is kinda strange. The buildstamp file gets created by mk-image (anaconda scripts) to create the buildstamp the mk-image script erases buildstamp and then creates a new file. Additionally I could not find any trace of replacing the name of buildstamp with `buildstamp_$count`.
Strange it is. I haven't found any traces of buildstamp_$count neither.
Perhaps I should mention that we are using mksquashfs to append a few files to minstg2.img. I'm certain that .buildstamp is not one of those, but perhaps we are looking at some kind of mksquashfs bug.
Everything is possible ;)
What are you using to make your tree? on what is your distro based on, fedora, centos? what versions?
Pungi, Fedora 8.
I *think* what is happenning is that you are compossing on top of an already composed tree, and your compose tool does not want to replace the existing .buildstamp file, so it makes another with a similar name. I could be wrong though. In any case you should check the compose tool and the anconda scritps from the version you are using.
Another theory is that there's a name clash in /tmp. It seems like Pungi and the other tools does not clean up its build directories. Instead, they are left to tmpwatch, which has a 30 day limit by default. So we have always have 30 directories of each in /tmp.
I've done another build now and it looks OK. Perhaps we just had bad luck and hit the same sequence (pid?) number of an existing dir.
I'm pretty sure that the script that puts the stuff in tmp is not pungi but buildinstall, pungi simply calls buildinstall. Additionally pungi has its own temp, log directory somewhere, thats not tmp (AFAIR).
Regards.
Regards,
Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00
-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
On Mon, 28 Jan 2008 16:21:56 +0100 Joel Andres Granados jgranado@redhat.com wrote:
I'm pretty sure that the script that puts the stuff in tmp is not pungi but buildinstall, pungi simply calls buildinstall. Additionally pungi has its own temp, log directory somewhere, thats not tmp (AFAIR).
buildinstall does purport to supporting a TMPDIR setting, but when I've tried to use that in the past with pungi it's lead to broken composes. It's on my list to investigate and hopefully fix after the Alpha is released.
On Mon, 28 Jan 2008, Peter Åstrand wrote:
Another theory is that there's a name clash in /tmp. It seems like Pungi and the other tools does not clean up its build directories. Instead, they are left to tmpwatch, which has a 30 day limit by default. So we have always have 30 directories of each in /tmp.
I've done another build now and it looks OK. Perhaps we just had bad luck and hit the same sequence (pid?) number of an existing dir.
Bingo. When looking at i386.log, I found:
Building minstg.img Running mksquashfs /tmp/instimage.dir.4284 /tmp/minstg2.img -all-root -no-fragments -no-progress Found a valid exportable little endian SQUASHFS superblock on /tmp/minstg2.img.4284.
That is, the target /tmp/minstg2.img.4284 already exists, so files will be appended. Another funny thing is that both first debug lines are incorrect:
* We are not building minstg.img, but minstg2.img
* The output file is not /tmp/minstg2.img, but /tmp/minstg2.img.4284.
In /usr/lib/anaconda-runtime/mk-images, you will find:
echo "Running mksquashfs $tmp $TMPDIR/${imagename}2.img -all-root -no-fragments -no-progress" mksquashfs $tmp $TMPDIR/${imagename}2.img.$$ -all-root -no-fragments -no-progress chmod 0644 $TMPDIR/${imagename}2.img.$$
It seems like $$ was added to the command but not the debug printout... It would be much more SPOT to do:
cmd="mksquashfs $tmp $TMPDIR/${imagename}2.img.$$ -all-root -no-fragments -no-progress" echo "Running ${cmd}" ${cmd}
Another thing to consider is run run mksquashfs with the -noappend.
Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00
Peter Åstrand wrote:
On Mon, 28 Jan 2008, Peter Åstrand wrote:
Another theory is that there's a name clash in /tmp. It seems like Pungi and the other tools does not clean up its build directories. Instead, they are left to tmpwatch, which has a 30 day limit by default. So we have always have 30 directories of each in /tmp.
I've done another build now and it looks OK. Perhaps we just had bad luck and hit the same sequence (pid?) number of an existing dir.
Bingo. When looking at i386.log, I found:
Building minstg.img Running mksquashfs /tmp/instimage.dir.4284 /tmp/minstg2.img -all-root -no-fragments -no-progress Found a valid exportable little endian SQUASHFS superblock on /tmp/minstg2.img.4284.
That is, the target /tmp/minstg2.img.4284 already exists, so files will be appended. Another funny thing is that both first debug lines are incorrect:
We are not building minstg.img, but minstg2.img
The output file is not /tmp/minstg2.img, but /tmp/minstg2.img.4284.
In /usr/lib/anaconda-runtime/mk-images, you will find:
echo "Running mksquashfs $tmp $TMPDIR/${imagename}2.img -all-root -no-fragments -no-progress" mksquashfs $tmp $TMPDIR/${imagename}2.img.$$ -all-root -no-fragments -no-progress chmod 0644 $TMPDIR/${imagename}2.img.$$It seems like $$ was added to the command but not the debug printout... It would be much more SPOT to do:
cmd="mksquashfs $tmp $TMPDIR/${imagename}2.img.$$ -all-root -no-fragments -no-progress" echo "Running ${cmd}" ${cmd}
this *is* a better idea. I'll take a look at it in the afternoon and see if it needs changin.
Another thing to consider is run run mksquashfs with the -noappend.
Don't know if thats really what we want, might break other stuff. would have to look into it.
Rgds,
Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00
-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
buildsys@lists.fedoraproject.org
-
Jesse Keating -
Joel Andres Granados -
Peter Åstrand