Bug#751704: libparted ped_disk_clobber() overwrites firmware on some arm systems
Hello, the following is a discussion from the Debian bugtracking system regarding Debian Bug#751704 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704). It needs involvement from parted upstream, therefore I am forwarding it to bug-par...@gnu.org. Kind regards, Karsten - Forwarded message from Jim Meyering j...@meyering.net - Date: Sun, 17 Aug 2014 14:51:41 -0700 From: Jim Meyering j...@meyering.net Subject: Bug#751704: libparted questions (was: Bug#751704: partman-base 173: partman overwrites parts of u-boot) On Wed, Aug 13, 2014 at 12:07 PM, Karsten Merker mer...@debian.org wrote: [CCing Otavio Salvador and Jim Meyering; the following is a short summary of the situation; the full history can be read in bug #751704: Debian-Installer uses partman for partitioning, which in turn is based on libparted. On sunxi-based systems, upon writing the partition table, partman/libparted overwrites parts of u-boot which are located between the end of the partition table and the beginning of the first partition which results in an unbootable system. An attempt to solve this problem has been to conditionally set PedDisk.needs_clobber to 0 in partman when it detects that it is trying to write to a boot device on sunxi-based systems.] Colin Watson cjwat...@debian.org wrote: PedDisk.needs_clobber is marked as office use only in parted; I interpret that as meaning that it really shouldn't be fiddled with outside parted, even though it's technically exposed. Could you please look at fixing parted to avoid clobbering the firmware area instead? I think that would be more correct. I have no idea what is really meant with the comment /* office use only ;-) */ int needs_clobber; in /usr/include/parted/disk.h, so I would like to ask upstream for clarification. Otavio, Jim: you are listed as parted upstream maintainers on http://www.gnu.org/software/parted/ - could you shed some light on this? Is it ok for an application to fiddle with the needs_clobber element or is this to be considered strictly libparted-internal? @Colin: If the solution is to be completely encapsulated in libparted, I see a large problem in how to solve the conflict between space after the partition table being very differently used by firmware for different SoCs on one side, and libparted trying to make sure that there are no remains of other partition table formats in the respective area on the other side - at least with the prerequisite of keeping both the current defaults (clobbering) as well as keeping the libparted API unchanged. With the current there is one erase size for all platforms method in ped_disk_clobber() in libparted/disk.c, we inevitably end up with conflicting requirements. An example: the source for ped_disk_clobber() states: /* How many sectors to zero out at each end. This must be large enough to zero out the magic bytes starting at offset 8KiB on a DASD partition table. Doing the same from the end of the disk is probably overkill, but at least on GPT, we do need to zero out the final sector. */ So for at least one platform (according to Wikipedia DASD seems to be some s/390 format), the area at offset 8KiB has to be wiped out while for another (armhf/sunxi) it may not be wiped out as the u-boot SPL is located there and cannot be relocated because its sector address is hardcoded in the SoC. According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#25, similar problems (but at other offsets) come up for other SoCs. According to the examples listed there, for TI SoCs libparted would have to stop clobbering the GPT header after writing a DOS MBR, but could wipe the DASD area. For a Freescale i.MX SoC libparted could legally clobber the GPT header, but would have to refrain from clobbering the areas behind it. If you extrapolate this to the large number of different SoC families, to handle this completely inside libparted, the library would have to know what exactly is the target system for which it writes a partition table and special-case the handling for each of them. While one might assume that the partition table is for an s/390 system when a DASD partition table is generated, this does not work as easily for the plethora of different architectures and systems that use DOS MBR partition tables. This gets even more complicated by the fact that libparted may run on one platform but modify partition tables for another platform, such as when operating on disk images for use with emulators or when operating on hd-media images for different arm platforms (with different firmware/bootloader requirements) on one autobuild host, so trying to do runtime detection of the host system would still not cover all use cases. In the case of creating images from scratch, the problem can be circumvented by (re-)writing the
Re: Artwork for jessie?
Hi, I've upload the theme with the rescaled logo. If everything is OK, I can start the others artworks to complete the theme. Regards, Juliette - Mail original - De: Cyril Brulebois k...@debian.org À: Vincent Blut vincent.deb...@free.fr Cc: Adrien Aubourg adrien.aubo...@gmail.com, juliette belin juliette.be...@free.fr, Ulrich rusty@mailbox.org, onsemel...@riseup.net, Debian Desktop debian-desk...@lists.debian.org, debian-boot@lists.debian.org, Paul Tagliamonte paul...@debian.org Envoyé: Mercredi 13 Août 2014 17:42:39 Objet: Re: Artwork for jessie? Vincent Blut vincent.deb...@free.fr (2014-08-13): Le mer. 13 août 2014 à 14:40, Adrien Aubourg adrien.aubo...@gmail.com a écrit : Le 13/08/2014 14:33, juliette.be...@free.fr a écrit : Hi, I'm on hollidays until sunday, I don't have the right computer to work on the theme... Thank you for the scaling Adrien, but some others changes are necessary, all the lines must fit the new scaled logo. Can it wait until next week ? I tried to do my best, but sure it would be better if the original author do the rescaling him/herself. Paul should be the one who can tell if it can wait until next week. And Cyril, who needs those files in order to include them in the installer, which should be froze fairly soon ;-) Hello, for what it's worth, the next Beta (Beta 2) will likely not happen before one, maybe two months. Nevertheless, artwork has to be merged into several components, so it takes time to get all of this sorted. (I think Paul might tell you more about the relevant components.) Bottom line: as far as I can tell, waiting until next week should be good OK. :) Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1590103045.31088124.1408367126448.javamail.r...@zimbra19-e3.priv.proxad.net
Re: Re: the audio group
which is fine. But what if people decide to later not use logind/systemd? In what does it hurt that the first created user is *also* added to the audio group? When a user is added to the audio group. He will always see all sound devices, even when logind tries to hide the device from the user. e.g. in a multi seat setting, an user on seat0 can control the sound devices from another user on seat1. Especially now that we go to systemd as the default init system, I think it is wise to respect the systemd ACL settings. So we don't get unexpected behaviors. Thanks, floris -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/op.xksh7ona5k9...@jessica.jkfloris.demon.nl
Bug#758522: installation-reports: Jessie beta1 on Dell T410 successful
Package: installation-reports Severity: normal Jessie beta1 on Dell PowerEdge T410 installation was successful. I had to manually copy bnx2 firmware files into /lib/firmware/ but that is to be expected at this stage, I suppose. -- Package-specific info: Boot method: CD Image version: http://cdimage.debian.org/cdimage/jessie_di_beta_1/amd64/iso-cd/debian-jessie-DI-b1-amd64-netinst.iso Date: 2014-08-18 Machine: Dell PowerEdge T410 Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/sda1 ext4 922402716 813580 874710724 1% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 6600744 8744 6592000 1% /run tmpfs tmpfs 16501852 0 16501852 0% /dev/shm tmpfs tmpfs 16501852 0 16501852 0% /sys/fs/cgroup tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 102400 0102400 0% /run/user Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Without manually copying the bnx2 firmware files, installation would fail once the installer try to access the network to download packages. Configuring network appeared to work, but didn't, and looking at the kernel log suggests missing firmware. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=8 (jessie) - installer build 20140802 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux leo 3.14-2-amd64 #1 SMP Debian 3.14.13-2 (2014-07-24) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 5500 I/O Hub to ESI Port [8086:3403] (rev 13) lspci -knn: Subsystem: Dell Device [1028:028d] lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 [8086:3408] (rev 13) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:03.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 3 [8086:340a] (rev 13) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:07.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 7 [8086:340e] (rev 13) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:09.0 PCI bridge [0604]: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express Root Port 9 [8086:3410] (rev 13) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:0a.0 PCI bridge [0604]: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express Root Port 10 [8086:3411] (rev 13) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:14.0 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub System Management Registers [8086:342e] (rev 13) lspci -knn: 00:14.1 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers [8086:3422] (rev 13) lspci -knn: 00:14.2 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub Control Status and RAS Registers [8086:3423] (rev 13) lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 [8086:3a37] lspci -knn: Subsystem: Dell Device [1028:028d] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1a.1 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5 [8086:3a38] lspci -knn: Subsystem: Dell Device [1028:028d] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1a.7 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 [8086:3a3c] lspci -knn: Subsystem: Dell Device [1028:028d] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1 [8086:3a40] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1 [8086:3a34] lspci -knn: Subsystem: Dell Device [1028:028d] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.1 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI
Re: Re: the audio group
On Mon, Aug 18, 2014 at 03:24:50PM +0200, Floris wrote: which is fine. But what if people decide to later not use logind/systemd? In what does it hurt that the first created user is *also* added to the audio group? When a user is added to the audio group. He will always see all sound devices, even when logind tries to hide the device from the user. e.g. in a multi seat setting, an user on seat0 can control the sound devices from another user on seat1. And if we ignore the multi-seat stuff (which is going to be used by a *tiny* minority of users) there is no down-side. Especially now that we go to systemd as the default init system, I think it is wise to respect the systemd ACL settings. So we don't get unexpected behaviors. There are still likely going to be vastly more non-systemd users than multi-seat users. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818135234.ga14...@einval.com
Re: Re: the audio group
On Mon, Aug 18, 2014 at 02:52:34PM +0100, Steve McIntyre wrote: And if we ignore the multi-seat stuff (which is going to be used by a *tiny* minority of users) there is no down-side. There are still likely going to be vastly more non-systemd users than multi-seat users. That sure sounds likely. Perhaps there can be a README.multiseat in the systemd package that explains what changes to make for such a setup. Just because systemd is default doesn't mean everything else should stop working. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818142216.gh17...@csclub.uwaterloo.ca
Re: Re: the audio group
On Mon, Aug 18, 2014 at 10:22:16AM -0400, Lennart Sorensen wrote: That sure sounds likely. Perhaps there can be a README.multiseat in the systemd package that explains what changes to make for such a setup. Just because systemd is default doesn't mean everything else should stop working. Besides all existing installs that upgrade would need to make the same changes should they choose to move to a systemd multiseat setup. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818142335.gi17...@csclub.uwaterloo.ca
Re: Re: the audio group
Op Mon, 18 Aug 2014 15:52:34 +0200 schreef Steve McIntyre st...@einval.com: On Mon, Aug 18, 2014 at 03:24:50PM +0200, Floris wrote: which is fine. But what if people decide to later not use logind/systemd? In what does it hurt that the first created user is *also* added to the audio group? When a user is added to the audio group. He will always see all sound devices, even when logind tries to hide the device from the user. e.g. in a multi seat setting, an user on seat0 can control the sound devices from another user on seat1. And if we ignore the multi-seat stuff (which is going to be used by a *tiny* minority of users) there is no down-side. Especially now that we go to systemd as the default init system, I think it is wise to respect the systemd ACL settings. So we don't get unexpected behaviors. There are still likely going to be vastly more non-systemd users than multi-seat users. how about users who will login remotely? They also have full access to all the audio devices, even when they don't able to hear the music, because the speaker is on the other side of the world. But the main issue is, having two systems (groups and ACL) that control access rights for the same device give inconsistent behavior. A user can be in the audio group for sound, he doesn't have to be a member of lpadmin to use his printer. The cdrom group is only for non-out-of-the-box cd/ dvd devices etc. In the near future (systemd 215) [1] the need to be part of a group for a normal user will even be less important. So maybe we leave the situation for now and rethink about it in some time. thanks, floris [1] http://0pointer.de/blog/projects/stateless.html -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/op.xksnj5mp5k9...@jessica.jkfloris.demon.nl
Re: Re: the audio group
On Mon, Aug 18, 2014 at 05:20:19PM +0200, Floris wrote: how about users who will login remotely? They also have full access to all the audio devices, even when they don't able to hear the music, because the speaker is on the other side of the world. Remote login might be from a computer that's just on the other side of the room. -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818162955.ga32...@topoi.pooq.com
Re: Use dedicated partition for /boot/grub instead of /boot
On Mon, Aug 18, 2014 at 12:40:13AM -0500, Christopher Chavez wrote: 2. Would it be a better idea to only have /boot/grub, instead of /boot, on a separate partition? (I can confirm that it works both when installing and in existing setups, i.e. grub-install and update-grub both work as expected.) If it's separate partition, it could be shared between several different bootable Linux systems. Might this actually work, given that files in .boot/grub might end up being updated by any of them? Which might actually be what we want? -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818163350.gb32...@topoi.pooq.com
Bug#751704: bug#18289: libparted ped_disk_clobber() overwrites firmware on some arm systems
On Mon, Aug 18, 2014 at 08:19:17AM +0200, Karsten Merker wrote: Hello, the following is a discussion from the Debian bugtracking system regarding Debian Bug#751704 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704). It needs involvement from parted upstream, therefore I am forwarding it to bug-par...@gnu.org. Thanks for forwarding this. parted should only be clobbering these extra sectors when a new disklabel is applied (eg. mklabel in the ui) which, I think, is the appropriate thing to do. If you are operating on an existing disklabel and want to preserver a boot loader in the space before the 1st partition you shouldn't be calling ped_disk_new_fresh(). If you are creating a new disklabel then any boot loader code should be installed after partitioning. I don't think parted needs any changes. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818165949.gx27...@lister.brianlane.com
Re: Re: the audio group
Quoting Steve McIntyre (st...@einval.com): On Mon, Aug 18, 2014 at 03:24:50PM +0200, Floris wrote: which is fine. But what if people decide to later not use logind/systemd? In what does it hurt that the first created user is *also* added to the audio group? When a user is added to the audio group. He will always see all sound devices, even when logind tries to hide the device from the user. e.g. in a multi seat setting, an user on seat0 can control the sound devices from another user on seat1. And if we ignore the multi-seat stuff (which is going to be used by a *tiny* minority of users) there is no down-side. I'd anyway recommend to NOT create a user during Debian installation in such multi-seat setupswhich actually also solves the problem. user-setup has a preseedable variable for this: Template: passwd/make-user Type: boolean Default: true # :sl2: _Description: Create a normal user account now? Just pressed passwd/make-user to False and you're done. I'd anyway expect multi-seat setups to use an external account database. signature.asc Description: Digital signature
Bug#758522: marked as done (installation-reports: Jessie beta1 on Dell T410 successful)
Your message dated Mon, 18 Aug 2014 19:15:53 +0200 with message-id 20140818171553.gi3...@mykerinos.kheops.frmug.org and subject line Re: Bug#758522: installation-reports: Jessie beta1 on Dell T410 successful has caused the Debian Bug report #758522, regarding installation-reports: Jessie beta1 on Dell T410 successful 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.) -- 758522: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758522 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: installation-reports Severity: normal Jessie beta1 on Dell PowerEdge T410 installation was successful. I had to manually copy bnx2 firmware files into /lib/firmware/ but that is to be expected at this stage, I suppose. -- Package-specific info: Boot method: CD Image version: http://cdimage.debian.org/cdimage/jessie_di_beta_1/amd64/iso-cd/debian-jessie-DI-b1-amd64-netinst.iso Date: 2014-08-18 Machine: Dell PowerEdge T410 Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/sda1 ext4 922402716 813580 874710724 1% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 6600744 8744 6592000 1% /run tmpfs tmpfs 16501852 0 16501852 0% /dev/shm tmpfs tmpfs 16501852 0 16501852 0% /sys/fs/cgroup tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 102400 0102400 0% /run/user Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Without manually copying the bnx2 firmware files, installation would fail once the installer try to access the network to download packages. Configuring network appeared to work, but didn't, and looking at the kernel log suggests missing firmware. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=8 (jessie) - installer build 20140802 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux leo 3.14-2-amd64 #1 SMP Debian 3.14.13-2 (2014-07-24) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 5500 I/O Hub to ESI Port [8086:3403] (rev 13) lspci -knn: Subsystem: Dell Device [1028:028d] lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 [8086:3408] (rev 13) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:03.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 3 [8086:340a] (rev 13) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:07.0 PCI bridge [0604]: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 7 [8086:340e] (rev 13) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:09.0 PCI bridge [0604]: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express Root Port 9 [8086:3410] (rev 13) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:0a.0 PCI bridge [0604]: Intel Corporation 7500/5520/5500/X58 I/O Hub PCI Express Root Port 10 [8086:3411] (rev 13) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:14.0 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub System Management Registers [8086:342e] (rev 13) lspci -knn: 00:14.1 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers [8086:3422] (rev 13) lspci -knn: 00:14.2 PIC [0800]: Intel Corporation 7500/5520/5500/X58 I/O Hub Control Status and RAS Registers [8086:3423] (rev 13) lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 [8086:3a37] lspci -knn: Subsystem: Dell Device [1028:028d] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn:
Re: Re: the audio group
user-setup-apply is run in finish-install, so it can check if systemd is installed or not. The only downsides I see: * Still need to add the groups in non-systemd installations, eg freebsd, so this will be an point of difference that will need testing. * If a user chooses to remove systemd after the install, they would need to manually add the groups. -- see shy jo signature.asc Description: Digital signature
Re: Use dedicated partition for /boot/grub instead of /boot
On Mon, 2014-08-18 at 00:40 -0500, Christopher Chavez wrote: (Please let me know if there's a better venue for collecting feedback for this idea, or additional ones I should solicit feedback from. I primarily use Ubuntu, but I assume this is as upstream as it gets.) Background: It has been discussed (in other venues) where a separate /boot partition (e.g. for btrfs, LVM, and encrypted installations; or to workaround BIOS limitations), depending on how large it was when created, will have a likelihood of becoming full after multiple kernel updates, and there are corresponding bug reports likewise (which I have not listed here). Old kernel packages are now auto-removable in Debian and Ubuntu. So this should not be a common problem in future. One proposed measure was to not use a /boot partition in the first place, which often works, but I have also managed to have installations fail with core.img is unusually large, particularly in instances where the disk was pre-formatted, including Windows multiboot scenarios. This should no longer be a problem since the switch to UEFI. Questions: 1. Is it the case that the only reason for having a separate /boot was to provide easy access /boot/grub? I.e., was it intentional to provide easy access to kernels as well? No, your own background text explains why it might not be possible to load a kernel or initramfs from the root filesystem. Also, we support many more boot loaders than GRUB, with different limitations. 2. Would it be a better idea to only have /boot/grub, instead of /boot, on a separate partition? (I can confirm that it works both when installing and in existing setups, i.e. grub-install and update-grub both work as expected.) [...] I don't think so. Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
Re: Artwork for jessie?
Hi Debian fellows, In fact I was on the point to upload various Debian 8 themes, unfortunately I had a huge computing problem and I lost my recent works (and so my Debian 8 theme propositions). So, I would like to know if it would be possible to wait until the 25th August before closing submissions, the time for me to remake at least one theme ? Best regards. madeinkobaia Digital Artist - Ubuntu Studio Art Team Leader 2014-08-13 14:40 GMT+02:00 Adrien Aubourg adrien.aubo...@gmail.com: Le 13/08/2014 14:33, juliette.be...@free.fr a écrit : Hi, I'm on hollidays until sunday, I don't have the right computer to work on the theme... Thank you for the scaling Adrien, but some others changes are necessary, all the lines must fit the new scaled logo. Can it wait until next week ? I tried to do my best, but sure it would be better if the original author do the rescaling him/herself. Paul should be the one who can tell if it can wait until next week. Regards, Adrien Regards, Juliette - Mail original - De: Adrien Aubourg adrien.aubo...@gmail.com À: Vincent Blut vincent.deb...@free.fr, Paul Tagliamonte paul...@debian.org Cc: Ulrich rusty@mailbox.org, onsemel...@riseup.net, Cyril Brulebois k...@debian.org, Debian Desktop debian-desk...@lists.debian.org, debian-boot@lists.debian.org, juliette belin juliette.be...@free.fr Envoyé: Mercredi 13 Août 2014 13:51:08 Objet: Re: Artwork for jessie? Le 12/08/2014 23:07, Vincent Blut a écrit : Le mar. 12 août 2014 à 23:05, Paul Tagliamonte paul...@debian.org a écrit : Sounds like Lines has consensus. Fair enough; let's go with it, but we should revert the logo back to the original aspect. Which I do realize breaks the entire concept. -T Juliette, could we have a look of your theme with the original logo, please ? I took the liberty to do it myself. Have a look on the wiki page, I've just added a .zip file for Lines themes with the original Debian logo: https://wiki.debian.org/DebianArt/Themes/Lines Some minors changes though: - The logo is now in the center of the wallpapers - login backgrounds don't exist anymore (use wallpapers instead) - The logo is now in the cneter of the grub wallpaper. In addition, it's been faded into the background - I revamped syslinux background, but I think we should use less lines - The installer banner doesn't show Debian 8 text. Regards, Adrien Cheers, Vincent -- To UNSUBSCRIBE, email to debian-desktop-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53eb5cbb.1030...@gmail.com
Bug#758411: marked as done (d-i manual: aptitude is no longer the recommended package management tool)
Your message dated Mon, 18 Aug 2014 21:28:06 +0200 with message-id 20140818212806.fd90fa36b2db83f2b9bc6...@mailbox.org and subject line Re: Bug#758411: d-i manual: aptitude is no longer the recommended package management tool has caused the Debian Bug report #758411, regarding d-i manual: aptitude is no longer the recommended package management tool 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.) -- 758411: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758411 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: installation-guide Tags: patch Hi, IMO aptitude is no longer the recommended package management tool. AFAIK the release-notes for example now recommend apt-get (for dist-upgrades at least). Probably the following patch should be applied. Holger -- Holger Wansing hwans...@mailbox.org Index: en/using-d-i/modules/apt-setup.xml === --- en/using-d-i/modules/apt-setup.xml (Revision 69238) +++ en/using-d-i/modules/apt-setup.xml (Arbeitskopie) @@ -24,8 +24,7 @@ Other front-ends for package management, like commandaptitude/command and commandsynaptic/command, are also in use. These front-ends are recommended for new users, since they integrate some additional features (package searching and status checks) -in a nice user interface. In fact, commandaptitude/command is now the -recommended utility for package management. +in a nice user interface. /parapara ---End Message--- ---BeginMessage--- Hi, Cyril Brulebois k...@debian.org wrote: Holger Wansing hwans...@mailbox.org (2014-08-17): IMO aptitude is no longer the recommended package management tool. AFAIK the release-notes for example now recommend apt-get (for dist-upgrades at least). Probably the following patch should be applied. Hello, I'm not sure synaptic is still the thing pulled by major desktop environments but I agree that recommending aptitude looks wrong, so feel free to remove that sentence. Done. Holger -- Holger Wansing hwans...@mailbox.org---End Message---
Bug#751704: bug#18289: libparted ped_disk_clobber() overwrites firmware on some arm systems
On Mon, Aug 18, 2014 at 09:59:49AM -0700, Brian C. Lane wrote: On Mon, Aug 18, 2014 at 08:19:17AM +0200, Karsten Merker wrote: Hello, the following is a discussion from the Debian bugtracking system regarding Debian Bug#751704 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704). It needs involvement from parted upstream, therefore I am forwarding it to bug-par...@gnu.org. Thanks for forwarding this. parted should only be clobbering these extra sectors when a new disklabel is applied (eg. mklabel in the ui) which, I think, is the appropriate thing to do. If you are operating on an existing disklabel and want to preserver a boot loader in the space before the 1st partition you shouldn't be calling ped_disk_new_fresh(). If you are creating a new disklabel then any boot loader code should be installed after partitioning. I don't think parted needs any changes. Hello, thanks for your swift reply. I fully understand your position, but unfortunately things on arm are fundamentally different from the PC world. U-Boot is more of a BIOS than a bootloader like GRUB; it is highly board specific and handles low-level stuff such as setting the IO pinmuxing for the specific board and configuring the DRAM controller. Without it, the board is completely dead from a user perspective. On a PC, the BIOS is always available in ROM/Flash even when all disk devices have been wiped and the user can still select some other device (such as the network, a CDROM drive or a USB memory stick) to boot from. On the arm systems we are talking about, there is no ROM BIOS and the u-boot image on the SD card (or on an eMMC chip) is the only way to interact with the system at all. The usual case is that the u-boot image is written raw onto the storage medium, i.e. there is no partition table or filesystem on it by default, so we need to create a new disklabel in the installer. You are fully right that normally a bootloader should be installed after partitioning. This works well for the case of a bootloader that uses universally available BIOS functions and is not hardware-specific, such as is the case on PCs. In the case of u-boot on the other hand, in PC-lingo we would have to provide the installer with the ability to flash the BIOS for every PC model on the market as part of the operating system installation, which is not feasible. We might be able to do that for a small selection of devices, but not for all of them -- we need to keep the u-boot image that is on the device even when creating a new disklabel, but we are unsure what is the best way to handle this. The approach in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#60 (setting PedDisk.needs_clobber to 0 before calling ped_disk_commit for specific devices) works in practice, but the question was whether it is ok for the calling application to fiddle around with the needs_clobber flag, or whether we should take some other approach. Kind Regards, 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. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818200759.ga4...@excalibur.cnev.de
Bug#485586: debian-installer: Default to graphical install
Hi, Cyril Brulebois k...@debian.org wrote: Holger Wansing hwans...@mailbox.org (2014-08-17): That would lead to more changes to the d-i manual IMO. Indeed, and since you were updating the manual already I thought it might make sense to batch everything together. At least: booting of the graphical installer is now only documented in an appendix. If Graphical install is the default, the info about it should be integrated into the regular boot-installer chapter. I could provide a first patch as a proposal, if wanted. I haven't taken the time to look at what's documented right now, but feel free to start updating the doc. As I see it, the needed modifications should only be about updating the menu entry getting selected by default, so that we move from text-mode install to graphical-mode install on amd64/i386 architectures. I have prepared a patch for this (attached) and I would like to receive some thoughts on it. I have added Samuel Thibault in CC, since he has also some knowledge and interest on the d-i manual. Basically I moved the chapter Appendix D.6. The Graphical Installer to 5.1.8 (at the end of Booting the installer on 32-bit PC), leaving the content unchanged. And I moved chapter Appendix D.6.1. Using the graphical installer to 6.1.1 (at the end of How the Installer Works), leaving the content mostly unchanged (only the first line differs). Holger -- Holger Wansing hwans...@mailbox.org Index: en/boot-installer/x86.xml === --- en/boot-installer/x86.xml (Revision 69238) +++ en/boot-installer/x86.xml (Arbeitskopie) @@ -401,7 +401,7 @@ For a normal installation, select either the quoteInstall/quote or the quoteGraphical install/quote entry mdash; using either the arrow keys on your keyboard or by typing the first (highlighted) letter, the -quoteInstall/quote entry is already selected by default mdash; and press +quoteGraphical install/quote entry is already selected by default mdash; and press enterkey; to boot the installer. /parapara @@ -473,3 +473,83 @@ /para /sect2 + + sect2 condition=gtk id=graphical + titleThe Graphical Installer/title +para + +The graphical version of the installer is only available for a limited +number of architectures, including arch-title;. The functionality of +the graphical installer is essentially the same as that of the regular +installer as it basically uses the same programs, but with a different +frontend. + +/parapara + +Although the functionality is identical, the graphical installer still has +a few significant advantages. The main advantage is that it supports more +languages, namely those that use a character set that cannot be displayed +with the regular quotenewt/quote frontend. It also has a few usability +advantages such as the option to use a mouse, and in some cases several +questions can be displayed on a single screen. + +/parapara arch=any-x86 + +The graphical installer is available with all CD images and with the +hd-media installation method. To boot the graphical installer simply select +the relevant option from the boot menu. Expert and rescue mode for the +graphical installer can be selected from the quoteAdvanced options/quote +menu. The previously used boot methods userinputinstallgui/userinput, +userinputexpertgui/userinput and userinputrescuegui/userinput can +still be used from the boot prompt which is shown after selecting the +quoteHelp/quote option in the boot menu. + +/parapara arch=any-x86 + +There is also a graphical installer image that can be netbooted. And there +is a special quotemini/quote ISO imagefootnote id=gtk-miniiso + +para +The mini ISO image can be downloaded from a debian; mirror as described +in xref linkend=downloading-files/. +Look for filenamenetboot/gtk/mini.iso/filename. +/para + +/footnote, which is mainly useful for testing. + +/parapara arch=powerpc + +For arch-title;, currently only an experimental quotemini/quote ISO +image is availablefootnote id=gtk-miniiso + +para +The mini ISO image can be downloaded from a debian; mirror as described +in xref linkend=downloading-files/. +Look for filenamenetboot/gtk/mini.iso/filename. +/para + +/footnote. It should work on almost all PowerPC systems that have +an ATI graphical card, but is unlikely to work on other systems. + +/parapara + +Just as with the regular installer it is possible to add boot parameters +when starting the graphical installer. + +/para +notepara + +The graphical installer requires significantly more memory to run than +the regular installer: minimum-memory-gtk;. If insufficient memory is +available, it will automatically fall back to the regular +quotenewt/quote frontend. + +/parapara + +If the amount of memory in your system is below minimum-memory;, +the graphical installer may fail to boot at all while booting the +regular installer would still work. Using the regular installer is +recommended for systems with little available
Bug#485586: debian-installer: Default to graphical install
Hi Holger, and thanks for the proposed patch! Holger Wansing hwans...@mailbox.org (2014-08-18): Index: en/boot-installer/x86.xml === --- en/boot-installer/x86.xml (Revision 69238) +++ en/boot-installer/x86.xml (Arbeitskopie) @@ -401,7 +401,7 @@ For a normal installation, select either the quoteInstall/quote or the quoteGraphical install/quote entry mdash; using either the arrow keys on your keyboard or by typing the first (highlighted) letter, the -quoteInstall/quote entry is already selected by default mdash; and press +quoteGraphical install/quote entry is already selected by default mdash; and press enterkey; to boot the installer. The x86 part is likely correct… at least I was considering defaulting to graphical on (Linux) amd64 and i386 only. From a quick look it seems we have a netboot-gtk target for: amd64 armel (kirkwood only) armhf hurd-i386 (not released, who cares) i386 kfreebsd-amd64 powerpc (both powerpc and powerpc64) Additionally we have a cdrom_gtk target for: amd64 hurd-i386 i386 kfreebsd-amd64 Now, hurd-i386 doesn't need caring about; kfreebsd-* architectures are looking quite badly already, so I won't change anything on those right now. I expect arm* people to tell us whether any change is needed for those, but since I see no menu anyway… This lefts us with powerpc which has no menu either. = This means amd64 + i386 only, unless I'm missing something? +/parapara arch=powerpc + +For arch-title;, currently only an experimental quotemini/quote ISO +image is availablefootnote id=gtk-miniiso + +para +The mini ISO image can be downloaded from a debian; mirror as described +in xref linkend=downloading-files/. +Look for filenamenetboot/gtk/mini.iso/filename. +/para + +/footnote. It should work on almost all PowerPC systems that have +an ATI graphical card, but is unlikely to work on other systems. = So no powerpc here I think. I'd have to check an actual installation image under emulation, maybe; but I'm a bit too lazy for this right now. Worst case we could ping debian-powerpc@ to make sure. +notepara + +The graphical installer requires significantly more memory to run than +the regular installer: minimum-memory-gtk;. If insufficient memory is +available, it will automatically fall back to the regular +quotenewt/quote frontend. + +/parapara + +If the amount of memory in your system is below minimum-memory;, +the graphical installer may fail to boot at all while booting the +regular installer would still work. Using the regular installer is +recommended for systems with little available memory. + +/para/note I'm not sure since I tend to use 1GB RAM every time, but I thought there was some fallback mechanism in place? This was just a cursory reading, but the rest looks fine. Hopefully you'll get some more review. At least Steve was interested in seeing this happen, and he's a native speaker as well. :-) Mraw, KiBi. signature.asc Description: Digital signature
Bug#485586: debian-installer: Default to graphical install
Cyril Brulebois, le Mon 18 Aug 2014 23:36:03 +0200, a écrit : +notepara + +The graphical installer requires significantly more memory to run than +the regular installer: minimum-memory-gtk;. If insufficient memory is +available, it will automatically fall back to the regular +quotenewt/quote frontend. + +/parapara + +If the amount of memory in your system is below minimum-memory;, +the graphical installer may fail to boot at all while booting the +regular installer would still work. Using the regular installer is +recommended for systems with little available memory. + +/para/note I'm not sure since I tend to use 1GB RAM every time, but I thought there was some fallback mechanism in place? There is, but atm with 128MiB RAM it doesn't even boot, just because the initrd is so big that we don't even get to boot to the point of the fallback script. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818214931.gh8...@type.youpi.perso.aquilenet.fr
Bug#485586: debian-installer: Default to graphical install
Helloo, Holger Wansing, le Mon 18 Aug 2014 23:07:11 +0200, a écrit : Basically I moved the chapter Appendix D.6. The Graphical Installer to 5.1.8 (at the end of Booting the installer on 32-bit PC), leaving the content unchanged. And I moved chapter Appendix D.6.1. Using the graphical installer to 6.1.1 (at the end of How the Installer Works), leaving the content mostly unchanged (only the first line differs). That seems sensible indeed. It would be very convenient, whenever you commit this, to actually remove the old text, so it's really a move :) Also, please do the same move in all the .xml translations, so that translators don't have to do anything about it. The po translations shouldn't need any change. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818214812.gg8...@type.youpi.perso.aquilenet.fr
Bug#758581: debian-installer: FTBFS on armhf/network-console: No library provides non-weak __aeabi_unwind_cpp_pr0
Package: debian-installer Version: 20140802 Severity: serious Justification: FTBFS Hi, I've noticed what $Subject says through the daily builds. Looking at last successful build and today's (failing) one, a few things pops up: | -Unpacking libdebian-installer4-udeb (0.94) ... | +Unpacking libdebian-installer4-udeb (0.95) ... → addition of ppc64el support, not likely to be an issue | -Unpacking zlib1g-udeb (1:1.2.8.dfsg-1) ... | +Unpacking zlib1g-udeb (1:1.2.8.dfsg-2) ... → irrelevant changes AFAICT In the library reduction passes: | -1052 symbols, 637 unresolved | +1051 symbols, 636 unresolved […] | -reducing libgcc_s.so.1 | -No pic file found for /lib/arm-linux-gnueabihf//libgcc_s.so.1 ; copying […] | -Object: ./tmp/network-console/tree/lib/libgcc_s.so.1-so-stripped […] | +1170 symbols, 38 unresolved | +Traceback (most recent call last): | + File /usr/bin/mklibs, line 560, in module | +raise Exception(No library provides non-weak %s % name) | +Exception: No library provides non-weak __aeabi_unwind_cpp_pr0 libgcc_s.so.1 comes from a gcc package, and there's been a gcc-4.9 package in unstable for 2 days, which might match. But then I don't see any difference in package contents or symbols list for the libgcc1 packages between 1:4.9.1-5 and 1:4.9.1-7. I'm afraid I'm running out of the time to dig deeper into what's mklibs is after (possibly a _pic.a but I don't see any for libgcc_s). Having both a glibc and a gcc-4.9 upload in the said time window could explain this regression, as a wild guess. Could somebody from debian-arm@ (x-d-cc) check what's going on precisely and possibly forward the failure to the right place if d-i isn't the buggy package here? Thanks for your time. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818223422.17543.37141.report...@wodi.home.mraw.org
Bug#485586: debian-installer: Default to graphical install
Cyril Brulebois k...@debian.org (2014-08-18): Now, hurd-i386 doesn't need caring about; kfreebsd-* architectures are looking quite badly already, so I won't change anything on those right now. I expect arm* people to tell us whether any change is needed for those, but since I see no menu anyway… This lefts us with powerpc which has no menu either. = This means amd64 + i386 only, unless I'm missing something? +/parapara arch=powerpc + +For arch-title;, currently only an experimental quotemini/quote ISO +image is availablefootnote id=gtk-miniiso + +para +The mini ISO image can be downloaded from a debian; mirror as described +in xref linkend=downloading-files/. +Look for filenamenetboot/gtk/mini.iso/filename. +/para + +/footnote. It should work on almost all PowerPC systems that have +an ATI graphical card, but is unlikely to work on other systems. = So no powerpc here I think. I'd have to check an actual installation image under emulation, maybe; but I'm a bit too lazy for this right now. Worst case we could ping debian-powerpc@ to make sure. I've now checked that indeed powerpc has had a graphical target for a long while but it hasn't been used/advertised through boot menus, at least from what I can tell by looking at the files under the build/boot/powerpc directory in the debian-installer source package. +notepara + +The graphical installer requires significantly more memory to run than +the regular installer: minimum-memory-gtk;. If insufficient memory is +available, it will automatically fall back to the regular +quotenewt/quote frontend. + +/parapara + +If the amount of memory in your system is below minimum-memory;, +the graphical installer may fail to boot at all while booting the +regular installer would still work. Using the regular installer is +recommended for systems with little available memory. + +/para/note I'm not sure since I tend to use 1GB RAM every time, but I thought there was some fallback mechanism in place? Except that I missed what Samuel mentioned. :-) Mraw, KiBi. signature.asc Description: Digital signature
Bug#485586: debian-installer: Default to graphical install
[ Adding -accessibility@ and -cd@ to the loop. ] Steve McIntyre st...@einval.com (2014-08-17): On Sun, Aug 17, 2014 at 01:25:28PM +0200, Cyril Brulebois wrote: Control: tag -1 confirmed Another issue is that it requires much more memory, but that IMO is not a blocker. It does require careful documentation though. Holger's last reports reminded of this, which we finally didn't do for wheezy. Unless someone has an objection, I'll schedule this switch for the next d-i upload. Yay, definitely. We never did get round to this for Wheezy, so let's get it done now. On a related note: we have an amd64-i386 “multi-arch” netinst image. I'd be happy to take opinions on the following questions since that's the only image linked directly from www.debian.org, which leads some people to call it “_the_ default installation image”… Its boot menu reads right now (at least in Jessie Beta 1): Install 64 bit install Graphical install 64 bit graphical install Advanced options Help Install with speech synthesis 64 bit speech install FWIW, I'm tempted to modify it so that it becomes: Install Graphical install 64 bit install 64 bit graphical install Advanced options Help Install with speech synthesis 64 bit speech install This means swiching items #2 and #3, so that we have 32-bit and 64-bit entries together (which is what happens in the Advanced options sub-menu). Speech synthesis entries can be kept together separately (see below). = debian-boot/cd@: anyone against such a change? The default is Install right now, which installs i386. The topic of this bug report is switching to Graphical install by default, but shouldn't we also promote amd64 by default while we're at it? This would mean having 64 bit graphical install as the default. = debian-boot/cd@: do we want amd64 by default? Since the menus can be confusing a bit, I'm also wondering whether we should be explicit about the non-64 bit items, and prefix them with 32 bit. = debian-boot/cd@: opinions? If we were to switch to amd64 as the default architecture, we should probably point the s shortcut (for speech synthesis) from Install with speech synthesis to 64 bit speech install. = debian-accessibility@: if we go from i386 to amd64 by default, is there anything that needs to be done on your side (doc update etc.) that we should coordinate with you? As far as I can see, right now we have s = i386, s + down arrow = amd64. This change would mean s = amd64, s + up arrow = i386. I'm not sure that changing the shortcuts are a good thing, to be honest, but being consistent as far as the default architecture is concerned would probably be a good idea anyway. :/ Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#485586: debian-installer: Default to graphical install
Cyril Brulebois, le Tue 19 Aug 2014 01:17:02 +0200, a écrit : = debian-accessibility@: if we go from i386 to amd64 by default, is there anything that needs to be done on your side (doc update etc.) Normally, only the installer manual would need an update. I don't see the multi-arch boot menu documented there, however. that we should coordinate with you? As far as I can see, right now we have s = i386, s + down arrow = amd64. This change would mean s = amd64, s + up arrow = i386. I'm not sure that changing the shortcuts are a good thing, to be honest, but being consistent as far as the default architecture is concerned would probably be G good idea anyway. :/ It happens that we have apparently never documented the case of the multiarch image on http://wiki.debian.org/accessibility , so there is no actual regression with the change. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818233805.gs8...@type.youpi.perso.aquilenet.fr
Bug#757985: kfreebsd-* release status? (was: #757985: kfreebsd: d-i hangs)
[ I'm adding -release@ to the loop. I tried to refrain from mentioning my concerns in the Jessie Beta 1 announce, that's why I used a quite neutral wording, but let's be honest: kfreebsd-* is looking bad right now. ] Cyril Brulebois k...@debian.org (2014-08-14): Steven Chamberlain ste...@pyro.eu.org (2014-08-13): Some new installer components have appeared since wheezy, such as partman-iscsi, which is arch: all. It is of no use without open-iscsi-udeb, which is linux-any. Is it a bug that it is added into kfreebsd images with unsatisfied dependencies? And/or, must we work around it by making partman-iscsi arch: linux-any? I know it is not very big, but it is shown in the partman menu, despite it not going to work. I don't think we'll have userland iSCSI initiator support for jessie. (Non-)installability seems quite orthogonal to the fact that we're hitting ENOSPC right after locale-related settings, doesn't it? If a single extra udeb (or udeb size increase, which happens from time to time) is going to break kfreebsd-*, it seems to me that their status is far too brittle. To expand a bit on my earlier reply: that wouldn't be the first partman-* package being uninstallable. See the edos/dose reports (table or graphs): http://d-i.debian.org/edos/#unstable http://d-i.debian.org/edos/graph-unstable-kfreebsd-amd64.png http://d-i.debian.org/edos/graph-unstable-kfreebsd-i386.png I'm also quite astonished about being the one reporting that. Did I miss developer/porter testing and/or user reports? This kind of breakage is so bad that I would have expected reports way earlier, or at least before my own noticing that these images are unusable… Is anyone currently working on figuring out what exactly the problem is, and how to fix it? FWIW the current state of d-i on kfreebsd-*, along with unfixed (not even replied to) serious bug reports in kfreebsd headers (#750836, #756553), and upgradability issues (kernel removal, #756464) kind of get me worried about kfreebsd-* releasability for jessie. Mraw, KiBi. signature.asc Description: Digital signature
Processed: Re: Bug#758476: d-i manual: part about bootloader installation is missing in example preseed file 'preseed.txt'
Processing control commands: tags -1 + pending Bug #758476 [installation-guide] d-i manual: part about bootloader installation is missing in example preseed file 'preseed.txt' Added tag(s) pending. -- 758476: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758476 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b758476.140840757717743.transcr...@bugs.debian.org
Bug#758476: d-i manual: part about bootloader installation is missing in example preseed file 'preseed.txt'
Control: tags -1 + pending Holger Wansing, le Sun 17 Aug 2014 22:59:19 +0200, a écrit : The relevant paragraph was set to arch=any-x86 with this commit: http://anonscm.debian.org/viewvc/d-i/trunk/manual/en/appendix/preseed.xml?r1=65001r2=65009 This attribute works for building the manual itself, but it fails for the preseed.pl script, which generates the preseed.txt file. In the perl script it is documented that 'condition' attributes and 'arch' attributes are supported by the script, but there are apparently some problems. Indeed, it wasn't implementing the any and x86 magics. I have commited support for them, the bootloader section now gets in. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140819001932.gw8...@type.youpi.perso.aquilenet.fr
Re: Debian Installer Jessie Beta 1 release
I installed Jessie using a Braille display. Debian-Jessie-DI-b1-amd64-net inst.iso I tried to get Orca going like this. Open a text console and login as root: aptitude instal gnome-orca orca -t Now it tells me no speech is available, so I do aptitude install espeak orca -t Still no speech available, so I reboot. Now open up a text console again as root and type orca -t It talks this time and I go through the prompts, It tells me that it can't start the screen reader, because it can't connect to the Desktop. How should a novice ORCA user start up orca so that it will read the graphical login? By the way, the Braille doesn't read the graphical login either, we siply get screen not in text mode? Thanks! On Wed, 13 Aug 2014 18:19:46 +0200 Samuel Thibault sthiba...@debian.org wrote: Hello, Please help by testing this release, so we can have time to iron out bugs before the Jessie release! - Forwarded message from Cyril Brulebois k...@debian.org - From: Cyril Brulebois k...@debian.org To: debian-devel-annou...@lists.debian.org Subject: Debian Installer Jessie Beta 1 release The Debian Installer team[1] is pleased to announce the first beta release of the installer for Debian 8 Jessie. Important changes in this release of the installer == * Gnome installation images have been fixed (#756774): they will now really install Gnome (instead of Xfce). They should offer the best experience as far as accessibility is concerned. * A major parted release was merged lately, and many related components needed an update accordingly. If you experience any troubles during the partitioning step, please make sure to include /var/log/syslog (as usual) but also /var/log/partman in your installation report. * A major release of syslinux also appeared, with incompatible changes. It has consequences on various aspects, including PXE setups (see Ron's analysis in #757920), and theming. The artwork part will be dealt with in a later installer release. * The default init system on Linux is now systemd. Other changes in this release of the installer == * cdebconf: Resize banner when window width and banner width don't match (#745359). * debian-installer: - Deal with incompatible changes in syslinux. - Drop some parted_server functions (due to parted changes). * kfreebsd-9: replaced with kfreebsd-10. * linux: updated to 3.14.15. * preseed: Re-enable keyboard question on file preseed (#696857). Hardware support changes * debian-installer: - Add support for mipsel/loongson-3. - Add support for QNAP HS-210. - Add support for D-Link DNS-320. - Add some dtb files for armhf and armel/kirkwood. - Drop support for armhf/efikamx (no longer supported upstream). * linux: - [armhf] Add MMC and NIC modules for BeagleBone Black to udebs (#754491). - [armhf] Add virtio-modules udeb. - [armhf] Enable BRCMFMAC, BRCMFMAC_SDIO as modules (#734430). - [armhf] Backport sunxi AHCI and GMAC drivers from v3.15-rc1. - [armhf] Enable more Allwinner/sunxi drivers (#745972). - [mips*] Add few new udebs and use standard udebs configuration when possible. - [mips,mipsel] Remove the sb1a-bcm91480b flavour. - [mipsel/loongson3] Add support for Loongson 3 LS3A RS780E 1-way boards. - [mips,mipsel] Enable initramfs for all flavours, but keep the disk related drivers built-in for now. - [mips/octeon] Backport from upstream PCIe2 support and interface mode detection for Octeon. - [mips,mipsel/4kc-malta] Fix bug which can cause incorrect system call restarts (fix hang on boot). - [x86] udeb: Add hyperv-keyboard to hyperv-modules. - udeb: Add sdhci-acpi to mmc-modules (#747284). - udeb: Add mtip32xx, nvme to sata-modules. - udeb: Update sound-modules (#743319). - Include virtio_mmio in virtio-modules udeb when available. * u-boot: - Add support for some CuBox and Cubieboard targets. - Drop support for powerpc. Known bugs in this release == * Firmware handling: udev no longer reports missing firmware (#725714), and patches for the kernel need polishing before we are able to restore support for loading missing firmware. * GNU/kFreeBSD installation images suffer from various important bugs (#757985, #757986, #757987, #757988). Porters could surely use some helping hands to bring the installer back into shape! See the errata[2] for details and a full list of known issues. Feedback for this release = We need your help to find bugs and further improve the installer, so please try it. Installer CDs, other media and everything else you will need are available at our web
Re: Re: the audio group
Quoting Joey Hess (jo...@debian.org): user-setup-apply is run in finish-install, so it can check if systemd is installed or not. Interesting suggestion, yes. The only downsides I see: * Still need to add the groups in non-systemd installations, eg freebsd, so this will be an point of difference that will need testing. * If a user chooses to remove systemd after the install, they would need to manually add the groups. Not the groups, but the first created user to the groups, which seems reasonable to me. signature.asc Description: Digital signature
Re: Bug#485586: debian-installer: Default to graphical install
Hoy, Le mardi, 19 août 2014, 01.17:02 Cyril Brulebois a écrit : The default is Install right now, which installs i386. The topic of this bug report is switching to Graphical install by default, but shouldn't we also promote amd64 by default while we're at it? This would mean having 64 bit graphical install as the default. = debian-boot/cd@: do we want amd64 by default? While I don't have a definitive opinion on the ordering of the menu choices, I definitively think amd64 should be picked by default on amd64 architectures. Especially since multiarch, there's no good reason left for installing i386 on amd64-capable machines AFAIK. Now, the ideal would be to use syslinux' ifcpu/ifcpu64 c32 modules to determine the menu order depending on the machine (see [0]): no 64 bit option on 32 bit machines, hidden or down the menu 32 bit option on 64 bit-capable machines. I'd be happy to iron out some proposals during DebConf, if that idea seems interesting. OdyX [0] https://bugs.debian.org/707844#45 signature.asc Description: This is a digitally signed message part.
