Bug#851539: Stretch RC1 netinst installer prompts for additional CDs
On Mon, Jan 16, 2017 at 01:13:13AM +, Steve McIntyre wrote: > On Sun, Jan 15, 2017 at 04:53:26PM -0800, Josh Triplett wrote: > >Package: installation-reports > >Severity: normal > > > >I tried doing an install with a Stretch RC1 netinst CD. Worked fine, > >except that later in the install, right before asking about an apt > >mirror, the installer asked about scaning additional CDs. Previous > >versions of the netinst installer haven't asked that question; normally > >only the full-CD installers ask that. > > This is a deliberate change, yes. It makes the firmware netinsts more > useful now, for example... I thought that firmware had a separate prompting mechanism, triggered by the detection of missing firmware? If the installer notices missing firmware, it prompts for separate firmware media. - Josh Triplett
cdebconf_0.220_i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 16 Jan 2017 06:47:22 +0100 Source: cdebconf Binary: cdebconf cdebconf-gtk libdebconfclient0 libdebconfclient0-dev cdebconf-udeb cdebconf-priority libdebconfclient0-udeb cdebconf-text-udeb cdebconf-newt-udeb cdebconf-gtk-udeb Architecture: source i386 all Version: 0.220 Distribution: unstable Urgency: medium Maintainer: Debian Install System TeamChanged-By: Christian Perrier Description: cdebconf - Debian Configuration Management System (C-implementation) cdebconf-gtk - Gtk+ frontend for Debian Configuration Management System cdebconf-gtk-udeb - Gtk+ frontend for Debian Configuration Management System (udeb) cdebconf-newt-udeb - Newt frontend for Debian Configuration Management System (udeb) cdebconf-priority - Change debconf priority (udeb) cdebconf-text-udeb - Plain text frontend for Debian Configuration Management System (udeb) cdebconf-udeb - Debian Configuration Management System (C-implementation) (udeb) libdebconfclient0 - Debian Configuration Management System (C-implementation library) libdebconfclient0-dev - Development files for cdebconf libdebconfclient0-udeb - Debian Configuration Management System (C-implementation) (udeb) Changes: cdebconf (0.220) unstable; urgency=medium . [ Updated translations ] * Bulgarian (bg.po) by Damyan Ivanov Checksums-Sha1: aec7e5104d5982a6ae70a15a93ee5825199957b5 2662 cdebconf_0.220.dsc d011d2d31d27eebfddf1e26157c07c3414e61970 272180 cdebconf_0.220.tar.xz 82d437c1b06b8ed2d9d6d6f66269adca278c1370 229694 cdebconf-dbgsym_0.220_i386.deb 5bf9559ab0e4e67078865d0a6a8efbde2a506f9d 94802 cdebconf-gtk-dbgsym_0.220_i386.deb 83838f651610b6b55f748fec131b3bc20f74 32126 cdebconf-gtk-udeb_0.220_i386.udeb 15ca8683ef5ac60eb3eee8c106f9783284412fa2 75556 cdebconf-gtk_0.220_i386.deb 2aced1de43a02a5b9e6c88814e697c23a04b5740 21340 cdebconf-newt-udeb_0.220_i386.udeb f0ae6138bf62e3a5b46a530a1f06271dbbba38d2 3152 cdebconf-priority_0.220_all.udeb 1002cff01dd44b20af07d229a2e0e4051b183a51 25100 cdebconf-text-udeb_0.220_i386.udeb 022d7e528c16843906d048439a6624b5f216f483 82100 cdebconf-udeb_0.220_i386.udeb 88029ad8301ee5b996d3dec35107665c79c70e44 12767 cdebconf_0.220_i386.buildinfo 52a90d4ab715050f0030794b64b873df4d7c506f 183350 cdebconf_0.220_i386.deb d789ece0f6b56c454eb1d5515845b595eede0881 5462 libdebconfclient0-dbgsym_0.220_i386.deb 31bb378fa1ee4896c9377e7e1e150ca3599330c8 52208 libdebconfclient0-dev_0.220_i386.deb c50161764a9892eb980281e13ee1ec580b5efa0b 3294 libdebconfclient0-udeb_0.220_i386.udeb 2544bc8c48c13304711a0ae368417032378791bd 47760 libdebconfclient0_0.220_i386.deb Checksums-Sha256: b1500394e7e44f0c6a8e476d9997593624ab9de6528ca83b4ab16aa7dc3c040f 2662 cdebconf_0.220.dsc 219f67671868d8ef06b39ae81b9ede335cfff104294ff9745cf7642bb7a336c1 272180 cdebconf_0.220.tar.xz 5e78be70d6394a7559c3fe92721de3cbed01490da5d07667eef8a57c9744370b 229694 cdebconf-dbgsym_0.220_i386.deb 53a5d908087aca57501ac0a190b332905e40036331ad71dfae9eb893df6f580a 94802 cdebconf-gtk-dbgsym_0.220_i386.deb 3c18c16e633410a1b4215520ea130e5807d2364d93812171d294e7bb3c6a5ecf 32126 cdebconf-gtk-udeb_0.220_i386.udeb 555b1427d7f765fa6b2f2d07b2814d46e07417cb2946e85f9236e4ef1d7844ed 75556 cdebconf-gtk_0.220_i386.deb 7dcb53be0aa42b408087c01fec94f71068ee8fd9c346fe46911d6c368c0b0a5f 21340 cdebconf-newt-udeb_0.220_i386.udeb dc8b5b14ce5db2cdb63d0540a0d83b5fcfcc6d11eca7834c2736e31e8d8f9bb7 3152 cdebconf-priority_0.220_all.udeb 6e6af4cf660907842e756aa7e920771a33e97a0529e6a4c63aa9bb381a8e9730 25100 cdebconf-text-udeb_0.220_i386.udeb 6d7443ce5c1b6a44c4c8242ff61eb55ab91e660b7800c0a572de774c4b2029ff 82100 cdebconf-udeb_0.220_i386.udeb 36bd8169d5ae1f3e8623937caa5647206f6e27750d1821288c9a841c4ba9a4e1 12767 cdebconf_0.220_i386.buildinfo 2c8facaf9a06dee79faa0a78d51df6efabc366a1a88a310f03809f2362ffd609 183350 cdebconf_0.220_i386.deb 1017026805a34154d1ecfcb359ad2710338028acf6b4baacf186935b91b34252 5462 libdebconfclient0-dbgsym_0.220_i386.deb 270979eaa015ae29b83e6698bfdea0e67dec07d41984de93e4467a7d0cb56e56 52208 libdebconfclient0-dev_0.220_i386.deb 350b1f1b21d70affac50a2def034856454895734bafd663070704309ed530aa9 3294 libdebconfclient0-udeb_0.220_i386.udeb 8c4918a23aff3ec633f48e1f1c689bcfdfbe2dd42cf885d1eb7a878182886cb8 47760 libdebconfclient0_0.220_i386.deb Files: 00292a546bab1c33162d617474819781 2662 utils optional cdebconf_0.220.dsc 2941a40a22a61ddf5180f1db475866b5 272180 utils optional cdebconf_0.220.tar.xz 3de644e73785873c4d82880ccfcb4dc9 229694 debug extra cdebconf-dbgsym_0.220_i386.deb 4d6acbe328645c09b95d4068094abefe 94802 debug extra cdebconf-gtk-dbgsym_0.220_i386.deb 5b012f45087b5ceda6a31cd0ebb81473 32126 debian-installer optional cdebconf-gtk-udeb_0.220_i386.udeb 99621cc01172e5837eaafd6f98f8ec46 75556 admin extra cdebconf-gtk_0.220_i386.deb 89a7cc3477664f37f77fb567e98f4932 21340 debian-installer optional
hw-detect_1.121_i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 16 Jan 2017 07:11:05 +0100 Source: hw-detect Binary: hw-detect ethdetect disk-detect driver-injection-disk-detect archdetect Architecture: source i386 all Version: 1.121 Distribution: unstable Urgency: medium Maintainer: Debian Install System TeamChanged-By: Christian Perrier Description: archdetect - Hardware architecture detector (udeb) disk-detect - Detect disk drives (udeb) driver-injection-disk-detect - Detect OEM driver injection disks (udeb) ethdetect - Detect network hardware and load kernel drivers for it (udeb) hw-detect - Detect hardware and load kernel drivers for it (udeb) Changes: hw-detect (1.121) unstable; urgency=medium . [ Cyril Brulebois ] * Update firmware-map as of 2017-01-15. Checksums-Sha1: df6d3a1dda88132914103dc8b68c1db468aac3bf 2021 hw-detect_1.121.dsc 71b1d7b37b10af176c15e1d07979b18cffeb25e4 187104 hw-detect_1.121.tar.xz 50414944b58f856ca9014177320efbdd6794ed86 2688 archdetect_1.121_i386.udeb 2235df5991d030e063e5bfeb4edc36b922df02ff 24304 disk-detect_1.121_i386.udeb ed6c92a9c2d0a9983fdf5fa179971004e298fb60 13496 driver-injection-disk-detect_1.121_all.udeb fad2db1e40488206410b49212062199234b0c8cd 30936 ethdetect_1.121_all.udeb 31c6b3939e46321edd98b4e3e2abea92b64f4469 5741 hw-detect_1.121_i386.buildinfo 507a2c393b181bdb9e2714e296cf4bf2a19b3ab3 119874 hw-detect_1.121_i386.udeb Checksums-Sha256: f0dee5cd830dafab807b28ecac66404566a3ff0678502f14fd8274e66591da0b 2021 hw-detect_1.121.dsc f6c6f769b49cf427c8a7519de7a3585f9be70397fd5581e82d4a1ef4ec2f10b6 187104 hw-detect_1.121.tar.xz 1c956be8f9fcee98ca01e6f8f5ef05d95b49891b43a7c027c9c373518f7ab04c 2688 archdetect_1.121_i386.udeb 171d046a796700cd35e67cc8c7b50a997f6be336dcc1a84a48dc593127131b4f 24304 disk-detect_1.121_i386.udeb e2bf054f8fd8e79b8e11d7338338b375354c1a1936aeb0cb5ceaba90a0521745 13496 driver-injection-disk-detect_1.121_all.udeb 50167c407cf5f18a21a6f62161b1ee7322819cbefc21d8418901169839643bf3 30936 ethdetect_1.121_all.udeb 2db2c14ca49d51c1973b8c70a30eea410396876beded99872e7e132776db69d3 5741 hw-detect_1.121_i386.buildinfo e55566da7e8ce890627819f90c81ae4d1c20fc2ef44f3c06ec2fca340abcd9a1 119874 hw-detect_1.121_i386.udeb Files: d3cc576dd23b46042bb437658ad0cc88 2021 debian-installer standard hw-detect_1.121.dsc 406e82682d19de3be8fb6688cae60c89 187104 debian-installer standard hw-detect_1.121.tar.xz 48cd1459df4125d3c0f65fe2ad892537 2688 debian-installer standard archdetect_1.121_i386.udeb e47149c560f0c55d342672e209489507 24304 debian-installer optional disk-detect_1.121_i386.udeb f9cf078d6a6f91ceb5c5d14b23c1c8ba 13496 debian-installer optional driver-injection-disk-detect_1.121_all.udeb 8ef990434bc6602553d96266846902b1 30936 debian-installer optional ethdetect_1.121_all.udeb 85298ed3a7632baf96adb6da622f9902 5741 debian-installer standard hw-detect_1.121_i386.buildinfo 7f270a1c355853b2e7bc2ea2411f9dc6 119874 debian-installer standard hw-detect_1.121_i386.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJYfGdKAAoJEIcvcCxNbiWorSgP/j5egpixgAnzrg7iwk8js9uL J2NoElGNwxe+YdNhvXCs0BiXCRHS5s5HuGCYQn4a+JPWdziWl6Afy4Ps1rvuMc2T 6DNk9YsiOwG0boIrWTMHtRAADZ2EytNeUv4bc+AwewLhFJujjtDiORmSWmcDGEJW QLRzkZg2uTi5YgeQvHCgQPd2NZqRWSt06i1TpD0FaMonZy2AFuienJxaSqzF9a9A SCibt3pNbPjq9oBQI5ZDfVsRg0DkWLtvf6JuGHhPwNnveCHR4aJFAiOuxrdluUUQ MSeFvcG/pHCv7r1RTi0zA8ZK5r4l4jmgrZjm9wzTBqee1DljzeKL3uqY81r3Tpn5 RooWvWTSNhLW1v5SvmA4+OHipIVEjtySGfqwrZ3QjGLcaJCeMaCOYFcqszDvmgT3 j9MwSU76fqrZ/CfVGegrXAKb747dFJ5A4Xv8cDTh0sTrXgE+NZpwtFt/RBz9Xbje ZttigIDwyu3WGXmgGpG/OEfwb1sIbPPW31bY0q686qFwEDzJBvVnUswOx/okN6iv byH8jK5/ZyhgmdC9AyDs3eCCxgNHOYFaOhNBr/TYvCcCIJ/qZ+Z/dnAECADQWDO6 zlfcuAu7wCSY5Rl1I82kRhuA0Je5dJA4Xz3UNuIKid7/DnMlDus5myUD5vzE2P8o 3RuWYGg1gTaPE+Ef0OZ8 =lrXl -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of hw-detect_1.121_i386.changes
hw-detect_1.121_i386.changes uploaded successfully to localhost along with the files: hw-detect_1.121.dsc hw-detect_1.121.tar.xz archdetect_1.121_i386.udeb disk-detect_1.121_i386.udeb driver-injection-disk-detect_1.121_all.udeb ethdetect_1.121_all.udeb hw-detect_1.121_i386.buildinfo hw-detect_1.121_i386.udeb Greetings, Your Debian queue daemon (running on host usper.debian.org)
Processing of cdebconf_0.220_i386.changes
cdebconf_0.220_i386.changes uploaded successfully to localhost along with the files: cdebconf_0.220.dsc cdebconf_0.220.tar.xz cdebconf-dbgsym_0.220_i386.deb cdebconf-gtk-dbgsym_0.220_i386.deb cdebconf-gtk-udeb_0.220_i386.udeb cdebconf-gtk_0.220_i386.deb cdebconf-newt-udeb_0.220_i386.udeb cdebconf-priority_0.220_all.udeb cdebconf-text-udeb_0.220_i386.udeb cdebconf-udeb_0.220_i386.udeb cdebconf_0.220_i386.buildinfo cdebconf_0.220_i386.deb libdebconfclient0-dbgsym_0.220_i386.deb libdebconfclient0-dev_0.220_i386.deb libdebconfclient0-udeb_0.220_i386.udeb libdebconfclient0_0.220_i386.deb Greetings, Your Debian queue daemon (running on host usper.debian.org)
netcfg_1.141_i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 16 Jan 2017 05:56:00 +0100 Source: netcfg Binary: netcfg netcfg-static Architecture: source i386 Version: 1.141 Distribution: unstable Urgency: medium Maintainer: Debian Install System TeamChanged-By: Christian Perrier Description: netcfg - Configure the network (udeb) netcfg-static - Configure a static network (udeb) Changes: netcfg (1.141) unstable; urgency=medium . [ Samuel Thibault ] * Revert work around for bug #769189, it is now fixed. Checksums-Sha1: 90169c40e1d736c5bbeb98743ae2b6b51d0d1c9b 1893 netcfg_1.141.dsc b1af238c52dbfce5c8308758c23ef8c9ca16b9c9 391936 netcfg_1.141.tar.xz 6bdd7f030ae4043e6e0432a2ef7a54b5ae6522e2 343376 netcfg-static_1.141_i386.udeb a88f553772d2a97f2d9394c456642a90cc3e336f 5071 netcfg_1.141_i386.buildinfo d3ba548cf98f629893dd5933758ead141ce9774b 439310 netcfg_1.141_i386.udeb Checksums-Sha256: 57bc37c6f02e25815d823b13982493277bc3ccc72539915900ee46965cd5bf9c 1893 netcfg_1.141.dsc 9d70a88bc90087b7c251ef06b8ca49d69a20280426519af248cbce0e94381a40 391936 netcfg_1.141.tar.xz 4d91321e194ae03f45042cf608b6915f88c2176f8aaa21dd5fe0b2c1b5a8e6ad 343376 netcfg-static_1.141_i386.udeb 1d719b90426ce4511990064c524613650eaecb7c0a21257f855f1ceb9db1705b 5071 netcfg_1.141_i386.buildinfo 0121fa3a06f7cc19d0cda4c2e4f168b275daeb3dd09cd8f29baf8db0d76e4289 439310 netcfg_1.141_i386.udeb Files: c20a646ede39bd596c0cf5563fecb33b 1893 debian-installer optional netcfg_1.141.dsc 71e8c7e8050a8854d034d8a1cc6eb681 391936 debian-installer optional netcfg_1.141.tar.xz 7fbc0ad2471ea757bdb10fd31f57533c 343376 debian-installer optional netcfg-static_1.141_i386.udeb b285719442cc97cf5e2759fe7ef494c5 5071 debian-installer optional netcfg_1.141_i386.buildinfo c8ca98e3a2add10a959799eb8cf6072f 439310 debian-installer optional netcfg_1.141_i386.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJYfGMdAAoJEIcvcCxNbiWowG4P/08mawmuQxUe/BnzjVrb+O+m kJPUipY+/u+D/xv0Hy1BWOgG/4SbXysRn6TuL7k9AHoUr9iEa7JOazwi2CoLBxox QaR40pQP/xaBjWlfsB0msMioUwP5w0/s3Ppu/i+db9KLXe4Ek+txl43MMohNgMCc FnivRUeqs6RMOpc6V3rbLOkBW/Y166faCL1rarYD8ljkfzbYC+BcyUnLj33RdUvm 404AH2jDcc104l+BlS+Ja4ZdPxeF2dOioUomL9cOiJ1K+BFetpUQCNlR0HFUnyzR u0XCSGVoshGrZjuqmOCrTgDR5uC4Py+SmX/mcQ6Ifn5MMJLgRtGo+LPo2YWeao4L T8nzxliojnu02vCBeZoJ0U7kNTkPUPZQG2Nt0gWUa6R52zOcMDTMmMomGD8e+iTs 5KflXVYf/xNfCndUQSR7yRlFvF9oeNMNX9mHYGb60q5pzPGNv3xHyRO1z3S4lkR0 DJ9RaTU499geib9lvnTk6Y22+F/a6d2r9L/aPcc3fuQHS29CZzsxAcxnzL5ASXs6 FnVMops6qekL5SWHbL4u4I+bXjwlz+Lcx0H3CgngAZoHJMTnjDoUc3FYn4+Zisye d6Yl1tzrnr7cPxre+K9vN4OOycOuq8iRhjJIlk15nlA93HBS2+hK1Yy/cSThRPrA E4cW9rn5soGcst1tZXMz =BDoq -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of netcfg_1.141_i386.changes
netcfg_1.141_i386.changes uploaded successfully to localhost along with the files: netcfg_1.141.dsc netcfg_1.141.tar.xz netcfg-static_1.141_i386.udeb netcfg_1.141_i386.buildinfo netcfg_1.141_i386.udeb Greetings, Your Debian queue daemon (running on host usper.debian.org)
kernel-wedge_2.96_i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 15 Jan 2017 08:01:17 +0100 Source: kernel-wedge Binary: kernel-wedge Architecture: source all Version: 2.96 Distribution: unstable Urgency: medium Maintainer: Debian Install System TeamChanged-By: Christian Perrier Description: kernel-wedge - udeb package builder for Debian-Installer Changes: kernel-wedge (2.96) unstable; urgency=medium . [ Cyril Brulebois ] * Fix “strength” typo in kernel-wedge manpage, thanks to victory. Checksums-Sha1: a5184e7fdabf59fb83ec13c3b3c1db5d7180dfed 1673 kernel-wedge_2.96.dsc 1f1abc2a02291d6265ede9decbd8b5e8d487c2a7 38380 kernel-wedge_2.96.tar.xz 07c207fc22818ae385bb717998eadca8e256c1de 39968 kernel-wedge_2.96_all.deb 0cb1ab4c3a2ded1008fa0b9016c9474323d97f9d 4563 kernel-wedge_2.96_i386.buildinfo Checksums-Sha256: b1cbec759e960fa946d4d87f3bb011092f06a4bda45438a287b8f54476f3ac12 1673 kernel-wedge_2.96.dsc 5e36a984d8d4a5b84f14611a7cc7f4b9e491a5377f6dc7200821f09fc78398f1 38380 kernel-wedge_2.96.tar.xz 07fbbb551d0e629bf2902f8ffb2404f9c7b4ec5aeb4f35d88a028d23811e8870 39968 kernel-wedge_2.96_all.deb 3a8c0484b0715b71ff7785583438dc9b940babe6bde200a7cefb52687e954440 4563 kernel-wedge_2.96_i386.buildinfo Files: c0f5c69bf0770ca90a280cbafb629030 1673 utils optional kernel-wedge_2.96.dsc 1f59f5418c9037c2a4b4551ab8ab77b8 38380 utils optional kernel-wedge_2.96.tar.xz aa4b3dbc54f409cc670c1517348b9e8b 39968 utils optional kernel-wedge_2.96_all.deb d7b703f00697ebc42e98e8677e61016b 4563 utils optional kernel-wedge_2.96_i386.buildinfo -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJYfF4vAAoJEIcvcCxNbiWo67EP/iVsLug5L1agdHRmV44e+/1S Q8h6qpf/LKZwQTSsJl6mEvGBSpkDSKOYj/nTInQzQZVRkmZPTiRyD/lrNszIVone apFUU2CZqg7pB2ephWgkr0QtoaoYNV7ttYZKZQexaUqROwdYYm3gPDH5QncEsx1D 1g4S0mdJk5vO2REb9/mlRJx50foNAsBX9vD8nkAeJBb5pmC2yKQXh4JiDhBawt2F vtUdaA7uZtH964HZkMYsYqcgeseiPTlDt+Ng1VukPkftRQpP+8RHqlFe6p3xCR4p 64gPoDdrqJvtP/LWIdbIOj14L/KZ0Rg2Ly4lSOlJLcUlaTD4uJBEb4fYaHmHf7OH j/VbJKRJ8JYOJhq8s/YYF+sum14ymlW9St+MpzQvf9VtlY3DPUuIUU30ZQstyj1e +DgDZg12K7hTtd9UP+AoJY4S+/aC5MiSj2rT0wLuNQ/mUV9GVguUGc5teRue8Zic 6/JMqvB7BHc8k353vMXy1zo6Bg4fG5LjjrAHGon5I91mW70BYc1dEpW0ElVtgum/ PF8fuUQRjGoOsLVPMLnn+v5WBWUq+IoxQ3fpM6JAUZ5SGEknr+xHY+twb0kyIZhM pfpvOejCham/7C+LmxN7cIbapiR6mdS9UrMbgN7a38PoZO8KZUi4TVBaQLj6ODln naEjE4qbIrxsmNMC1tH8 =mMyL -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of kernel-wedge_2.96_i386.changes
kernel-wedge_2.96_i386.changes uploaded successfully to localhost along with the files: kernel-wedge_2.96.dsc kernel-wedge_2.96.tar.xz kernel-wedge_2.96_all.deb kernel-wedge_2.96_i386.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#851526: Please provide command-line option to disable ipv6
On Sun, 2017-01-15 at 17:06 -0700, Nicholas D Steeves wrote: > On Sun, Jan 15, 2017 at 02:43:45PM -0800, Josh Triplett wrote: > > Package: netcfg > > Severity: wishlist > > > > netcfg provides an option to completely disable all automatic > > configuration, but no option to disable ipv6 autoconfig (SLAAC) while > > leaving DHCP enabled. Putting ipv6.disable=1 on the kernel command line > > will cause netcfg to realize the network has no ipv6, but only after > > waiting a similar timeout for a link-local address, defeating the > > purpose. > > > > Please either detect disabled ipv6 and skip those steps, or provide a > > command-line option to disable ipv6 in netcfg. > > > > (Context: repeatedly testing preseed installs in a virtual machine, and > > I don't want to keep waiting on ipv6 autoconfig timing out.) > > > > From what I've read, ipv6.disable=1 hasn't been sufficient for quite > some time, and one requires something like the following in > /etc/sysctl.d/: > > 00-disable-ipv6.conf: > net.ipv6.conf.all.disable_ipv6 = 1 > net.ipv6.conf.default.disable_ipv6 = 1 > net.ipv6.conf.lo.disable_ipv6 = 1 You read wrong. ipv6.disable=1 does all that, and more. (See https://kernel.org/doc/Documentation/networking/ipv6.txt) Ben. -- Ben Hutchings Every program is either trivial or else contains at least one bug signature.asc Description: This is a digitally signed message part
Bug#851539: Stretch RC1 netinst installer prompts for additional CDs
On Sun, Jan 15, 2017 at 04:53:26PM -0800, Josh Triplett wrote: >Package: installation-reports >Severity: normal > >I tried doing an install with a Stretch RC1 netinst CD. Worked fine, >except that later in the install, right before asking about an apt >mirror, the installer asked about scaning additional CDs. Previous >versions of the netinst installer haven't asked that question; normally >only the full-CD installers ask that. This is a deliberate change, yes. It makes the firmware netinsts more useful now, for example... -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Bug#851539: Stretch RC1 netinst installer prompts for additional CDs
Package: installation-reports Severity: normal I tried doing an install with a Stretch RC1 netinst CD. Worked fine, except that later in the install, right before asking about an apt mirror, the installer asked about scaning additional CDs. Previous versions of the netinst installer haven't asked that question; normally only the full-CD installers ask that. - Josh Triplett
Bug#851537: Please support preseeding an empty domain to prevent prompting
Package: netcfg Severity: wishlist netcfg supports preseeding the domain via netcfg/get_domain, but providing an empty values results in the installer still prompting. Please consider providing a way to preseed an empty domain name, to completely suppress the prompt for one. Thanks, Josh Triplett
Bug#851526: Please provide command-line option to disable ipv6
On Sun, Jan 15, 2017 at 02:43:45PM -0800, Josh Triplett wrote: > Package: netcfg > Severity: wishlist > > netcfg provides an option to completely disable all automatic > configuration, but no option to disable ipv6 autoconfig (SLAAC) while > leaving DHCP enabled. Putting ipv6.disable=1 on the kernel command line > will cause netcfg to realize the network has no ipv6, but only after > waiting a similar timeout for a link-local address, defeating the > purpose. > > Please either detect disabled ipv6 and skip those steps, or provide a > command-line option to disable ipv6 in netcfg. > > (Context: repeatedly testing preseed installs in a virtual machine, and > I don't want to keep waiting on ipv6 autoconfig timing out.) > From what I've read, ipv6.disable=1 hasn't been sufficient for quite some time, and one requires something like the following in /etc/sysctl.d/: 00-disable-ipv6.conf: net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 Cheers, Nicholas signature.asc Description: Digital signature
Bug#385628: debian-installer: Should incite the user to use different password for root and for the initial user
Package: user-setup Followup-For: Bug #385628 I'd rather not annoy users with such a prompt. On a single-user system, especially one using sudo for root access, using the same password for both a user and root seems perfectly fine. Only a multi-user system where multiple people have root needs to worry about this. - Josh Triplett -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#851526: Please provide command-line option to disable ipv6
Package: netcfg Severity: wishlist netcfg provides an option to completely disable all automatic configuration, but no option to disable ipv6 autoconfig (SLAAC) while leaving DHCP enabled. Putting ipv6.disable=1 on the kernel command line will cause netcfg to realize the network has no ipv6, but only after waiting a similar timeout for a link-local address, defeating the purpose. Please either detect disabled ipv6 and skip those steps, or provide a command-line option to disable ipv6 in netcfg. (Context: repeatedly testing preseed installs in a virtual machine, and I don't want to keep waiting on ipv6 autoconfig timing out.)
Bug#851514: Installer using virtio disk or CD-ROM fails to find itself
Package: installation-reports Severity: normal An installation on a virtual machine booting the installer from a virtio disk or CDROM drive results in a "Detect and mount CD-ROM" failure ("No common CD-ROM drive was detected.") after the language prompts. To reproduce this, try the following: qemu-img create debian.img 10G kvm -m 1G -drive file=debian-stretch-DI-rc1-amd64-netinst.iso,media=cdrom,if=virtio,format=raw -drive file=debian.img,if=virtio,format=raw
Re: [Openchrome-users] How to say No!! in a polite though ridiculous way
On Fri, Jan 13, 2017 at 11:47:40PM +0100, Kevin Brace wrote: > Hi Andreas, > > Throw this in your xorg.conf > > > Section "Module" > Load"vgahw" > EndSection > > > Other than that, your xorg.conf can be empty. > I hope it works. Thanks. Works for me. Debian Stretch. Before that I had to remove openchrome.so. I put that content as /usr/share/X11/xorg.conf.d/30-openchrome.conf and now it works fine. For the record, the hardware in question: 00:01.0 VGA compatible controller: VIA Technologies, Inc. VX855/VX875 Chrome 9 HCM Integrated Graphics (prog-if 00 [VGA controller]) Subsystem: VIA Technologies, Inc. VX855/VX875 Chrome 9 HCM Integrated Graphics Flags: bus master, fast devsel, latency 32, IRQ 11 Memory at d800 (32-bit, prefetchable) [size=64M] Memory at de00 (32-bit, non-prefetchable) [size=16M] [virtual] Expansion ROM at 000c [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Debian packaging: I would appreciate it if the Debian package could include such a file (if it is harmless) or at least as an example. Or find a way to avoid the extra configuration. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
Am Sonntag, den 15.01.2017, 12:39 +0100 schrieb Karsten Merker: > On Sun, Jan 15, 2017 at 12:02:56PM +0100, permondes - sagen wrote: > > Am Sonntag, den 15.01.2017, 11:47 +0100 schrieb Karsten Merker: > > > > This points at a problem with either your u-boot version or your > > > u-boot environment. The oldest u-boot version that Debian has > > > ever shipped for the Olinuxino A20 LIME as part of the official > > > Debian-Installer images has been mainline u-boot v2014.10, and > > > all mainline u-boot versions since v2014.10 provide a default > > > environment that is compatible with this boot script. > > > > > > Please note that u-boot keeps its old environment on upgrade by > > > default, i.e. if you originally had e.g. some vendor-specific > > > u-boot installed and upgraded to mainline u-boot later, this > > > would have kept the environment from the vendor u-boot. You can > > > reset the u-boot environment to its current default by running > > > "env default -a; saveenv" at the u-boot command prompt. > > > > > > HTH, > > > Karsten > > > > The device is being used as a FreedomBox, a flavour of Debian. They > > provide an initial "live" image which is quite old actually. Updating to > > the current version, which is done automatically during set-up, makes > > this change of boot.scr, so I guess they switched to standard u-boot. > > Not necessarily. The boot.scr is generated by the flash-kernel > package on every kernel update, but the u-boot in the boot area is > not automatically updated with an update of the u-boot-sunxi > package, so unless the people who have built the freedombox upgrade > mechanism have explicitly implemented a function to update the > u-boot in the boot area (which I doubt), you will probably still > have whatever older u-boot version was used when building the > original freedombox image. > > > I would like to test the reset of the environment, how do I get into > > u-boot prompt? I just have ssh access to the box, no serial, nor > > keyboard or so. > > Hm, that poses a problem. The "normal" way is via serial console, > or, if the u-boot version is relatively new, via a display > connected to the HDMI port and a USB keyboard. U-Boot isn't memory > resident (except for the PSCI functions), i.e. once the Linux > kernel is booted, there is no u-boot anymore with which one could > interact directly. > > What you could try is clobbering the area on the SD card in which > u-boot stores the environment. This results in a checksum mismatch > and u-boot falls back to the integrated default environment. On > the LIME, the u-boot environment is stored on the SD card starting > at offset 544kB from the start of the device, and is 128kB in size. > So on the LIME running > > $ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0 > > should overwrite the complete environment area with zeros, > resulting in u-boot falling back to the built-in defaults. But > without some form of console you still won't be able to see which > version of u-boot is really installed (cf. my mail to debian-arm) > and what exactly happens at boot time. If you want to make sure > that you have a current u-boot version installed, you can replace > whatever version is currently on the SD card by running > > $ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin > of=/dev/mmcblk0 bs=1k seek=8 > > Doing all this "blind" without console is of course inherently > dangerous, so make an image backup of your SD card that you can > restore in case of problems before trying any of this. > > HTH, > Karsten Hi Karsten, this what I did: to get a fresh boot.scr I used a command I got from the freedombox list some time ago: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Then I zeroed the environment and copied the correct u-boot. The devices booted, but I realized that boot.scr did not have the correct content, so I copied the before mentioned boot script for Allwinner SunXi-based devices over it and restarted the device. This time, it did not boot afterwards. Copying back the previous boot.scr made it boot again. The environment variables were the same as before. So I am back where I have been before. My understanding is, that this strange behavior is due to a transition that happened in the Freedombox project. So I will ask them to provide updated live images to start with a fresh and correct system instead of wasting time and trying to solve this particular case. Thanks for your support anyway Dietmar
Bug#820911: installation-report: Accessibility for visual impaired is broken,, High-Contrast Theme is no longer activated by shortcut
Hello Alex, Alex ARNAUD, on Thu 01 Dec 2016 14:56:08 +0100, wrote: > - Change the Debian installation guide to help visual-impaired to > activate the ncurse or graphical high-contrast theme. > I'm not able to write it myself because the contrast of the first screen > makes it completely unreadable for me. Some text was added to the installation guide about the boot menu: « If you wish or need to add any boot parameters for either the installer or the kernel, press Tab (BIOS boot), or 'e' then down arrow three times then 'end' (UEFI boot). This will bring the boot command for the selected menu entry and allow you to edit it to suit your needs. The help screens (see below) list some common possible options. Press 'Enter' (BIOS boot) or 'F10' (UEFI boot) to boot the installer with your options; pressing Esc will return you to the boot menu and undo any changes you made. » Is this enough for your needs? Samuel
Bug#851486: debian-installer: USB keyboard doesn't work on Banana Pi
Package: debian-installer Version: 20170112 Severity: normal Tags: d-i Dear Maintainer, My Banana Pi's SD card got corrupted so I'm trying to re-install the system. Following the instructions on https://wiki.debian.org/InstallingDebianOn/Allwinner I downloaded the bits from http://ftp.uk.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/ and the resulting SD card boots fine. After applying the console changes to output to HDMI, I can even see the installer — but the USB keyboard doesn't work... It works in u-boot so the hardware would appear to be OK. Regards, Stephen -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/8 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)
Re: Debian Installer Stretch RC 1 release
Congratulations on the d-i team for the RC1 release. I recently sent a succesful install report bug, and I am really happy with the work you are doing. I know how difficult and ungrateful this work can be, so I really appreciate all the work your doing. Keep it up! A. -- The survival of humans and other species on planet Earth in my view can only be guaranteed via a timely transition towards a stationary state, a world economy without growth. - Peter Custers
Bug#851429: installation-reports: mounting CD fails on qemu-system-aarch64
On Sun, Jan 15, 2017 at 01:12:53AM +, Steve McIntyre wrote: > On Sat, Jan 14, 2017 at 10:34:18PM +0100, Adam Borowski wrote: > >I'm afraid that regular arm64 d-i images fail to detect qemu's CD-ROM, and > >there's apparently no way to direct it to load udebs from a network mirror > >like mini.iso does. On the other hand, installation with mini.iso works > >well. > > > >The failing step is "Detecting hardware to find CD-ROM drives". > > > >CD=debian-stretch-DI-rc1-arm64-netinst.iso > >NET="-net bridge -net nic" > > > >qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \ > > -bios /usr/share/qemu-efi/QEMU_EFI.fd -m 2048 $NET \ > > -drive file="$DISK",cache=writeback,index=0,media=disk,format=raw \ > > -drive file="$CD",cache=writeback,index=1,media=cdrom -boot d > > I think the problem is with your setup. I've just booted that exact > netinst image happily using > > qemu-system-aarch64 -m 4G -cpu cortex-a57 -M virt -smp 8 -nographic > -pflash AAVMF_CODE.fd -pflash AAVMF_VARS.fd -drive > file=/scratch/iso/debian-stretch-DI-rc1-arm64-netinst.iso,id=cdrom,if=none,media=cdrom > -device virtio-scsi-device -device scsi-cd,drive=cdrom -k en-gb > -netdev user,id=eth0 -device virtio-net-device,netdev=eth0 Ie, virtio vs emulating a real piece of hardware. The problem here, though, is that qemu picked a piece of hardware that's old crap that's not expected in any physical arm64 gardware. I guess it'd be good to ask them to upgrade, like they did with the Cirrus card on x86. Ordinarily I'd want you to support this "hardware" as QEMU is a major platform (at least the one most available), but in this case, with the extensive incantations required to get it running, requiring virtio might be acceptable. I refuse to say "arguments" rather than "incantations" as the former is for specifying what the program should do and what you want altered from reasonable defaults, rather than a massive ritual that needs to be performed just to get basic functionality, with every piece involving lengthy research and breakage/data loss if you skip it. Like, my line lacks a flash for storing EFI vars, meaning that it will install correctly (with mini.iso), work when rebooted, even upon multiple reboots, then fail to work anymore once you shut down qemu and start it again. So I wonder what's the best way to proceed. Probably documenting what's needed might be a good step. > and it's running the installer right now with udebs from the netinst > iso. What version of qemu-efi are you using for > /usr/share/qemu-efi/QEMU_EFI.fd? 0~20161202.7bbe0b3e-1 (current unstable and stretch). -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11
Re: Debian Installer Stretch RC 1 release
On 15.01.2017 05:21, Cyril Brulebois wrote: > The Debian Installer team[1] is pleased to announce the first release > candidate of the installer for Debian 9 "Stretch". > > > Important changes in this release of the installer > == > > * [...] > * As noted in the Stretch Alpha 6 release announcement, Debian Pure >Blends appeared in the Software selection screen. Unfortunately, >concerns voiced back then weren't worked on until after the freeze >started, and a freeze isn't the time where critical screens should >be revamped. Support was disabled accordingly. Since this is still an open discussion in #846002, I would have preferred if you would not try to force your own preference here before the CTTE made its decision. IMO your solution is not in any way cooperative and tries to make the CTTE decision useless. I therefore would ask the CTTE to make a final decision about the inclusion of the blends selection in the Stretch installer. In principle these are *two* decisions: 1. Appearance of the blends in the installer: Please decide, whether * the blends shall be shown in their current (alpha-8) form * The installer is extended to show the desktop and the blends only optionally (as propagated by Phil, and opposed by Cyril) * the blends should not appear in the Stretch installer at all. 2. Maintenance of the blends tasks appearing in the installer: * in a separate package maintained by the blends team * integrated into tasksel and maintained by d-i * be removed completely from the installation process Best regards Ole
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
On Sun, Jan 15, 2017 at 12:02:56PM +0100, permondes - sagen wrote: > Am Sonntag, den 15.01.2017, 11:47 +0100 schrieb Karsten Merker: > > This points at a problem with either your u-boot version or your > > u-boot environment. The oldest u-boot version that Debian has > > ever shipped for the Olinuxino A20 LIME as part of the official > > Debian-Installer images has been mainline u-boot v2014.10, and > > all mainline u-boot versions since v2014.10 provide a default > > environment that is compatible with this boot script. > > > > Please note that u-boot keeps its old environment on upgrade by > > default, i.e. if you originally had e.g. some vendor-specific > > u-boot installed and upgraded to mainline u-boot later, this > > would have kept the environment from the vendor u-boot. You can > > reset the u-boot environment to its current default by running > > "env default -a; saveenv" at the u-boot command prompt. > > > > HTH, > > Karsten > > The device is being used as a FreedomBox, a flavour of Debian. They > provide an initial "live" image which is quite old actually. Updating to > the current version, which is done automatically during set-up, makes > this change of boot.scr, so I guess they switched to standard u-boot. Not necessarily. The boot.scr is generated by the flash-kernel package on every kernel update, but the u-boot in the boot area is not automatically updated with an update of the u-boot-sunxi package, so unless the people who have built the freedombox upgrade mechanism have explicitly implemented a function to update the u-boot in the boot area (which I doubt), you will probably still have whatever older u-boot version was used when building the original freedombox image. > I would like to test the reset of the environment, how do I get into > u-boot prompt? I just have ssh access to the box, no serial, nor > keyboard or so. Hm, that poses a problem. The "normal" way is via serial console, or, if the u-boot version is relatively new, via a display connected to the HDMI port and a USB keyboard. U-Boot isn't memory resident (except for the PSCI functions), i.e. once the Linux kernel is booted, there is no u-boot anymore with which one could interact directly. What you could try is clobbering the area on the SD card in which u-boot stores the environment. This results in a checksum mismatch and u-boot falls back to the integrated default environment. On the LIME, the u-boot environment is stored on the SD card starting at offset 544kB from the start of the device, and is 128kB in size. So on the LIME running $ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0 should overwrite the complete environment area with zeros, resulting in u-boot falling back to the built-in defaults. But without some form of console you still won't be able to see which version of u-boot is really installed (cf. my mail to debian-arm) and what exactly happens at boot time. If you want to make sure that you have a current u-boot version installed, you can replace whatever version is currently on the SD card by running $ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1k seek=8 Doing all this "blind" without console is of course inherently dangerous, so make an image backup of your SD card that you can restore in case of problems before trying any of this. HTH, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
Am Sonntag, den 15.01.2017, 11:47 +0100 schrieb Karsten Merker: > On Sun, Jan 15, 2017 at 10:45:29AM +0100, permondes - sagen wrote: > > > Package: flash-kernel > > Version: 3.73 > > Severity: important > > > > Dear Maintainer, > > > > I am using an OLinuXino A20 LIME with arm. > > boot.scr used to have the following content (I removed the initial > > non-readable characters) which let boot the device without issues: > > > > setenv mmcpart 1 > > > > setenv mmcroot /dev/mmcblk0p2 ro > > setenv mmcrootfstype btrfs rootwait fixrtc > > setenv mmcrootflags subvol=@ > > > > setenv console ttyS0,115200n8 > > > > setenv kernel_file vmlinuz-4.8.0-2-armmp-lpae > > setenv initrd_file initrd.img-4.8.0-2-armmp-lpae > > setenv fdtfile sun7i-a20-olinuxino-lime.dtb > > > > setenv loadaddr 0x4600 > > setenv initrd_addr 0x4800 > > setenv fdtaddr 0x4700 > > > > setenv initrd_high 0x > > setenv fdt_high 0x > > > > setenv loadkernel load mmc ${mmcdev}:${mmcpart} ${loadaddr} > > ${kernel_file} > > setenv loadinitrd load mmc ${mmcdev}:${mmcpart} ${initrd_addr} > > ${initrd_file}\; setenv initrd_size \${filesize} > > setenv loadfdt load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile} > > > > setenv loadfiles run loadkernel\; run loadinitrd\; run loadfdt > > setenv mmcargs setenv bootargs console=${console} root=${mmcroot} > > rootfstype=${mmcrootfstype} rootflags=${mmcrootflags} > > > > run loadfiles; run mmcargs; bootz ${loadaddr} ${initrd_addr}: > > ${initrd_size} ${fdtaddr} > > > > <-- end of file > > To my knowledge Debian has never provided a boot script with this > content as a part of its official flash-kernel releases. Is this > perhaps from some non-official Debian image that somebody else > has produced, e.g. from some image provided by the hardware > manufacturer or from some other project that uses Debian as its > base but doesn't use Debian's normal mechanisms for handling the > boot scripts? > > Which u-boot version do you have installed? Can you provide the > output of the "printenv" command at the u-boot prompt? > > > The new content of that file is: > > > > # boot script for Allwinner SunXi-based devices > > > > # Mainline u-boot v2014.10 introduces a new default environment and > > # a new common bootcmd handling for all platforms, which is not fully > > # compatible with the old-style environment used by u-boot-sunxi. > > # This script therefore needs to check in which environment it > > # is running and set some variables accordingly. > > > > # On u-boot-sunxi, this script assumes that ${device} and ${partition} > > # are set. > > > > # The new-style environment predefines ${boot_targets}, the old-style > > # environment does not. > > if test -n "${boot_targets}" > > then > > echo "Mainline u-boot / new-style environment detected." > > # Mainline u-boot v2014.10 uses ${devtype}, ${devnum} and > > # ${bootpart} where u-boot-sunxi uses ${device} and ${partition}. > > # ${distro_bootpart} replaced ${bootpart} in u-boot v2016.01. > > if test -z "${device}"; then setenv device "${devtype}"; fi > > if test -z "${partition}${distro_bootpart}"; then setenv partition > > "${devnum}:${bootpart}"; fi > > if test -z "${partition}"; then setenv partition "${devnum}: > > ${distro_bootpart}"; fi > > else > > echo "U-boot-sunxi / old-style environment detected." > > # U-boot-sunxi does not predefine kernel_addr_r, fdt_addr_r and > > # ramdisk_addr_r, so they have to be manually set. Use the values > > # from mainline u-boot v2014.10, except for ramdisk_addr_r, > > # which is set to 0x4430 to allow for initrds larger than > > # 13MB on u-boot-sunxi. > > setenv kernel_addr_r 0x4200 > > setenv fdt_addr_r 0x4300 > > setenv ramdisk_addr_r 0x4430 > > fi > > > > if test -n "${console}"; then > > setenv bootargs "${bootargs} console=${console}" > > fi > > > > setenv bootargs ${bootargs} quiet > > > > > > image_locations='/boot/ /' > > if test -z "${fk_kvers}"; then > >setenv fk_kvers '4.8.0-2-armmp-lpae' > > fi > > > > if test -n "${fdtfile}"; then > >setenv fdtpath dtbs/${fk_kvers}/${fdtfile} > > else > >setenv fdtpath dtb-${fk_kvers} > > fi > > > > for pathprefix in ${image_locations} > > do > > if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers} > > then > > load ${device} ${partition} ${kernel_addr_r} > > ${pathprefix}vmlinuz-${fk_kvers} \ > > && load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath} > > \ > > && load ${device} ${partition} ${ramdisk_addr_r} > > ${pathprefix}initrd.img-${fk_kvers} \ > > && echo "Booting Debian ${fk_kvers} from ${device} ${partition}..." > > \ > > && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} > > ${fdt_addr_r} > > fi > > done > > > > <- end of file > > > > Which does not allow the device to boot. > > None of the variables in that script is set in the current environment. > > This points at a problem with
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
On Sun, Jan 15, 2017 at 10:45:29AM +0100, permondes - sagen wrote: > Package: flash-kernel > Version: 3.73 > Severity: important > > Dear Maintainer, > > I am using an OLinuXino A20 LIME with arm. > boot.scr used to have the following content (I removed the initial > non-readable characters) which let boot the device without issues: > > setenv mmcpart 1 > > setenv mmcroot /dev/mmcblk0p2 ro > setenv mmcrootfstype btrfs rootwait fixrtc > setenv mmcrootflags subvol=@ > > setenv console ttyS0,115200n8 > > setenv kernel_file vmlinuz-4.8.0-2-armmp-lpae > setenv initrd_file initrd.img-4.8.0-2-armmp-lpae > setenv fdtfile sun7i-a20-olinuxino-lime.dtb > > setenv loadaddr 0x4600 > setenv initrd_addr 0x4800 > setenv fdtaddr 0x4700 > > setenv initrd_high 0x > setenv fdt_high 0x > > setenv loadkernel load mmc ${mmcdev}:${mmcpart} ${loadaddr} > ${kernel_file} > setenv loadinitrd load mmc ${mmcdev}:${mmcpart} ${initrd_addr} > ${initrd_file}\; setenv initrd_size \${filesize} > setenv loadfdt load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile} > > setenv loadfiles run loadkernel\; run loadinitrd\; run loadfdt > setenv mmcargs setenv bootargs console=${console} root=${mmcroot} > rootfstype=${mmcrootfstype} rootflags=${mmcrootflags} > > run loadfiles; run mmcargs; bootz ${loadaddr} ${initrd_addr}: > ${initrd_size} ${fdtaddr} > > <-- end of file To my knowledge Debian has never provided a boot script with this content as a part of its official flash-kernel releases. Is this perhaps from some non-official Debian image that somebody else has produced, e.g. from some image provided by the hardware manufacturer or from some other project that uses Debian as its base but doesn't use Debian's normal mechanisms for handling the boot scripts? Which u-boot version do you have installed? Can you provide the output of the "printenv" command at the u-boot prompt? > The new content of that file is: > > # boot script for Allwinner SunXi-based devices > > # Mainline u-boot v2014.10 introduces a new default environment and > # a new common bootcmd handling for all platforms, which is not fully > # compatible with the old-style environment used by u-boot-sunxi. > # This script therefore needs to check in which environment it > # is running and set some variables accordingly. > > # On u-boot-sunxi, this script assumes that ${device} and ${partition} > # are set. > > # The new-style environment predefines ${boot_targets}, the old-style > # environment does not. > if test -n "${boot_targets}" > then > echo "Mainline u-boot / new-style environment detected." > # Mainline u-boot v2014.10 uses ${devtype}, ${devnum} and > # ${bootpart} where u-boot-sunxi uses ${device} and ${partition}. > # ${distro_bootpart} replaced ${bootpart} in u-boot v2016.01. > if test -z "${device}"; then setenv device "${devtype}"; fi > if test -z "${partition}${distro_bootpart}"; then setenv partition > "${devnum}:${bootpart}"; fi > if test -z "${partition}"; then setenv partition "${devnum}: > ${distro_bootpart}"; fi > else > echo "U-boot-sunxi / old-style environment detected." > # U-boot-sunxi does not predefine kernel_addr_r, fdt_addr_r and > # ramdisk_addr_r, so they have to be manually set. Use the values > # from mainline u-boot v2014.10, except for ramdisk_addr_r, > # which is set to 0x4430 to allow for initrds larger than > # 13MB on u-boot-sunxi. > setenv kernel_addr_r 0x4200 > setenv fdt_addr_r 0x4300 > setenv ramdisk_addr_r 0x4430 > fi > > if test -n "${console}"; then > setenv bootargs "${bootargs} console=${console}" > fi > > setenv bootargs ${bootargs} quiet > > > image_locations='/boot/ /' > if test -z "${fk_kvers}"; then >setenv fk_kvers '4.8.0-2-armmp-lpae' > fi > > if test -n "${fdtfile}"; then >setenv fdtpath dtbs/${fk_kvers}/${fdtfile} > else >setenv fdtpath dtb-${fk_kvers} > fi > > for pathprefix in ${image_locations} > do > if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers} > then > load ${device} ${partition} ${kernel_addr_r} > ${pathprefix}vmlinuz-${fk_kvers} \ > && load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath} > \ > && load ${device} ${partition} ${ramdisk_addr_r} > ${pathprefix}initrd.img-${fk_kvers} \ > && echo "Booting Debian ${fk_kvers} from ${device} ${partition}..." > \ > && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} > ${fdt_addr_r} > fi > done > > <- end of file > > Which does not allow the device to boot. > None of the variables in that script is set in the current environment. This points at a problem with either your u-boot version or your u-boot environment. The oldest u-boot version that Debian has ever shipped for the Olinuxino A20 LIME as part of the official Debian-Installer images has been mainline u-boot v2014.10, and all mainline u-boot versions since v2014.10 provide a default environment that is compatible with this boot script.
Re: Uploading netcfg?
Christian PERRIER, on Sun 15 Jan 2017 08:06:02 +0100, wrote: > --- a/finish-install.d/97release-dhcp-lease > +++ b/finish-install.d/97release-dhcp-lease > @@ -7,5 +7,5 @@ pid=$(pidof udhcpc) || true > > if [ "$(pidof dhclient || true)" ]; then > dhclient -r || true > - dhclient -1 -6 -r || true > + dhclient -6 -r || true > fi > > I tend to be confident in Samuel's changes, but as we are in the > release freeze, we should also be as conservative as we can wrt D-I > changes. > > Other advices? Should I build/upload or not? The change is just a clean-up. The -1 option was needed due to the previous isc-dhcp behavior which was hurting the hurd port (and not linux and kfreebsd). Now that isc-dhcp fixed its behavior the -1 option is not needed any more. It doesn't hurt either, though, so either way is fine. Samuel
Uploading netcfg?
I resumed tracking of pending changes in git for D-I packages, after the release of RC1. I'll upload kernel-wedge that has a tricial fix to a manpage. The only other pending change is the following in netcfg: bubulle@kheops:~/src/debian/debian-installer/trunk/packages/netcfg(master) $ git show 8cd816f384ac3066e5aa2652cb399cd814e98f2c commit 8cd816f384ac3066e5aa2652cb399cd814e98f2c Author: Samuel ThibaultDate: Wed Jan 11 00:45:19 2017 +0100 Revert work around for bug #769189, it is now fixed diff --git a/debian/changelog b/debian/changelog index 450214d..b67718b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +netcfg (1.141) UNRELEASED; urgency=medium + + * Revert work around for bug #769189, it is now fixed. + + -- Samuel Thibault Wed, 11 Jan 2017 00:42:38 +0100 + netcfg (1.140) unstable; urgency=medium [ Julien Cristau ] diff --git a/finish-install.d/97release-dhcp-lease b/finish-install.d/97release-dhcp-lease index 4a02076..27384d2 100755 --- a/finish-install.d/97release-dhcp-lease +++ b/finish-install.d/97release-dhcp-lease @@ -7,5 +7,5 @@ pid=$(pidof udhcpc) || true if [ "$(pidof dhclient || true)" ]; then dhclient -r || true - dhclient -1 -6 -r || true + dhclient -6 -r || true fi I tend to be confident in Samuel's changes, but as we are in the release freeze, we should also be as conservative as we can wrt D-I changes. Other advices? Should I build/upload or not? -- signature.asc Description: PGP signature
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
Package: flash-kernel Version: 3.73 Severity: important Dear Maintainer, I am using an OLinuXino A20 LIME with arm. boot.scr used to have the following content (I removed the initial non-readable characters) which let boot the device without issues: setenv mmcpart 1 setenv mmcroot /dev/mmcblk0p2 ro setenv mmcrootfstype btrfs rootwait fixrtc setenv mmcrootflags subvol=@ setenv console ttyS0,115200n8 setenv kernel_file vmlinuz-4.8.0-2-armmp-lpae setenv initrd_file initrd.img-4.8.0-2-armmp-lpae setenv fdtfile sun7i-a20-olinuxino-lime.dtb setenv loadaddr 0x4600 setenv initrd_addr 0x4800 setenv fdtaddr 0x4700 setenv initrd_high 0x setenv fdt_high 0x setenv loadkernel load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${kernel_file} setenv loadinitrd load mmc ${mmcdev}:${mmcpart} ${initrd_addr} ${initrd_file}\; setenv initrd_size \${filesize} setenv loadfdt load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile} setenv loadfiles run loadkernel\; run loadinitrd\; run loadfdt setenv mmcargs setenv bootargs console=${console} root=${mmcroot} rootfstype=${mmcrootfstype} rootflags=${mmcrootflags} run loadfiles; run mmcargs; bootz ${loadaddr} ${initrd_addr}: ${initrd_size} ${fdtaddr} <-- end of file The new content of that file is: # boot script for Allwinner SunXi-based devices # Mainline u-boot v2014.10 introduces a new default environment and # a new common bootcmd handling for all platforms, which is not fully # compatible with the old-style environment used by u-boot-sunxi. # This script therefore needs to check in which environment it # is running and set some variables accordingly. # On u-boot-sunxi, this script assumes that ${device} and ${partition} # are set. # The new-style environment predefines ${boot_targets}, the old-style # environment does not. if test -n "${boot_targets}" then echo "Mainline u-boot / new-style environment detected." # Mainline u-boot v2014.10 uses ${devtype}, ${devnum} and # ${bootpart} where u-boot-sunxi uses ${device} and ${partition}. # ${distro_bootpart} replaced ${bootpart} in u-boot v2016.01. if test -z "${device}"; then setenv device "${devtype}"; fi if test -z "${partition}${distro_bootpart}"; then setenv partition "${devnum}:${bootpart}"; fi if test -z "${partition}"; then setenv partition "${devnum}: ${distro_bootpart}"; fi else echo "U-boot-sunxi / old-style environment detected." # U-boot-sunxi does not predefine kernel_addr_r, fdt_addr_r and # ramdisk_addr_r, so they have to be manually set. Use the values # from mainline u-boot v2014.10, except for ramdisk_addr_r, # which is set to 0x4430 to allow for initrds larger than # 13MB on u-boot-sunxi. setenv kernel_addr_r 0x4200 setenv fdt_addr_r 0x4300 setenv ramdisk_addr_r 0x4430 fi if test -n "${console}"; then setenv bootargs "${bootargs} console=${console}" fi setenv bootargs ${bootargs} quiet image_locations='/boot/ /' if test -z "${fk_kvers}"; then setenv fk_kvers '4.8.0-2-armmp-lpae' fi if test -n "${fdtfile}"; then setenv fdtpath dtbs/${fk_kvers}/${fdtfile} else setenv fdtpath dtb-${fk_kvers} fi for pathprefix in ${image_locations} do if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers} then load ${device} ${partition} ${kernel_addr_r} ${pathprefix}vmlinuz-${fk_kvers} \ && load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath} \ && load ${device} ${partition} ${ramdisk_addr_r} ${pathprefix}initrd.img-${fk_kvers} \ && echo "Booting Debian ${fk_kvers} from ${device} ${partition}..." \ && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r} fi done <- end of file Which does not allow the device to boot. None of the variables in that script is set in the current environment. As work-around I am currently copying a saved version of the former file content to boot.scr. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 4.8.0-2-armmp-lpae (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages flash-kernel depends on: ii debconf [debconf-2.0] 1.5.59 ii devio 1.2-1.2 ii initramfs-tools0.126 ii linux-base 4.5 ii mtd-utils 1:2.0.0-1 ii ucf3.0036 Versions of packages flash-kernel recommends: ii u-boot-tools 2016.11+dfsg1-3 flash-kernel suggests no packages. -- debconf information: flash-kernel/linux_cmdline: quiet Dietmar
Bug#839747: marked as done (debian-installer-netboot-images: FTBFS in testing (no properly formatted SHA256 checksum lines found))
Your message dated Sun, 15 Jan 2017 10:00:24 +0100 with message-id <6099434.bgmakmr...@odyx.org> and subject line Re: Bug#839747: debian-installer-netboot-images: FTBFS in testing (no properly formatted SHA256 checksum lines found) has caused the Debian Bug report #839747, regarding debian-installer-netboot-images: FTBFS in testing (no properly formatted SHA256 checksum lines found) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 839747: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839747 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:debian-installer-netboot-images Version: 20150422+deb8u4.b1 Severity: serious Dear maintainer: I tried to build this package in stretch with "dpkg-buildpackage -A" (which is what the "Arch: all" autobuilder would do to build it) but it failed: [...] debian/rules build-indep dh build-indep dh_testdir -i dh_update_autotools_config -i dh_auto_configure -i dh_auto_build -i dh_auto_test -i fakeroot debian/rules binary-indep dh binary-indep dh_testroot -i dh_prep -i debian/rules override_dh_auto_install make[1]: Entering directory '/<>/debian-installer-netboot-images-20150422+deb8u4.b1' [... snipped ...] Connecting to httpredir.debian.org (httpredir.debian.org)|5.153.231.35|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://ftp.eq.uc.pt/software/Linux/debian/dists/jessie-proposed-updates/main/binary-amd64/Packages.gz [following] --2016-09-17 22:40:30-- http://ftp.eq.uc.pt/software/Linux/debian/dists/jessie-proposed-updates/main/binary-amd64/Packages.gz Resolving ftp.eq.uc.pt (ftp.eq.uc.pt)... 193.137.214.36 Connecting to ftp.eq.uc.pt (ftp.eq.uc.pt)|193.137.214.36|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 20 [application/x-gzip] Saving to: 'amd64.Packages.gz' 0K 100% 5.71M=0s 2016-09-17 22:40:30 (5.71 MB/s) - 'amd64.Packages.gz' saved [20/20] amd64.Packages.gz: OK --2016-09-17 22:40:30-- http://httpredir.debian.org/debian/pool/main/d/debian-installer/debian-installer_20150422+deb8u4+b1_amd64.deb Resolving httpredir.debian.org (httpredir.debian.org)... 128.31.0.66, 5.153.231.35, 2001:41c8:1000:21::21:35 Connecting to httpredir.debian.org (httpredir.debian.org)|128.31.0.66|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://ftp.eq.uc.pt/software/Linux/debian/pool/main/d/debian-installer/debian-installer_20150422+deb8u4+b1_amd64.deb [following] --2016-09-17 22:40:31-- http://ftp.eq.uc.pt/software/Linux/debian/pool/main/d/debian-installer/debian-installer_20150422+deb8u4+b1_amd64.deb Resolving ftp.eq.uc.pt (ftp.eq.uc.pt)... 193.137.214.36 Connecting to ftp.eq.uc.pt (ftp.eq.uc.pt)|193.137.214.36|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 736654 (719K) [application/x-debian-package] Saving to: 'debian-installer_20150422+deb8u4+b1_amd64.deb' 0K .. .. .. .. .. 6% 1.11M 1s 50K .. .. .. .. .. 13% 2.84M 0s 100K .. .. .. .. .. 20% 6.38M 0s 150K .. .. .. .. .. 27% 8.54M 0s 200K .. .. .. .. .. 34% 2.55M 0s 250K .. .. .. .. .. 41% 130M 0s 300K .. .. .. .. .. 48% 14.5M 0s 350K .. .. .. .. .. 55% 10.7M 0s 400K .. .. .. .. .. 62% 2.72M 0s 450K .. .. .. .. .. 69% 93.0M 0s 500K .. .. .. .. .. 76% 1.15M 0s 550K .. .. .. .. .. 83% 2.44M 0s 600K .. .. .. .. .. 90% 206M 0s 650K .. .. .. .. .. 97% 247M 0s 700K .. . 100% 233M=0.2s 2016-09-17 22:40:31 (3.83 MB/s) - 'debian-installer_20150422+deb8u4+b1_amd64.deb' saved [736654/736654] sha256sum: debian-installer_20150422+deb8u4+b1_amd64.deb.sha256sum: no properly formatted SHA256 checksum lines found debian/rules:19: recipe for target 'get-images-amd64' failed make[1]: *** [get-images-amd64] Error 1 make[1]: Leaving directory
Bug#766914: user-setup: hardware access groups should not be default
Hello, I had #849265 reported against adduser for this problem that exists in d-i's user-setup. It also exists in adduser if the --add_extra_groups flags is used (which is why I didn't reassign/merge), user-setup is adding this groups directly. See the bug log for 849265 [1], as well as my correspondence with pkg-systemd [2]. Thanks and regards Afif 1. http://bugs.debian.org/849265 2. http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2017-January/013684.html -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name