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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/debian-live-devel/attachments/20070628/efc7ebf7/attachment-0001.pgp