Bug#870869: Segfault during libc-l10n install on kirkwood (armel)
Package: base-installer Version: 1.169 While trying to install stretch on a QNAP 419PII, the installation consistently fails with a segfault in dpkg when it tries to install locales and libc-l10n. I install using the method described here: http://www.cyrius.com/debian/kirkwood/qnap/ts-41x/install/ Using the kernel-6282, (even though the kirkwood-qnap script can't auto-detect the right kernel version on a 419PII) kernel/initrd md5sum: e923a276eb14e6c5b58c283b30ea5d95 flash-debian 3bf2ade97a4ca7f853ff20a058313b17 initrd 286116d8b838ab5abfb069bc79f7cf09 kernel-6281 436b54c0d0299833c3ed58444c158fae kernel-6282 6fb0e16e925c9412dc7f165477790304 model I'm installating the root file system to an external USB3 disk using manual install (to preserve my RAID system on the main disks) System information: === # cat /proc/cpuinfo processor : 0 model name : Feroceon 88FR131 rev 1 (v5l) BogoMIPS: 1974.27 Features: swp half thumb fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant : 0x2 CPU part: 0x131 CPU revision: 1 Hardware: Marvell Kirkwood (Flattened Device Tree) Revision: Serial : = # lspci -knn 00:01.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device [11ab:6282] (rev 01) 00:02.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device [11ab:6282] (rev 01) 01:00.0 SCSI storage controller [0100]: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port SATA-II [11ab:7042] (rev 02) Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab] Kernel driver in use: sata_mv Kernel modules: sata_mv 02:00.0 USB controller [0c03]: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] (rev 01) Subsystem: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] Kernel driver in use: xhci_hcd Kernel modules: xhci_pci = # cat /sys/bus/soc/devices/soc0/family Marvell # cat /sys/bus/soc/devices/soc0/soc_id 6282 # cat /sys/bus/soc/devices/soc0/revision 1 = /var/log/syslog of the install: Aug 5 15:18:21 debootstrap: Creating /etc/network/interfaces. Aug 5 15:18:22 debootstrap: Created symlink /etc/systemd/system/multi-user.target.wants/networking.service -> /lib/systemd/system/networking.service. Aug 5 15:18:22 debootstrap: Created symlink /etc/systemd/system/network-online.target.wants/networking.service -> /lib/systemd/system/networking.service. Aug 5 15:18:22 debootstrap: Setting up apt-utils (1.4.7) ... Aug 5 15:18:22 debootstrap: Setting up debconf-i18n (1.5.61) ... Aug 5 15:18:22 debootstrap: Setting up whiptail (0.52.19-1+b1) ... Aug 5 15:18:22 debootstrap: Setting up gnupg (2.1.18-6) ... Aug 5 15:18:22 debootstrap: Setting up libgnutls30:armel (3.5.8-5+deb9u2) ... Aug 5 15:18:22 debootstrap: Setting up wget (1.18-5) ... Aug 5 15:18:22 debootstrap: Setting up tasksel (3.39) ... Aug 5 15:18:24 debootstrap: Setting up tasksel-data (3.39) ... Aug 5 15:18:24 debootstrap: Processing triggers for libc-bin (2.24-11+deb9u1) ... Aug 5 15:18:24 debootstrap: Processing triggers for systemd (232-25+deb9u1) ... Aug 5 15:18:24 apt-install: Queueing package qcontrol for later installation Aug 5 15:18:25 base-installer: Ign:1 http://ftp.dk.debian.org/debian stretch InRelease Aug 5 15:18:25 base-installer: Hit:2 http://ftp.dk.debian.org/debian stretch Release Aug 5 15:18:25 base-installer: Get:4 http://ftp.dk.debian.org/debian stretch/main Translation-en [5393 kB] Aug 5 15:18:36 base-installer: Fetched 5393 kB in 11s (481 kB/s) Aug 5 15:18:36 base-installer: Reading package lists... Aug 5 15:18:45 base-installer: Aug 5 15:18:48 in-target: Reading package lists... Aug 5 15:18:48 in-target: Aug 5 15:18:48 in-target: Building dependency tree... Aug 5 15:18:49 in-target: Aug 5 15:18:50 in-target: The following additional packages will be installed: Aug 5 15:18:50 in-target: libc-l10n Aug 5 15:18:50 in-target: The following NEW packages will be installed: Aug 5 15:18:50 in-target: libc-l10n locales Aug 5 15:18:50 in-target: 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Aug 5 15:18:50 in-target: Need to get 4109 kB of archives. Aug 5 15:18:50 in-target: After this operation, 13.8 MB of additional disk space will be used. Aug 5 15:18:50 in-target: Get:1 http://ftp.dk.debian.org/debian stretch/main armel libc-l10n all 2.24-11+deb9u1 [820 kB] Aug 5 15:18:50 in-target: Get:2 http://ftp.dk.debian.org/debian stretch/main armel locales all 2.24-11+deb9u1 [3290 kB] Aug 5 15:18:53 in-target: Preconfiguring packages ... Aug 5 15:18:53 in-target: Fetched 4109 kB in 0s (4657 kB/s) Aug 5 15:18:53 in-target: Selecting previously unselected
Re: RFC: Switching guided partitioning to LVM by default?
On Sat, Aug 05, 2017 at 04:06:49PM -0400, Cyril Brulebois wrote: > Current default is the first entry, and I think we should switch to > second one, with LVM. I agree & yay! -- cheers, Holger signature.asc Description: Digital signature
Re: RFC: Switching guided partitioning to LVM by default?
Le samedi, 5 août 2017, 22.20:21 h EDT Geert Stappers a écrit : > When we take LVM as default (which is fine for me) > then we should have the courage to have free PE. > So not assign all diskspace. Yes. I just tried on a stretch mini.iso, if you pick "Guided - use a whole disk with LVM" , the default partitioning you get is "All files in one partition" : 254.8 Mb /boot on ext2 107.1 Gb lvm in which … 1.1 Gb of swap 106 Gb / If we go the LVM by default route, I'd at least consider making the LVM not entirely filled, and maybe also swap the default to a separate /home. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: RFC: Switching guided partitioning to LVM by default?
On Sat, Aug 05, 2017 at 04:06:49PM -0400, Cyril Brulebois wrote: > Is anyone aware of any drawbacks of switching to LVM by default? - It makes sharing the disk with other operating systems harder: partman requires that the LVM PVs are committed to disk before you can play around with LVs, and since "use the whole disk" creates a single whole-disk partition for the LVM PV, there will be no space left for the other operating system if that does not support Linux's LVM. A user who would wish to create a partition for an alternate operating system after going through the LVM step would have to destroy all LVM LVs, destroy the VG, destroy the PVs, change the size of the partition, and then recreate everyhing again. - Last I checked (but this may have been changed), the LVM VG created by the partitioner is given a default name, which confuses the kernel if you place a disk containing another LVM VG with that same name in the same machine. This makes recovering a system by placing its disk into a different machine needlessly complicated. - While LVM is indeed more flexible than plain partitions, it does add some overhead in terms of metadata, which is not necessarily useful if the user is only interested in installing to a single hard disk. All in all, I'm not convinced that switching this default will be a net plus for our users. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: RFC: Switching guided partitioning to LVM by default?
On Sat, Aug 5, 2017 at 2:06 PM, Cyril Brulebois wrote: > Hi, > > While preparing some slides for my “News from the Debian Installer” talk > at DebConf17, it occured to me that we might want to reconsider the > default here: > > Guided - use a whole disk > Guided - use a whole disk with LVM > Guided - use a whole disk with encrypted LVM > Manual > > Current default is the first entry, and I think we should switch to > second one, with LVM. > > If the user doesn't need to touch anything, that doesn't change much; if > the user wants to change partitioning afterwards, LVM's flexibility is > available. > > Is anyone aware of any drawbacks of switching to LVM by default? > It makes it harder to share partitions with other operating systems in a dual boot setup, particularly a fat32 partition with windows is problematic, so nothing that matters. Actually in all seriousness, other than the dual boot issue doing a guided partitioning then changing things like deleting a partition is not well supported by the installer. It is seldom a problem for me these days as I preseed everything. > > > KiBi. > -- -- Ben Hildred Automation Support Services
Re: RFC: Switching guided partitioning to LVM by default?
On Sat, Aug 05, 2017 at 04:06:49PM -0400, Cyril Brulebois wrote: > Hi, > > While preparing some slides for my ???News from the Debian Installer??? talk > at DebConf17, it occured to me that we might want to reconsider the > default here: > > Guided - use a whole disk > Guided - use a whole disk with LVM > Guided - use a whole disk with encrypted LVM > Manual > > Current default is the first entry, and I think we should switch to > second one, with LVM. > > If the user doesn't need to touch anything, that doesn't change much; if > the user wants to change partitioning afterwards, LVM's flexibility is > available. > > Is anyone aware of any drawbacks of switching to LVM by default? > When we take LVM as default (which is fine for me) then we should have the courage to have free PE. So not assign all diskspace. Advantages: * user gets the benefit of LVM: assigning space to a file system * quicker install ( no formatting/mkfs of whole disk ) * no need to shrink /home so space can be used for /srv Disavantage, in theory: * user might miss disk space Groeten Geert Stappers -- Leven en laten leven
RFC: Switching guided partitioning to LVM by default?
Hi, While preparing some slides for my “News from the Debian Installer” talk at DebConf17, it occured to me that we might want to reconsider the default here: Guided - use a whole disk Guided - use a whole disk with LVM Guided - use a whole disk with encrypted LVM Manual Current default is the first entry, and I think we should switch to second one, with LVM. If the user doesn't need to touch anything, that doesn't change much; if the user wants to change partitioning afterwards, LVM's flexibility is available. Is anyone aware of any drawbacks of switching to LVM by default? KiBi. signature.asc Description: Digital signature
Bug#870615: debian-installer: FTBFS on armhf: missing firefly-rk3288/u-boot.img
Vagrant Cascadian (2017-08-05): > Looks like either no version, or an older version was installed: > > https://d-i.debian.org/daily-images/armhf/20170805-00:05/build_hd-media.log > dpkg-checkbuilddeps: error: Unmet build dependencies: u-boot-rockchip (>= > 2017.07+dfsg1-3) Oh right, I only looked at the bottom of the output. For some reason, the dpkg-checkbuilddeps error didn't prevent the build to go through and test building other targets… Sorry for the noise. Will keep an eye on this. KiBi. signature.asc Description: Digital signature
Bug#870615: debian-installer: FTBFS on armhf: missing firefly-rk3288/u-boot.img
On 2017-08-05, Vagrant Cascadian wrote: > On 2017-08-05, Cyril Brulebois wrote: >> Cyril Brulebois (2017-08-05): >>> Vagrant Cascadian (2017-08-04): >>> > And now fixed in u-boot 2017.07+dfsg1-3 (just uploaded), corresponding >>> > fix in debian-installer pushed to git. >>> >>> OK, I've just triggered a new “daily” attempt since the first one failed >>> (the versioned build-dep wasn't available yet). See you around! >> >> It resulted in: >> | Providing u-boot binaries for Firefly-RK3288 ... >> | cp: cannot stat '/usr/lib/u-boot/firefly-rk3288/u-boot.rksd': No such file >> or directory >> | config/armhf//u-boot.cfg:8: recipe for target 'u-boot-binaries' failed >> | make[2]: *** [u-boot-binaries] Error 1 > > What version of u-boot-rockchip was installed at the time of the build? > It appears to be present in u-boot-rockchip from sid: > > lesspipe u-boot-rockchip_2017.07+dfsg1-3_armhf.deb | grep rksd > -rw-r--r-- root/root 26624 2017-08-04 15:56 > ./usr/lib/u-boot/firefly-rk3288/u-boot-spl.rksd > -rw-r--r-- root/root427127 2017-08-04 15:56 > ./usr/lib/u-boot/firefly-rk3288/u-boot.rksd Looks like either no version, or an older version was installed: https://d-i.debian.org/daily-images/armhf/20170805-00:05/build_hd-media.log dpkg-checkbuilddeps: error: Unmet build dependencies: u-boot-rockchip (>= 2017.07+dfsg1-3) live well, vagrant signature.asc Description: PGP signature
Bug#870615: debian-installer: FTBFS on armhf: missing firefly-rk3288/u-boot.img
On 2017-08-05, Cyril Brulebois wrote: > Cyril Brulebois (2017-08-05): >> Vagrant Cascadian (2017-08-04): >> > And now fixed in u-boot 2017.07+dfsg1-3 (just uploaded), corresponding >> > fix in debian-installer pushed to git. >> >> OK, I've just triggered a new “daily” attempt since the first one failed >> (the versioned build-dep wasn't available yet). See you around! > > It resulted in: > | Providing u-boot binaries for Firefly-RK3288 ... > | cp: cannot stat '/usr/lib/u-boot/firefly-rk3288/u-boot.rksd': No such file > or directory > | config/armhf//u-boot.cfg:8: recipe for target 'u-boot-binaries' failed > | make[2]: *** [u-boot-binaries] Error 1 What version of u-boot-rockchip was installed at the time of the build? It appears to be present in u-boot-rockchip from sid: lesspipe u-boot-rockchip_2017.07+dfsg1-3_armhf.deb | grep rksd -rw-r--r-- root/root 26624 2017-08-04 15:56 ./usr/lib/u-boot/firefly-rk3288/u-boot-spl.rksd -rw-r--r-- root/root427127 2017-08-04 15:56 ./usr/lib/u-boot/firefly-rk3288/u-boot.rksd live well, vagrant signature.asc Description: PGP signature
Bug#870615: debian-installer: FTBFS on armhf: missing firefly-rk3288/u-boot.img
Cyril Brulebois (2017-08-05): > Vagrant Cascadian (2017-08-04): > > I went with the latter approach, so u-boot-rockchip includes a single > > binary that debian-installer can use. > > > > > > >> Might be best to temporarily disable the firefly-rk3288 in d-i until I > > >> figure out what's best to do... > > > > > > I've disabled it in git for now, will explore a proper fix soon. > > > > And now fixed in u-boot 2017.07+dfsg1-3 (just uploaded), corresponding > > fix in debian-installer pushed to git. > > OK, I've just triggered a new “daily” attempt since the first one failed > (the versioned build-dep wasn't available yet). See you around! It resulted in: | Providing u-boot binaries for Firefly-RK3288 ... | cp: cannot stat '/usr/lib/u-boot/firefly-rk3288/u-boot.rksd': No such file or directory | config/armhf//u-boot.cfg:8: recipe for target 'u-boot-binaries' failed | make[2]: *** [u-boot-binaries] Error 1 KiBi. signature.asc Description: Digital signature
Bug#870615: debian-installer: FTBFS on armhf: missing firefly-rk3288/u-boot.img
Vagrant Cascadian (2017-08-04): > I went with the latter approach, so u-boot-rockchip includes a single > binary that debian-installer can use. > > > >> Might be best to temporarily disable the firefly-rk3288 in d-i until I > >> figure out what's best to do... > > > > I've disabled it in git for now, will explore a proper fix soon. > > And now fixed in u-boot 2017.07+dfsg1-3 (just uploaded), corresponding > fix in debian-installer pushed to git. OK, I've just triggered a new “daily” attempt since the first one failed (the versioned build-dep wasn't available yet). See you around! KiBi. signature.asc Description: Digital signature
Re: Avoiding use of symlinks in d-i archive tar
On Sun, Jul 30, 2017 at 04:45:38PM +0200, Cyril Brulebois wrote: > Yeah. Feel free to propose patches for that then. Pushed as branch "waldi/dedup-links" to debian-installer.git. > > This symlink is handled by the archive anyway. > OK; I would have thought so but I've never looked at implementation details. I looked again and I was wrong. However I'll change that. Bastian -- ... bacteriological warfare ... hard to believe we were once foolish enough to play around with that. -- McCoy, "The Omega Glory", stardate unknown
Bug#794410: installer works now with debian-live-9.0.1-amd64-
The problem with the installer freeze at 12% seems to be solved at the 9.0.1 iso. When i did a fresh install (without additional firmware) with the "debian-live-9.0.1-amd64-xfce.iso" on the Acer Aspire E11 (ES1-111-C5Q9) the process ended up with a fully working debian installation. I previously also tried the "firmware-9.0.0-amd64-netinst.iso" on this laptop but then the installer hangs again at 12% ( installed discover) .
