error on live-cd
Hello, I'm Flávio, a student at Federal University of Bahia. I found an error when trying to make a live cd. The settings were defaults. Only typed commands lb lb config and build. The error was as follows: W: Failed to fetch var/lib/apt/lists/partial/cdn.debian.net_debian_dists_wheezy_main_i18n_Translation-en copy :/ Encountered a section with the Package: header.
Processed: reassign 631136 to iso-scan
Processing commands for cont...@bugs.debian.org: reassign 631136 iso-scan Bug #631136 [debian-installer] Testing USB installer image problem Bug reassigned from package 'debian-installer' to 'iso-scan'. Ignoring request to alter found versions of bug #631136 to the same values previously set Ignoring request to alter fixed versions of bug #631136 to the same values previously set thanks Stopping processing here. Please contact me if you need assistance. -- 631136: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631136 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.17706915604.transcr...@bugs.debian.org
Re: debconf not recognizing template pattern from custom udeb
Ryan Braun [ADS] wrote: Here is the templates control file from the udeb. Template: debian-installer/scripted-partitioning/title Type: text Description: Partition automatically via a shell script Template: scripted-partitioning/script Type: text Description: What script do you want to run to partition your disk? The filename must be relative to /lib/scripted-partitioning, and must already exist and be executable. If this is the actual file, it's clearly wrong; you have a lot of extra newlines. -- see shy jo -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120402143601.gb20...@gnu.kitenet.net
Bug#666530: cups fails to configure under cdebconf
Hi, Thanks for the report, On Sat, 2012-03-31 at 10:19 -0400, Jacob Emmert-Aronson wrote: Package: cdebconf Version: 0.160 Severity: normal Dear Maintainer, When cdebconf is enabled, Oh, one more person running cdebconf ! It's getting a bit popular. the cups postinst script dies with exit status 15 (confirmed against cups versions 1.5.2-5, 1.5.2-8, and 1.5.2-9). Unsetting DEBCONF_USE_CDEBCONF to fall back to debconf allows the package to install correctly. I locally repackaged cups to add set -x to the postinst script and obtained the following output, which may be useful in debugging: + db_fget cupsys/raw-print changed + _db_cmd 'FGET cupsys/raw-print' changed There it is. 'changed' is not a known/defined flag, so cdebconf returns an error message. Debconf on the other hand can take any string as a flag, so returns 0 false. My apologies if this would be more appropriately filed under the cups package; feel free to reassign if that is the case. Well, you've found a difference between debconf and cdebconf, so it's good to raise it here anyway. I guess this mostly brings the question of the flags management difference between Debconf and cdebconf. The former can take any word, while the latter can only take predefined ones by design, since they are stored internally as a bits field. Should we : * keep the internal cdebconf design, and restrict debconf flags to a list of defined ones (seen, dontparse, changed, ?) * make cdebconf as flexible of debconf, which would probably involve a change of the libdebconf API and ABI. * Another solution I might not think about right now. Regis -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1333232643.1936.18.ca...@x200s.malip.net
Re: error on live-cd
Flávio, On 02/04/12 10:46 AM, Nilton Seixas wrote: I'm Flávio, a student at Federal University of Bahia. I found an error when trying to make a live cd. The settings were defaults. Only typed commands lb lb config and build. The error was as follows: W: Failed to fetch var/lib/apt/lists/partial/cdn.debian.net_debian_dists_wheezy_main_i18n_Translation-en copy :/ Encountered a section with the Package: header. First of all, this question is not appropriate for this list, but should be asked on debian-l...@lists.debian.org, which I have CC'd in this reply. Please follow up to that list only, dropping debian-boot from your CC. Second, the bug appears to be this one in apt: http://bugs.debian.org/657560 Although it appears that adding the new version of apt in experimental to your image configuration would fix this, I would be hesitant to build a live image using an apt from experimental for anything other than testing purposes. If it were me, I would try 'lb config --mirror-binary some.other.mirror' first. Though if this particular configuration is as common as comment #49 suggests, it may be hard to find a suitable candidate by trial and error. Ben -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f7a4330.8050...@sanctuary.nslug.ns.ca
Bug#415634: Update
With KDE 4.7, things are quite different. We have new metapackages, including a convenient kde-standard, which is pretty much the same as the proposed kde-typical. Considering that kaffeine is less interesting now (kaboodle was replaced by dragonplayer), the only important thing from kde-extras-typical that's still not installed by kde-standard is amarok. Amarok has changed too. Installing it on my not-so-barebone KDE (kde-standard is installed) now adds 99 MB (installed size): amarok amarok-common amarok-utils kdemultimedia-kio-plugins libgpod-common libgpod4-nogtk liblastfm0 libloudmouth1-0 libqjson0 libqtscript4-core libqtscript4-gui libqtscript4-network libqtscript4-sql libqtscript4-uitools libqtscript4-xml libtag-extras Amarok itself is 78 MB. JuK is still just 1 MB. Now that KDE has changed (see http://dot.kde.org/2009/11/24/repositioning-kde-brand?page=1 ) I think we could make kde-standard depend on either JuK or Amarok, and not need to change task-kde-desktop. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f7a4a8e.8040...@gmail.com
Bug#666974: installs to /dev/sda when grub-installer/bootdev = /dev/sdb
Package: grub-installer Version: 1.60+squeeze3 Severity: important *** Please type your report below this line *** When I specify in my preseeding file: d-i partman-auto/disk string /dev/sdb d-i grub-installer/bootdev string /dev/sdb grub-installer ignores me and installs to /dev/sda. partman-auto does the right thing. In some cases this can result in an unbootable system. Attached is a syslog excerpt for the execution of grub-installer, with DEBCONF_DEBUG=5 set in the boot line. You can see that it reads in the right disk name from the preseeding file, but somewhere in the step_os_probe .. step_bootdev .. step_install_loader sequence it changes $bootdev to /dev/sda. I have also observed (on other installations, using software RAID-1) that d-i grub-installer/bootdev string /dev/sda /dev/sdb is read in but also ultimately ignored and grub-installer only installs to /dev/sda. This installation was on a machine with two hard disks of identical size, but only one was intended to be used in the installation. The partioning was one ext3 partition for /, and one LVM for everything else. No separate /boot partition. No software raid is specified. I was able to stop the installer at the end and ran grub-installer again on one of the installer consoles: sh -vx /usr/bin/grub-installer /target 1/target/var/log/gi 21 This shows the problem comes when parsing the grub-mkdevicemap output. + os-prober + db_settitle debian-installer/grub-installer/title + _db_cmd SETTITLE debian-installer/grub-installer/title + IFS= printf %s\n SETTITLE debian-installer/grub-installer/title + IFS= read -r _db_internal_line + RET=OK + return 0 + tmpfile=/tmp/menu.lst.extras + [ -s /tmp/os-probed ] + q=grub-installer/only_debian + state=1 + [ ] + chroot /target grub-mkdevicemap --no-floppy -m+ -head -n1 + cut -f2 + default_bootdev_os=/dev/disk/by-id/scsi-35000c50017a6040b + [ /dev/disk/by-id/scsi-35000c50017a6040b ] + chroot /target readlink -f /dev/disk/by-id/scsi-35000c50017a6040b + default_bootdev=/dev/sda when I run that grub-mkdevicemap on the host after installation, I get: # grub-mkdevicemap --no-floppy -m - (hd0) /dev/disk/by-id/scsi-35000c50017a6040b (hd1) /dev/disk/by-id/scsi-35000c50017a7843b so it seems that there is a disconnect here from the specification of $bootdev and the attempt to guess $default_bootdev_os. The consequences are as follows. A little further down the script there is this, er, dense if statement: case $ARCH:$grub_package in *:grub|*:grub-pc|sparc:grub-ieee1275) if [ $(device_to_disk $cdsrc) = $default_bootdev ] || \ ([ -n $hdsrc ] [ $(device_to_disk $hdsrc) = $default_bootdev ]) || \ ([ $default_bootdev = '(hd0)' ] \ (([ -n $cdfs ] [ $cdfs != iso9660 ]) || \ [ $hybrid = true ])) || \ ([ $default_bootdev != '(hd0)' ] \ ! partmap $default_bootdev /dev/null \ ! grub_probe -t fs -d $default_bootdev /dev/null); then db_fget grub-installer/bootdev seen if [ $RET != true ]; then bootfs=$(findfs /boot) [ $bootfs ] || bootfs=$(findfs /) disk=$(device_to_disk $bootfs) db_set grub-installer/bootdev $disk state=2 fi fi ;; ... This fails out at the $default_bootdev = '(hd0)' comparison. + device_to_disk + echo + sed s:\(/dev/\(cciss\|ida\|rs\)/c[0-9]d[0-9][0-9]*\|/dev/mmcblk[0-9]\|/dev/\(ad\|da\)[0-9]\+\|/dev/[a-z]\+\).*:\1: + [ = /dev/sda ] + [ -n ] + [ /dev/sda = (hd0) ] Then we come to step_bootdev, a loop that continues until we have a suitable value of $state. There $default_bootdev supercedes what I set $bootdev to. $state is already set to 1 and $q to grub-installer/only_debian (see above). db_progress STEP 1 db_progress INFO grub-installer/progress/step_bootdev while : ; do if [ $state = 1 ]; then db_input high $q || true if ! db_go; then # back up to menu db_progress STOP exit 10 fi db_get $q if [ $RET = true ]; then bootdev=$default_bootdev break else # Exit to menu if /boot is on SATA RAID/multipath; we # don't support device selection in that case if [ $frdev ]; then db_progress STOP exit 10 fi state=2 fi ... + db_progress STEP 1 + _db_cmd PROGRESS STEP 1 + IFS= printf %s\n PROGRESS STEP 1 + IFS= read -r _db_internal_line RET=OK + return 0 + db_progress INFO grub-installer/progress/step_bootdev + _db_cmd PROGRESS
Bug#666977: [src:tasksel] Please remove dependencies of tasks on tasksel
Source: tasksel Version: 3.08 Severity: wishlist This is similar to #413250, making tasks usable without having to install tasksel. Now having packages for tasks is great (although it does make a fair amount of task packages!), as tasks can now be used without using tasksel. But tasks cannot yet be used without *installing* tasksel, as installing these tasks requires the administrator to also install tasksel. For example, task-kde-desktop depends on tasksel. The only reason task-kde-desktop depends on tasksel is that /usr/share/doc/task-kde-desktop is a symlink to /usr/share/doc/tasksel. This contains tasksel's changelog, README, TODO and copyright. TODO and README are more confusing than helpful for tasks. That leaves the changelog and copyright. Only the changelog has a significant size. These could either be duplicated in all task packages, or a new dependency package could be created (for example, tasks-common or tasksel-common). I wouldn't mind a dependency on tasksel-data if tasksel-data wouldn't depend on tasksel. My problem with this dependency is not tasksel itself, but tasksel's dependency on aptitude. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f7a64da.9090...@gmail.com
Bug#413250: Fwd: Bug#666977: Acknowledgement ([src:tasksel] Please remove dependencies of tasks on tasksel)
Original Message Subject: Bug#666977: Acknowledgement ([src:tasksel] Please remove dependencies of tasks on tasksel) Date: Tue, 03 Apr 2012 02:51:04 + From: ow...@bugs.debian.org (Debian Bug Tracking System) Reply-To: 666...@bugs.debian.org To: Filipus Klutiero chea...@gmail.com Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Install System Teamdebian-boot@lists.debian.org If you wish to submit further information on this problem, please send it to 666...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 666977: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666977 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#666974: Acknowledgement (installs to /dev/sda when grub-installer/bootdev = /dev/sdb)
I realised the code fragments I showed are from master, not the squeeze branch. However I don't think it makes a difference. Firstly the code parsing grub-mkdevicemap has not changed. Secondly even if the condition ([ $default_bootdev != '(hd0)' ] \ ! partmap $default_bootdev /dev/null \ ! grub_probe -t fs -d $default_bootdev /dev/null); then is met, I think that because of the preseeding db_fget grub-installer/bootdev seen $RET will be true so that the code checking where /boot comes from if [ $RET != true ]; then bootfs=$(findfs /boot) [ $bootfs ] || bootfs=$(findfs /) disk=$(device_to_disk $bootfs) db_set grub-installer/bootdev $disk state=2 fi (which might fix the problem) will never run. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120403044109.gf23...@mayhem.atnf.csiro.au
