Bug#430566: xserver-xorg postinst calls xresprobe that makes running X server flick
Package: live-helper Version: 1.0~a15-1 Severity: normal --- Please enter the report below this line. --- I'm running X with the i810 driver, and while lh_* is bootstrapping the chroot the screen goes black for few seconds (sometimes rebooting the machine, but this is more X related than live-helper). The flicker is caused by an execution of xresprobe and is reproducible. I think there is no point in configuring X during the bootstrapping phase, but I really don't know how it is done at runtime when the live CD boots. If at boot-time xresprobe is not needed, it is only recommended by xserver-xorg, so it may be blacklisted. Cheers. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.21.1-mactel Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.it.debian.org 500 testing security.debian.org --- Package information. --- Depends (Version) | Installed =-+-= cdebootstrap (= 0.3.15) | 0.4.3 OR debootstrap (= 0.3.3.2) | 1.0.0 -- Enrico Tassi ___ Debian-live-devel mailing list Debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
persistent option
I'm trying to use the persistency feature and I succeded usgin qemu for executing the image and adding an hda virtual disk for persistence. What I'm failing doing is using a real USB device, booting the real computer from the live CD. I tried bot with casper (stable) and live-initramfs from unstable, but it seems they both fail in finding the usb key. How can I debug this? Where should I look. Cheers -- Enrico Tassi ___ Debian-live-devel mailing list Debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: persistent option
On Thu, Jun 28, 2007 at 04:42:40PM +0100, [EMAIL PROTECTED] wrote: First of all, does your computer BIOS support booting from a USB stick at all? Also, have you made sure that your partition (should be the first one on your USB stick of filesystem type 'vfat', normally seen as '/dev/sda1' by Linux) is marked as bootable? You can use fdisk to achieve this. Finally, do a 'syslinux /dev/sda1' from your root account to make sure it has a correct MBR. Sorry, I've been misunderstood. I'm booting from CD, and I want to achieve persistency trough a usb stick. 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. Then I tried with my real hardware. I booted from the CD, I created a new file one the desktop, issued live-snapshot, copied the cpio file on the usb stick, unmounted it and rebooted with the stick in. After the reboot the file I created was not on the desktop. I'll have users that can't format the usb stick with ext2 or relable it, but from the wiki I understood it is not necessary (and in fact, just putting the file there worked using qemu). How can I trace this problem? can It be that the usb device is discovered late? 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? Am I doing something wrong? Thanks for the help. -- Enrico Tassi ___ Debian-live-devel mailing list Debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Bug#431160: Caching mechanism for local-packagelists seems not to work
Package: live-helper Version: 1.0~a16-1 Severity: normal --- Please enter the report below this line. --- I've a lot of packages that are installed because they are listed in the config/chroot_local-packagelists/extra.txt and are fetched from a custom debian archive listed in config/chroot_sources/extra.bootstrap. After the lh_* these debs are not in the cache directory and are re-download over and over. Cheers. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.21.1-mactel Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.it.debian.org 500 testing security.debian.org --- Package information. --- Depends (Version) | Installed =-+-= cdebootstrap (= 0.3.15) | 0.4.3 OR debootstrap (= 0.3.3.2) | 1.0.0 -- Enrico Tassi ___ Debian-live-devel mailing list Debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: persistent option
On Thu, Jun 28, 2007 at 11:04:11PM +0200, Marco Amadori wrote: /var/log/casper.log (or /var/log/live.log) Here there are no timestamps... can't tell you if the failure in finding the device happens before the kernel discovers it. 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. I added a sleep 5, and it worked! 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 think that the geometric retry is a bit overkilling. It is probably enough to wait, lets say, 5 seconds if the first attempt fails. I'd never wait more than 5 seconds... in any case sleep has the granularity of seconds... So even if you solution is teoretically elegant I think that a second attempt after few seconds is enough. Cheers and thanks for the help. -- Enrico Tassi ___ Debian-live-devel mailing list Debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Bug#431160: More infos
Package: live-helper Version: 1.0~a18-1 --- Please enter the report below this line. --- Ive just noticed that aptitude fails, cause twho packages are installed at the same time (coq and emacsen-common) but the formes should probably pre-depend on the latter. Setting up coq (8.1+dfsg-3) ... ERROR: emacsen-common being used before being configured. ERROR: This is likely a bug in the coq package, which needs to ERROR: add one of the appropriate dependencies. ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz ERROR: for details. dpkg: error processing coq (--configure): subprocess post-installation script returned error exit status 2 This bug may be reassigned, but the 'set -e' at the beginning of /usr/bin/lh_chroot_local-packageslists makes me think that one of the following options should be adopted: 1) resist to failures and continue caching the result 2) fails and add a flag to ignore eventual failures For example in my cases, the failure can be ignored. Cheers. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.22-mactel Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.it.debian.org 500 testing security.debian.org --- Package information. --- Depends (Version) | Installed =-+-= cdebootstrap (= 0.3.15) | 0.4.3 OR debootstrap (= 0.3.3.2) | 1.0.0 -- Enrico Tassi ___ Debian-live-devel mailing list Debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Bug#433612: Duplicate grub lines
Package: live-helper
Version: 1.0~a18-1
Severity: normal
--- Please enter the report below this line. ---
Recently the lh_binary_grub helper started adding 2 fake lines in the
grub menu. Looking at the code, this snipped catch my attention:
DEFAULT_FLAVOUR=`echo ${LIVE_LINUX_FLAVOURS} | awk '{ print $1 }'`
DEFAULT_KERNEL=`basename chroot/boot/vmlinuz-*${DEFAULT_FLAVOUR}`
DEFAULT_INITRD=initrd.img-`echo ${DEFAULT_KERNEL} | sed -e 's/vmlinuz-//'`
Grub_live_entry live ${DEFAULT_KERNEL} ${DEFAULT_INITRD}
Grub_live_entry live (fail-safe mode) ${DEFAULT_KERNEL}
${DEFAULT_INITRD} ${FAILSAFE}
for KERNEL in chroot/boot/vmlinuz-*
do
VERSION=`basename ${KERNEL} | sed -e 's/vmlinuz-//'`
Grub_live_entry live, kernel ${VERSION} `basename
${DESTDIR_LIVE}`/`basename ${KERNEL}` `basename
${DESTDIR_LIVE}`/initrd.img-${VERSION}
Grub_live_entry live, kernel ${VERSION} (fail-safe mode) `basename
${DESTDIR_LIVE}`/`basename ${KERNEL}` `basename
${DESTDIR_LIVE}`/initrd.img-${VERSION} ${FAILSAFE}
done
IMO the for loop catches twice the default kernel image. I mean, it has already
been added explicitly, so the for loops add it again. Moreover the former
addition is different not only in the lable name, but also in the path!
And at least in my case the former does not work at all (points to a non
existing path)
Cheers
--- System information. ---
Architecture: amd64
Kernel: Linux 2.6.21.1-mactel
Debian Release: lenny/sid
500 unstablewww.debian-multimedia.org
500 unstableftp.it.debian.org
500 testing security.debian.org
--- Package information. ---
Depends (Version) | Installed
=-+-=
cdebootstrap (= 0.3.15) | 0.4.3
OR debootstrap (= 0.3.3.2) | 1.0.0
--
Enrico Tassi
___
Debian-live-devel mailing list
Debian-live-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Bug#433611: Completely offline CD build
On Thu, Jul 19, 2007 at 11:07:23AM +0200, Daniel Baumann wrote: Vladimir Stavrinov wrote: I have applied this patch for lh_binary_chroot rev. 2509 and benefit about 50% of total build time without any side effects. it has side effects, as written somewhen last week on the mailinglist. I missed the mail... sorry In any case, for any non toy image, unless you have a 10.000 rpm scsi hard drive, copying 1,8G of data for the sake of not requiring 2 packages to be installed on the host system, seems crazy (both in time and HDD usage, it really stucks my laptop for 10 minutes, and also requires a lot of free space). Am I missing something that the current approach gives (in addition to not requiring squashfs, genisoimage ...)? Cheers -- Enrico Tassi ___ Debian-live-devel mailing list Debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Bug#433612: reopening 433612
# Automatically generated email from bts, devscripts version 2.10.6 # The path for the kernel images has been properly fixed, but there are still duplicates reopen 433612 ___ Debian-live-devel mailing list Debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Bug#433612: Why?
Could you please explain why having duplicate grub lines is a feature and not a bug? Cheers -- Enrico Tassi ___ Debian-live-devel mailing list Debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
