Alle giovedì 28 giugno 2007, Enrico Tassi ha scritto: > I tried the live CD with qemu, and I used -hda hand_made_vfat_image > and it worked placin into it the cpio file created by casper-snapshot or > live-snapshot. It worked perfectly.
This should be working because it is one of the two snapshots mode I tested (in qemu in fact) ;-) > Then I tried with my real hardware. > How can I trace this problem? /var/log/casper.log (or /var/log/live.log) > can It be that the usb device is > "discovered" late? Yes, it should be that, in fact early versions of casper had a huge (buggy 15 min) timeout that hided that problem, I probably need to think about a smart solution of that, but for now try to add a delay in your chroot in /usr/share/initramfs-tools/scripts/live grepping "cpio.gz". Please comment the next proposed solution: As default live-initramfs will try just 1 time to find persistent media. If "nopersistent" is specified it will not try at all. If "persistent" is specified it will try with geometric wait times until a fixed numer of trials has passed. > I'm pretty sure that during boot, the kernel prints > something about usb device exactly at the beginning of the squash-fs > loading (the operation that takes some time). Can it be a rece > condition? I need to try on real hardware too and find a way. > Am I doing something wrong? If you did the same as you did for qemu, just replacing the qemu ide disk partition with a similar (as in "filesystem" and "file name") partition on a real usb key, you did not; so the bug is in our code I presume (if not in strange places like udev or the kernel). > Thanks for the help. Thanks for your report. -- ESC:wq
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Debian-live-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
