Bug#783287: Debian installer RC3 problem
Package: installation-reports Boot method: installer Image version: http://cdimage.debian.org/cdimage/weekly-builds/arm64/iso-dvd/ Date: 2015/04/25 Machine: APM Mustang Processor: ARMv8 Memory: 8GB Partitions: Output of lspci -knn (or lspci -nn): Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: EFI loader brings a grub prompt, but when I type configfile (memdisk)/boot/grub/grub.cfg error: no such device: /.disk/info. I have still time to use Mustang, developer's help is appreciated.
Bug#783304: debian-installer: Autoinstall fails waiting on realtek 8169 firmware despite having working wired network connection
Package: debian-installer Version: 20150422 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Selecting auto install: hangs waiting for firmware, same hardware works fine if expert install used * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? System is zotac zbox id-6 - normally requires radeon, realtek, wifi firmware. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150425160644.2549.41161.report...@thinkpad.localnet.net
Bug#783304: debian-installer: Autoinstall fails waiting on realtek 8169 firmware despite having working wired network connection
Andrew M.A. Cater (2015-04-25): > Package: debian-installer > Version: 20150422 > Severity: normal > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > > Selecting auto install: hangs waiting for firmware, same hardware works fine > if expert install used >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > System is zotac zbox id-6 - normally requires radeon, realtek, wifi firmware. We'll need to know more. Are you actually supplying firmwares? If so, how? What are you doing for this firmware step when performing a (manual?) expert install? Also, what's the contents of syslog in the “hanging” case? Mraw, KiBi. signature.asc Description: Digital signature
Bug#783247: Please don't install acpid and acpi-support-base
m...@linux.it (Marco d'Itri) writes: > On Apr 24, Michael Biebl wrote: > >> A while ago, I already filed a bug to have acpid and acpi-support-base >> removed from tasksel [1], since it duplicates functionality which is >> nowadays provided by systemd/logind. > Indeed they are not needed when systemd is used (but are still required > on sysvinit systems). Are you sure about this? It was my first reaction as well, but then I remembered the troubles I had with logind conflicting with my acpid based setup. logind duplicates the functionality provided acpid and acpi-support-base defaults. And logind seems to be mandatory regardless of init system. So I guess acpid and acpi-support-base should be removed from tasksel. Bjørn -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87pp6sj6jn@nemi.mork.no
Bug#783247: Please don't install acpid and acpi-support-base
Am 25.04.2015 um 22:29 schrieb Bjørn Mork: > m...@linux.it (Marco d'Itri) writes: >> On Apr 24, Michael Biebl wrote: >> >>> A while ago, I already filed a bug to have acpid and acpi-support-base >>> removed from tasksel [1], since it duplicates functionality which is >>> nowadays provided by systemd/logind. >> Indeed they are not needed when systemd is used (but are still required >> on sysvinit systems). > > Are you sure about this? It was my first reaction as well, but then I > remembered the troubles I had with logind conflicting with my acpid > based setup. > > logind duplicates the functionality provided acpid and acpi-support-base > defaults. And logind seems to be mandatory regardless of init system. > So I guess acpid and acpi-support-base should be removed from tasksel. acpid and acpi-support-base have already been removed from tasksel. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: translations for d-i manual [ Was: Re: Status of D-I translations... ]
On Thu, Mar 12, 2015 at 08:48:47PM +0100, Holger Wansing wrote: > The situation for the d-i manual is similar: we have some languages, > that did not receive no or nearly no translation updates since the > release of Wheezy. > Should those languages be deactivated? > These are:japanese (no update since 17 months) > russian (no update since 24 months) > swedish (no update since 2 years 7 months) > vietnamese (no update since 2 years 7 months) > chinese zh_CN (no update since 2 years 3 months) > All of them are po-based translations, so the manuals are strictly > spoken not outdated (changed paragraphs fall-back to english), but it of > no good use for users probably? Even though the documents are not translated fully some content might still be useful. Also, showing that the translation is not finished, but partial, might actually spur some people to take it over. I think it would be best to keep the languages and try to find a way to (automatically) add a disclaimer to the top of the document saying something like: "This document is not fully translated and it is not actively being updated. If you can help please contact x" When I mean automatically I mean that the text should be added when the PO statistics show a large part of the content untranslated. Best regards Javier signature.asc Description: Digital signature
Bug#783247: Please don't install acpid and acpi-support-base
On Apr 25, Bjørn Mork wrote: > > Indeed they are not needed when systemd is used (but are still required > > on sysvinit systems). > Are you sure about this? It was my first reaction as well, but then I > remembered the troubles I had with logind conflicting with my acpid > based setup. Yes: I checked. -- ciao, Marco pgpt49Ar6IA0p.pgp Description: PGP signature
Bug#783323: Broken configuration for OpenBlocks AX3-4
Package: flash-kernel Version: 3.35 Severity: important flash-kernel has this entry for the OpenBlocks AX3-4: Machine: PlatHome OpenBlocks AX3-4 board Kernel-Flavors: armmp DTB-Id: armada-xp-openblocks-ax3-4.dtb DTB-Append: yes U-Boot-Kernel-Address: 0x200 U-Boot-Kernel-Entry-Point: 0x240 U-Boot-Initrd-Address: 0x0 Boot-Device: /dev/sda1 Boot-Kernel-Path: /boot/uImage Boot-Initrd-Path: /boot/uInitrd Boot-DTB-Path: /boot/dtb Required-Packages: u-boot-tools Firstly, the Armada XP supports LPAE and the installer selects the armmp-lpae kernel by default. This makes it impossible to boot from the files on the installed system. Secondly, if the installation uses LVM, /dev/sda1 is the /boot partition, not the root partition. After fixing the first problem, flash-kernel fails like this: # flash-kernel 3.16.0-4-armmp-lpae Installing armada-xp-openblocks-ax3-4.dtb into /boot/dtb-3.16.0-4-armmp-lpae Taking backup of dtb-3.16.0-4-armmp-lpae. Installing new dtb-3.16.0-4-armmp-lpae. Installing armada-xp-openblocks-ax3-4.dtb into /boot/dtb-3.16.0-4-armmp-lpae Taking backup of dtb-3.16.0-4-armmp-lpae. Installing new dtb-3.16.0-4-armmp-lpae. flash-kernel: installing version 3.16.0-4-armmp-lpae Generating kernel u-boot image... done. Will use /dev/sda1 as boot device. Installing new uImage. mv: cannot move '/tmp/flash-kernel.3ft8lyny/uImage' to '/tmp/flash-kernel.V2iwAjyz//boot/uImage': No such file or directory Removing /boot from the file paths fixes this, but of course it would break configurations without a separate /boot. I don't know whether there's a good way to deal with both configurations. Maybe you should bodge it by creating the /boot/boot directory in this case? Thirdly, the machine name is not quite accurate - this is not just a board but a complete product with a custom case. Ben. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150425223944.27117.91960.report...@deadeye.wl.decadent.org.uk
Re: breaks initramfs if BUSYBOX=n
On Sat, 25 Apr 2015 16:22:13 +0200 Michael Biebl wrote: > Package: cryptsetup > Version: 2:1.6.6-5 > Severity: grave > > Hi, > > if the cryptsetup package is installed, it also installed a > initramfs-tools hook. > > I use BUSYBOX=no in initramfs.conf, but the cryptroot hook copies > /bin/busybox to the initramfs nonetheless. > > As a result, the initramfs is unable to boot the system > > I'm getting > Begin: Running /scripts/init-bottom ... done > /init: exec: line 338: switch_root: not found > ...Kernel panic -n not syncing: Attempted to kill init > > > To reproduce the bug, make sure you have the "busybox" package installed > (which it is, by default), set BUSYBOX=n in > /etc/initramfs-tools/initramfs.conf and run "update-initramfs -u" and > reboot. > I looked into this in more detail, and the culprit seems to be /usr/share/initramfs-tools/conf-hooks.d/cryptsetup which forcefully set's BUSYBOX=y. /usr/share/initramfs-tools/hooks/busybox will see the BUSYBOX=y setting and copy the busybox binary. /usr/share/initramfs-tools/hooks/zz-busybox sources /etc/initramfs-tools/initramfs.conf, therefor BUSYBOX=n will be set again, and the symlinks are not created. The result is a broken initramfs. I'm not sure, what is supposed to take precedence in such a case: The configuration in /etc/initramfs-tools/initramfs.conf or /usr/share/initramfs-tools/conf-hooks.d/cryptsetup and if it's a bug in cryptsetup which forcefully overrides BUSYBOX= or if it's a bug in busybox, which sources /etc/initramfs-tools/initramfs.conf in /usr/share/initramfs-tools/hooks/zz-busybox and therefor doesn't respect the settings which are set via conf-hooks.d. I've CCed the initramfs-tools and busybox maintainers for their input. If cryptsetup really requires busybox and forcefully sets BUSYBOX=y, why does the cryptsetup package not depend on busybox? I see several possible fixes here a/ /usr/share/initramfs-tools/hooks/zz-busybox doesn't source /etc/initramfs-tools/initramfs.conf directly and as a result respects settings from hooks directories. b/ /usr/share/initramfs-tools/conf-hooks.d/cryptsetup drops the BUSYBOX=y line. And if this is not an option, because cryptsetup requires busybox, then this should be reflected in the package dependencies accordingly by making the Recommends a Depends. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#783323: Broken configuration for OpenBlocks AX3-4
On Sat, 25 Apr 2015 23:39:44 +0100 Ben Hutchings wrote: > Secondly, if the installation uses LVM, /dev/sda1 is the /boot > partition, not the root partition. After fixing the first problem, > flash-kernel fails like this: Actually, this doesn't depend on LVM. The installer always creates a separate /boot partition using the ext2 filesystem, and this makes sense as u-boot generally doesn't support ext4. So I think that the /boot prefix should be removed from the paths for this entry. (And maybe many other entries.) (I know u-boot has optional support for ext4 now, but there's no sign of it in this version. For reference, that's: U-Boot 2011.12 (Aug 26 2013 - 13:08:34) Plat'Home version: 2.0.7 (Marvell version: 2012_Q4.0p17) ) Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your sig. signature.asc Description: This is a digitally signed message part
Bug#783247: Please don't install acpid and acpi-support-base
Quoting Michael Biebl (bi...@debian.org): > Package: hw-detect > Version: 1.108 > Severity: normal > Tags: patch > > Hi! > > While installing a jessie (GNOME) desktop with the latest RC3 installer, > I noticed that we still install acpid and acpi-support-base. > > A while ago, I already filed a bug to have acpid and acpi-support-base > removed from tasksel [1], since it duplicates functionality which is > nowadays provided by systemd/logind. > > The same reasons apply to debian-installer. > I therefor would like to see those packages dropped from hw-detect as > well. For the record, I plan to commit your patch to D-I's git as soon as Cyril officially raises the "virtual freeze" we currently have in D-I packages (master branches being targeted at the Jessie release). signature.asc Description: Digital signature
