console-setup_1.158_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 18 Jan 2017 07:05:30 +0100 Source: console-setup Binary: keyboard-configuration console-setup console-setup-mini console-setup-linux console-setup-freebsd bdf2psf console-setup-udeb console-setup-amiga-ekmap console-setup-ataritt-ekmap console-setup-macintoshold-ekmap console-setup-pc-ekmap console-setup-sun4-ekmap console-setup-sun5-ekmap console-setup-pc-ekbd console-setup-linux-fonts-udeb console-setup-freebsd-fonts-udeb console-setup-linux-charmaps-udeb console-setup-freebsd-charmaps-udeb Architecture: source Version: 1.158 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: bdf2psf- font converter to generate console fonts from BDF source fonts console-setup - console font and keymap setup program console-setup-amiga-ekmap - encoded Linux keyboard layouts for Amiga keyboards (udeb) console-setup-ataritt-ekmap - encoded Linux keyboard layouts for Atari TT keyboards (udeb) console-setup-freebsd - FreeBSD specific part of console-setup console-setup-freebsd-charmaps-udeb - FreeBSD 8-bit charmaps for console-setup-udeb (udeb) console-setup-freebsd-fonts-udeb - FreeBSD console fonts for Debian Installer (udeb) console-setup-linux - Linux specific part of console-setup console-setup-linux-charmaps-udeb - Linux 8-bit charmaps for console-setup-udeb (udeb) console-setup-linux-fonts-udeb - Linux console fonts for Debian Installer (udeb) console-setup-macintoshold-ekmap - encoded Linux keyboard layouts for old-style Macintosh keyboards (udeb) console-setup-mini - console font and keymap setup program - reduced version for Linux console-setup-pc-ekbd - encoded FreeBSD keyboard layouts for PC keyboards (udeb) console-setup-pc-ekmap - encoded Linux keyboard layouts for PC keyboards (udeb) console-setup-sun4-ekmap - encoded Linux keyboard layouts for Sun4 keyboards (udeb) console-setup-sun5-ekmap - encoded Linux keyboard layouts for Sun5 keyboards (udeb) console-setup-udeb - Configure the keyboard (udeb) keyboard-configuration - system-wide keyboard preferences Changes: console-setup (1.158) unstable; urgency=medium . [ Updated translations ] * Bulgarian (bg.po) by Damyan Ivanov Checksums-Sha1: cced9d57d5d70f6f853fdb3e4bd63627f20c0c9e 3273 console-setup_1.158.dsc 4cef6122385768a79da7603423f99468fe0bc2a9 1644252 console-setup_1.158.tar.xz Checksums-Sha256: 8b924f05499323bee8d9719b0f8a53ccdf61d86899774a95679134eea0c643f4 3273 console-setup_1.158.dsc 0ebbf8ff03f2a145d6f4ca304e8712847645be30f2f6e1891206e11ae3125063 1644252 console-setup_1.158.tar.xz Files: 088477efee8695592c7ec36233e111c5 3273 utils optional console-setup_1.158.dsc 9f6fc43a82eb6b3337732e4b6d0089ba 1644252 utils optional console-setup_1.158.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJYfwbLAAoJEIcvcCxNbiWo/9UQAID6H/0Dog2CungfbuWbg61W Wu3hHTS912+9UBAfSY27I81NR8xMSiXrBsKa21yN0LjEp2KZ68BRpf4ogh7SIJDw RFmD11AzraBodRbz4TB8nvChmsO/Sx//rekvDANxx8QJg6exq7uQmiBu1T2+ItYJ LnfOzrtsXyoTmDJbOTMHVXgwExQQRPxP2w5g0a5WGyEK8mw4N6rO2DcUWeJQ76FQ 3am78VB16LtVWf4TRD4PsyU0lSn4nLVOUZfU55VJtRojjhyTWqtUCCIItTDHNX+T Gs5OQbvHeXLgBUUFHWAc9Cog/9zdg2YSWXbM6SwomnLXzIW0Cu6hJOBlyDOlRCvn +Aa/WagxVXl6Zi+y8lCYMmzIqzV4VwfJ9NUONL7+z6IonFJAuJDqyACs7QxoAh5F DdXnqcGc1txVVvQF1Dq5loOuRHgLnHPwHW+DlR23/7Xn+uBnpABXhVGPI7lbhZ+F g87EGZ3NVQUn/mUoJK213Ke1hGWyIO4NmJJVWMVtlaQdeged+ROyUqp5XSNo5afI Zuuesr7ygYQMM27vFVpuGCMqCbYPLJYF9JFcwpmc45iy7+c2/E9R4xLL9MVcGrs5 7SJAd9cn33x33eIDxpGN/JsyY4MXQ2vDD8iuJ7V6OAOoqM1FjCAYlEOl7uypc7lH 52wDniTBfoPuMabeLvVw =AzN/ -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of console-setup_1.158_source.changes
console-setup_1.158_source.changes uploaded successfully to localhost along with the files: console-setup_1.158.dsc console-setup_1.158.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot
Ah...the logic is in debian/rescue-mode.postinst; I had assumed it would be elsewhere. I'll take some time to study this thoroughly, and to do a VM install and rescue to see how the LVM case works. If you know if it's closer to (1) or (2) in my last email. Is Feb 5th (Full freeze) the final deadline for this work? Deadline being, it needs to have been submitted to ftp-masters before then. Cheers, Nicholas signature.asc Description: Digital signature
Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot
Hi Philipp, Thank you for the clarification, and sorry for my tardy reply. On Wed, Jan 04, 2017 at 12:04:09AM +0100, Philipp Kern wrote: > On 12/19/2016 05:49 AM, Nicholas D Steeves wrote: > > Which rescue mode, and where? Please tell me so I can fix it! From > > what I've read, setting a default subvolid != 5 was explored by other > > distributions, and abandoned. > > rescue-mode is in [0]. That presents you with a menu where you can > select local root filesystems. That should somehow DTRT instead of > mounting the top-level btrfs filesystem with the root filesystem being > below. I suppose it'd be also ok to mount it as-is, as long as the shell > is spawned in the right place. (Although that might be surprising.) > > The mode is triggered by passing "rescue/enable=true" on the kernel > command-line. d-i ships with boot menu items that do this. > > Kind regards > Philipp Kern > > [0] https://anonscm.debian.org/cgit/d-i/rescue.git/tree/ > Oh, there! I had already checked that out in debian-installer/packages/rescue. :-) From what I gather, DTRT looks something like one of the following: 1. Use existing choose partition menu * select partition menu * test if selected partition is a btrfs volume - if there are no subvolumes, use present behaviour * if subvolumes exist - install btrfs-progs udeb - use btrfs subvol list to read subvols - present a menu How is this currently handled for LVM? There is very little code in "rescue" itself, and I haven't yet managed to figure out how everything fits together. 2. Alternatively, duplicate the existing LVM code, then modify it for btrfs. If you could point me to whatever 'rescue' ties into for LVM support I would be very grateful! From what I've gathered so far, "rescue" dependency on the btrfs application is provided by the btrfs-progs udeb and not through initramfs Cheers, Nicholas signature.asc Description: Digital signature
Bug#851715: partman-base: "Partition disks" list should show LVM volume groups
Package: partman-base Version: 189 Severity: normal Hello, The typical scenario is this: a new computer with pre-installed windows which we do want to keep as such (and thus guided partitioning using the whole disk is a no-go), and install Debian in an LVM or encrypted LVM. The way I would do it is: first go to the manual menu, set up an LVM volume group, or setup up an encrypted volume and set up an LVM volume group, and then select guided partitioning to let d-i partition the available volume. This is how it works with RAID, for instance. But while in the RAID case, the md volume shows up in the list of disks, in the LVM case the volume group does not show up. More precisely, for instance: create example disk with existing partition: - dd < /dev/zero > disk bs=1M count=1 seek=1 - /sbin/fdisk disk n p 2048 +1G t c then boot the installer and at partitioning step: - Manual - Configure the Logical Volume Manager - Create volume group with the free space on the disk (do *not* create logical volumes since the idea is that it's guided partitioning which does it). - Finish - Guided partitioning - Guided - use entire disk - the presented list only shows SCSI1, while it should also list the LVM volume group The LVM+crypt scenario is a matter of inserting this between "Manual" and "Configure the Logical Volume Manager": - Configure encrypted volumes - Create encrypted volumes - Use the free space on the disk - Finish and using the encrypted volume. For an instance of the RAID case where things do work as expected, with two physical disks: - Manual - Create empty partition tables on both disks - Configure software RAID - Create MD device - RAID1 - 2 active devices - 0 space device - select both disks - Finish - Guided partitioning - Guided - use entire disk - There we can select RAID1 Samuel -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Samuel Accroche-toi au terminal, j'enlève le shell... -+- nojhan -+-
Bug#851469: marked as done (flash-kernel: ARM new boot.scr does not allow the device to boot)
Your message dated Tue, 17 Jan 2017 21:59:29 +0100
with message-id <20170117205929.gc1...@excalibur.cnev.de>
and subject line Re: Bug#851469: flash-kernel: ARM new boot.scr does not allow
the device to boot
has caused the Debian Bug report #851469,
regarding flash-kernel: ARM new boot.scr does not allow the device to boot
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.)
--
851469: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851469
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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)
Loca
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
Am Montag, den 16.01.2017, 21:41 +0100 schrieb Karsten Merker: > On Mon, Jan 16, 2017 at 08:07:50PM +0100, permondes - sagen wrote: > > Am Montag, den 16.01.2017, 00:14 +0100 schrieb Karsten Merker: > > > > Could you (after making an image backup of your SD card so that > > > you can easily restore the previous setup) please try the > > > following procedure on the LIME: > > > > > > $ sudo apt-get install u-boot-sunxi > > > $ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin > > > of=/dev/mmcblk0 bs=1k seek=8 > > > $ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0 > > > $ sudo flash-kernel > > > $ sync > > > $ sudo reboot > > > > > > This should (at least in theory) provide you with a booting > > > system, unless there is some freedombox-specific mechanism > > > that modifies the boot.scr behind flash-kernel's back. > > > > > > Regards, > > > Karsten > > > > Hi Karsten, > > I followed your instructions to the letter: > > > > > $ sudo apt-get install u-boot-sunxi > > > u-boot-sunxi ist schon die neueste Version (2016.11+dfsg1-3). > > > 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht > > > aktualisiert. > > > > > > $ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin > > > of=/dev/mmcblk0 bs=1k seek=8 > > > 471+1 Datensätze ein > > > 471+1 Datensätze aus > > > 482846 Bytes (483 kB, 472 KiB) kopiert, 0,0468861 s, 10,3 MB/s > > > > > > $ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0 > > > 128+0 Datensätze ein > > > 128+0 Datensätze aus > > > 131072 Bytes (131 kB, 128 KiB) kopiert, 0,0190237 s, 6,9 MB/s > > > > > > $ sudo flash-kernel > > > DTB: sun7i-a20-olinuxino-lime.dtb > > > Installing > > > /usr/lib/linux-image-4.8.0-2-armmp-lpae/sun7i-a20-olinuxino-lime.dtb into > > > /boot/dtbs/4.8.0-2-armmp-lpae/sun7i-a20-olinuxino-lime.dtb > > > Taking backup of sun7i-a20-olinuxino-lime.dtb. > > > Installing new sun7i-a20-olinuxino-lime.dtb. > > > flash-kernel: installing version 4.8.0-2-armmp-lpae > > > Generating boot script u-boot image... done. > > > Taking backup of boot.scr. > > > Installing new boot.scr. > > > > > > $ sync > > > > > > $ sudo reboot > > > Connection to ... closed by remote host. > > > Connection to ... closed. > > > > As I could not ssh into it even after 5 minutes (usually it > > booted in 1-2 mins.), I tried with > > > > > nmap -p 80 --open -sV /24 > > > > but the device was not shown. Also the router web interface did > > not show it. > > That is indeed strange. I am sorry to have to say that we > probably won't be able to debug this any further without access > to the boot console. Flash-kernel and the boot script created by > it work without problems on my A20-based systems which were > installed with debian-installer, so it appears that the issue is > probably something specific to the freedombox setup. It might > have something to do with the way the SD card is partitioned or > with the use of btrfs as the root filesystem and the additional > kernel parameters that the freedombox-bootscript provides, but > without a boot log the exact issue is very difficult to > determine. > > > We can give up any time. I have a work around for the moment > > and can ask the Freedombox people to generate a new image with > > the current u-boot environment. > > Shall we keep the bug against flash-kernel open or shall we close > it? If the former, I would tag it "moreinfo" as we effectively > cannot solve the issue without further information about what > exactly happens during the boot process on your system. > > Regards, > Karsten Please close the bug. I will try to get a fw_env.config or set up a new system. The issue is probably Freedombox related and working on it does not advance this project. Thanks a lot for your support. Dietmar
s390-netdevice_0.0.51_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 17 Jan 2017 08:11:26 +0100 Source: s390-netdevice Binary: s390-netdevice Architecture: source Version: 0.0.51 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: s390-netdevice - Configure network hardware (udeb) Changes: s390-netdevice (0.0.51) unstable; urgency=medium . [ Updated translations ] * Bulgarian (bg.po) by Damyan Ivanov Checksums-Sha1: 521a999d9f17d97dc75f2f5d0ca11ed6d1cfed21 1787 s390-netdevice_0.0.51.dsc e51082587a568abb83bc43b79359a93dec05b72e 95388 s390-netdevice_0.0.51.tar.xz Checksums-Sha256: 54b07b9a05e7e3994f1bdd023e64fc9e8bc0a99c5593a42439920c386802753e 1787 s390-netdevice_0.0.51.dsc 06609619dce251e4b4ae7ca39e2e17ef78595cc2fd16f4e37bc5e9503f1e034c 95388 s390-netdevice_0.0.51.tar.xz Files: 816e8f4e643965c2c6282386af69ea36 1787 debian-installer standard s390-netdevice_0.0.51.dsc 170f38176a0e6fbf437c35a9c273075d 95388 debian-installer standard s390-netdevice_0.0.51.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJYflpSAAoJEIcvcCxNbiWom0QP/iyHIZBATf+/upBSP9Msimw1 PI+DXVTfCb9cIJ8zrlygHzVlCi3Ip/9eDzJ5bmJnqRaNMPKNRfp6D+CDBjMkF5v2 SHZ5qQd0h8xtl1tvtF3hzSDwwDSlwFeWOKL+MxCm5vz1fZyt6nV75SI+QZ1D7/Gi 0ah3jn4k5YvuWrSLgrKrYckezXQaNiv8ld9uKHnH8S6N2M0zbysxHFH1BNunFzGA KNdYbfS+qO25Mc6nVEZTHy7QUhvkkCQ1YuB9gwZ72yz6UOZYPlCliAi2fkwMyR4w dRSQy9SYV761MdOdSDAiYGbaJteohTFAj8Ck4Iz1VgR8ZT5eA+A+0mskHIiopJl6 2J5xo4C6eyHrxnHaDvlyeGfsls+brpFRSoj1y2KcMEqSeqrF5y73c6uCQlXpKYEb ZmZLDYisI3QtPzZgtl+kipiUDLhsnGAqBit6D8EibUl+BAW8ihaFMtSs5Abj6D20 SDAlCz+Rg+Fp3P3+VmZ/DUAB6HDqzXtRvl9OyrMq+eLMMU6F98iMdxnCJVkWyfOT YhXd2xqrKcXt8Q59T8F8CDViu2TbEj+R9dQtxplppIQDcfPdvP+uxPltDW/k7dbr dCXFnPoR6PQ61aWG/0W5fpfFYF/1puoZ7eRDdsGfwA0K5eD/YFG/dx79tLFUsvZa Ajyp2gH6xAZuvgugRuJF =HRId -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of s390-netdevice_0.0.51_source.changes
s390-netdevice_0.0.51_source.changes uploaded successfully to localhost along with the files: s390-netdevice_0.0.51.dsc s390-netdevice_0.0.51.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Fattura TIM linea Fissa - Gennaio 2017 - scadenza 12/01/2017
<<< text/html: Unrecognized >>>
Re: stretch hd-media - boot error for USB-FDD on S5000PAL
On Mon, 16 Jan 2017 09:39:25 -0500 lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote: > On Mon, Jan 16, 2017 at 11:56:41AM +0300, dbsubscr...@mail.ru wrote: > > I use the server on S5000PAL. For remote reinstallation of system > > to me it is necessary to choose in BIOS for USB disks the Force FDD > > mode. It will allow to consider USB the separate device and allows > > to choose him at single loadings on this version of BIOS. > > > > I use a loading image > > stretch/main/installer-amd64/current/images/hd-media/boot.img.gz. > > > > The image is copied on usb a disk through dd. The section 1Gb turns > > out. > > > > When loading with USB the message of "Boot error" is given at once > > > > I have tried to zapusat releases of boot.img.gz for the previous > > dates and only the release from 20160106 was loaded without > > problems. > > > > The image of hd-media of the jessie distribution kit is loaded > > without problems. > > In floppy mode? > > > BIOS servers it is updated to the latest version. > > > > Use of USB on this server works in the HDD mode, but demands > > indications of an order of loading in the list of HDD devices. And > > to use USB for single loading it is impossible. > > The hdmedia has a partition table and expects to be booted as a > harddisk. Making it a floppy can't possibly be expected to work since > floppy booting is totally different than hard disk booting. > > That is not a way to solve boot problems. > > -- > Len Sorensen No. The image boot.img.gz has the table of partitions not as at the hard drive. Partition mount without number (mount /dev/sdc /mnt/usb-boot) S5000PAL BIOS, USB Storage Emulation: [Auto] - USB devices less than 530MB will be emulated as floppy. [Forced FDD] - HDD formatted drive will be emulated as FDD (e.g. ZIP drive). I use "Forced FDD" and USB selected in BIOS Boot Manager https://www.debian.org/releases/stretch/amd64/apas02.html.en "Some BIOSes can boot USB storage directly, and some cannot. You may need to configure your BIOS to boot from a “removable drive” or even a “USB-ZIP” to get it to boot from the USB device. For helpful hints and details, see Section 5.1.5, “Booting from USB Memory Stick”. " zcat boot.img.gz > /dev/sdc Jessie boot correctly. Stretch boot correctly with boot.img.gz version 20160106 http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/20160106/images/hd-media/boot.img.gz Version from 20170112 print message "Boot error" http://http.us.debian.org/debian/dists/stretch/main/installer-amd64/current/images/hd-media/boot.img.gz Maybe BUG? -- dbsubscr...@mail.ru
Re: Bug#846002: Debian Installer Stretch RC 1 release
Hi Bjørn, Am 17.01.2017 um 10:28 schrieb Bjørn Mork: > To me it looks like a sandbox fight which started with the creative use > of "Priority: important". Now it appears that the party starting the > fight thinks the other party should stop throwing sand until "mommy" > (aka CTTE) decides who is right and who is wrong. > > I have of course probably gotten all this wrong. But that doesn't > really matter. The above describes how *I* subjectively perceive the > situation. That is not a subject for discussion. > > My personal advice, since I'm out here providing opionions nobody asked > for anyway, would be to start co-operating with the tasksel/installer > developers instead of waiting for a CTTE decision. That's not going to > solve your issues anyway. I think that your impression is not true here: "Priority: important" is the usual way to get a package installed at install time. And we announced to do this in the relevant bug, and this reached the table of d-i, with an explicite request for a comment or veto (which did not happen). After the following discussion we limited the number of entries and changed the wording to be less confusing. There was no response or critics to this from d-i until #846002 was opened (which was too late for other changes, according to Cyril). We were always ready to co-operate here, but without a getting a response this is a bit difficult. In the meantime, tasksel was extended by another entry "LXQt", making the "we don't want add items as they increase the confusion of tasksel" argument questionable. BTW, the usual way to cooperate is to open a bug report if something seems to go the wrong way with a package. If d-i was so unhappy about blends-tasks, why didn' they open a bug in summer saying that wording change and limiting entries is not enough? Finally: Yes, it seems that we have a conflict between two teams (blends and d-i), and CTTE is asked to decide for the technically best solution. I would really ask CTTE to evaluate the "confusion" argument (which is the central one here) in order to make a decision whether the blends should go into the installation menu or not. And who should maintain it (the blends or the d-i team) -- these two were the questions raised in the beginning from Holger. Best regards Ole
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
On Mon, 2017-01-16 at 20:11 +0100, permondes - sagen wrote: > no luck: > > > $ fw_printenv > > Cannot parse config file '/etc/fw_env.config': No such file or > > directory > > and indeed, the file does not exist. Yes, you would need to obtain or produce one suitable for your device, it's not automatically installed. There are various examples in /usr/share/doc/u-boot-tools/examples/ but you would likely need to find an one for your device with a search engine or produce one based on knowing where your u-boot saves the env. Ian.
Re: Bug#846002: Debian Installer Stretch RC 1 release
Andreas Tille writes: >> 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. > > While I'm not sure whether its a personal preference or whether some > discussion I might have missed has lead to this result but I'm similar > astonished as Ole about this result without a final decision of the > CTTE. If I can offer an view from the outside of this discussion: To me it looks like a sandbox fight which started with the creative use of "Priority: important". Now it appears that the party starting the fight thinks the other party should stop throwing sand until "mommy" (aka CTTE) decides who is right and who is wrong. I have of course probably gotten all this wrong. But that doesn't really matter. The above describes how *I* subjectively perceive the situation. That is not a subject for discussion. My personal advice, since I'm out here providing opionions nobody asked for anyway, would be to start co-operating with the tasksel/installer developers instead of waiting for a CTTE decision. That's not going to solve your issues anyway. Because, as has been pointed out by several people already: This whole mess was pointless from the start. No new Debian user will ever understand the meaning of the task menu. And no experienced Debian user will use it. Adding anything there is futile. You need to get into a dialogue with the installer developers so that you can find a way to properly integrate blends. And possibly remove tasks. This is of course way too late for Stretch. Live with it. Or continue wasting everybodys time on pointless discussions and be too late for the next release as well Bjørn
Bug#851539: Stretch RC1 netinst installer prompts for additional CDs
On 01/16/2017 07:56 PM, Josh Triplett wrote: > On Mon, Jan 16, 2017 at 12:30:03PM +, Steve McIntyre wrote: >> On Sun, Jan 15, 2017 at 11:51:43PM -0800, Josh Triplett wrote: >>> 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. >> >> There's also some netinsts with firmware included [1], and those are >> the ones this will help with. The previous settings in apt-setup were >> not very consistent and *very* old, so I've tweaked which images will >> ask about extra media. > > How does it help for the firmware-included images? > It makes it possible to use them to install from CD rather than from the network. Cheers, Julien
Re: dillon: additional build-depends for installation-guide
On Mon, 16 Jan 2017, Samuel Thibault wrote: > Peter Palfrader, on Sun 08 Jan 2017 19:51:14 +, wrote: > > On Sun, 08 Jan 2017, Holger Wansing wrote: > > > I'm sorry, I have to come back to this again: > > > > Applied, > > Sorry again, we had to change the font to fix japanese, here is a patch. > + fonts-vlgothic, installed. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Re: Bug#846002: Debian Installer Stretch RC 1 release
Hi, On Sun, Jan 15, 2017 at 02:24:13PM +0100, Ole Streicher wrote: > > 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. While I'm not sure whether its a personal preference or whether some discussion I might have missed has lead to this result but I'm similar astonished as Ole about this result without a final decision of the CTTE. Kind regards and thanks for working on the installer in any case Andreas. -- http://fam-tille.de
