Hi, Daniel Kiper wrote: > Thomas, it would be nice if you could add the broken ISOs images which you > used for tests to the tests in the GRUB. If you do that please CC Glenn.
Is it wise to have a test which will loop endlessly in case of failure ? Is there a way to let a test time out ? Whatever: After poking in my memory and GRUB's tests directory i came to tests/util/grub-fs-tester.in which produces its ISOs as needed. It could be appropriate to create one or both CE loop ISOs there. But this might become a problem in the future, because the post-production hacks depend on correct byte addresses in the ISO image. So it would be better to add one or two canned images: 897 bytes of http://scdbackup.webframe.org/ce_loop.iso.gz 904 bytes of http://scdbackup.webframe.org/ce_loop2.iso.gz Next problem is that these images do not go well with the other tests in grub-fs-tester.in. I would want to run gunzip <ce_loop.iso.gz >ce_loop.iso run_grubfstest ls / in the neighborhood of the xorriso runs and then bail out immediately. But i don't yet fully understand what the for-loops around the xorriso runs mean: for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 1); do ... for BLKSIZE in $blksizes; do ... for NDEVICES in $(range "$MINDEVICES" "$MAXDEVICES" 1); do ... x"ziso9660") FSUUID=$(date -u +%Y-%m-%d-%H-%M-%S-00); xorriso ... So how to bail out properly at this point after e.g. x"iso9660_ce_loop") gunzip <ce_loop.iso.gz >ce_loop.iso run_grubfstest ls / ? And why do the ls tests in grub-fs-tester.in look like run_grubfstest ls -- -la which i cannot decipher by help of the options[]-list in grub-fstest.c ? I CC Glenn Washburn already now, in the hope that he can point me to examples or states that these ISOs should not become part of the tests. (Crossing fingers for the latter case ... ;-) Have a nice day :) Thomas _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
