Re: Bug#485586: debian-installer: Default to graphical install
Didier 'OdyX' Raboud o...@debian.org (2014-08-19): 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. OK, ta. 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. I didn't mention this because my mails contained too many questions already, but yes, it would be nice to have a conditional behaviour, depending on the detected architecture. Maybe automatic selection of the default architecture in the multi- arch image; and displaying a warning on i386 if an amd64 image was booted? Probably to be tracked in a separate, wishlist bug report to avoid conflating everything, even if the topics are quite close, I admit. Mraw, KiBi. signature.asc Description: Digital signature
Re: Use dedicated partition for /boot/grub instead of /boot
2014/08/18 14:57 Christopher Chavez 2000...@gmail.com: (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.) Upstream relative to what? Boot managers have their own projects and mailing lists. 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). debian, at any rate, has not had problems with old kernels filling up the /boot partition for a long time. I don't care for the way it's being done, but it pretty much works. 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. I generally never bothered with a separate /boot on i386 back in the days of Fedora 4 or so, but I knew my BIOS could see the whole drive. openbsd uses a different partitioning scheme and a different way to boot, fits the boot-up code and all the openbsd partitions within a single BIOS recognized partition. It uses a kind of relay or trampoline technique, so the code that the BIOS passes control off to doesn't ever have to move. Grub 1 was kind of like that, too, but in a different way. openbsd can boot without a boot manager, but the whole purpose of grub is to hand off the boot to something else. 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? I guess it depends on what you mean by easy access. If you mean, to keep the kernel where it can be easily found by the boot manager, yeah, that's one of the big reasons. That information used to be a lot more available, until some IPidiots started trying to claim rights to it. But you can still find it on wikipedia. But I think your question was answered in the chat session you quoted below. And elsewhere in this thread. It occurs to me that putting grub in its own partition might make it easier for the various distros to cooperate about updating the grub configuration file. But I don't know if anyone is working on that. I would definitely not do it with the old BIOS partitions. Not enough partitions to work with. 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.) Have you found a way to tell each distro to use the independent grub? 3. If so, then what should its size be? Does it vary by installation and is it expected to grow over time? (In my case it requires ~5MB for i386, so I used a ~30MB ext4 partition. I have not considered UEFI, e.g. if using the ESP is better.) Have you looked at the grub project's site? I attempted to collect some preliminary feedback on IRC (the following was logged publicly): #ubuntu, 25 Jul 2014: [00:50] chrstphrchvz Does the size of /boot/grub vary by installation or over time, making it undesirable for separate partition? see description: http://ur1.ca/htmwi(Unsure if a support or development question, since I am seeking knowledge/opinion.) [00:52] TJ- chrstphrchvz: Yes, it can vary slightly as newer kernels are installed, if older kernels aren't also removed. I generally use a 512MB /boot/ file-system partition [00:56] Bashing-om chrstphrchvz: A separate /boot is something of an anachronism, dating back to limited PC BIOSes that could only handle small disks, so the boot files had to be at the start of the disk. Nowadays, this is no longer applicable . ^^^*^^^ [00:57] chrstphrchvz TJ-, I mean specifically /boot/grub rather than /boot (i.e. as an alternative). E.g. I can keep /boot on my root partition, and use a separate /boot/grub, but is a good idea? (I know it works.) [00:58] TJ- chrstphrchvz: You're asking to confuse GRUB, since it expects /boot/ and /boot/grub/ to be in the same root file-system or, more specifically, the grub configuration updater tool. [00:59] TJ- chrstphrchvz: but specifically, grub/ doesn't vary much in size, it contains the GRUB loadable modules, the saved environment, and grub.cfg [01:04] chrstphrchvz Bashing-om, GRUB is (theoretically) able to boot LVM etc. (what it is typically installed with nowadays) without a /boot partition, but it can result in core.img unusually large and failing to install (see description for cases). [01:06] chrstphrchvz TJ-,
Bug#485586: debian-installer: Default to graphical install
On Mon 18 Aug 2014 at 23:07:11 +0200, Holger Wansing wrote: 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. Defaulting to a graphical (gtk) frontend on i386 and amd64 would mean that it becomes the regular frontend, unless it is desired to credit the newt frontend with some special status. In the context of Section 5.3.2. there is a difference between the text and newt frontends. But for many users the distinction is lost and the present regular frontend as presented in the user interface is a text one. 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). Section 6.1 uses character-based instead of text. It would be nice to have some consistency in referring to the alternative to the default graphical installation. 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. I'd restructure that to draw attention to the default highlighting and to have it read better. For a normal installation, select either the “Install” or the “Graphical install” entry — using either the arrow keys on your keyboard or by typing the first (highlighted) letter — and press Enter to boot the installer. The entry Graphical install is already selected by default. +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. Replace regular with text? +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. Replace regular newt frontend with text installer? +Just as with the regular installer it is possible to add boot parameters +when starting the graphical installer. Replace regular with text? +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. Replace both regulars with texts? +The graphical installer basically works the same as +the regular installer and thus the rest of this manual can be used to guide +you through the installation process. Replace regular with text? +To switch to another console, you will also need to use the +keycapCtrl/keycap key, just as with the X Window System. For example, +to switch to VT2 (the first debug shell) you would use: keycombo +keycapCtrl/keycap keycapLeft Alt/keycap keycapF2/keycap +/keycombo. The graphical installer itself runs on VT5, so you can use +keycombo keycapLeft Alt/keycap keycapF5/keycap /keycombo +to switch back. I'm unsure whether a reference to the X Window System is useful, even for those who know what it is. In Section 6,1 the paragraph beginning For this architecture the would need the default user interface and the link altering. There are also a few other links in the manual to Sections D.6. and D.6.1.. In Section 5.3.2. should the default frontend reference become gtk? Regards, Brian. -- 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/20140819130344.ga7...@copernicus.demon.co.uk
Bug#742485: debian-installer: debian-testing-amd64-gnome-CD1.iso installs XFCE
Package: debian-installer Followup-For: Bug #742485 Dear Maintainer, I tested installing from debian-testing-amd64-CD-1.iso obtained at http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/, expecting the Gnome desktop to be installed. This image was dated 2014-08-18 08:52, MD5 sum was: f8003d7bad1724027efc41e629673eb1 Instead XFCE was installed. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20140819150717.1542.69769.report...@home.lan
Bug#742485: debian-installer: debian-testing-amd64-gnome-CD1.iso installs XFCE
On Tue, Aug 19, 2014 at 10:07:17AM -0500, Fabian Rodriguez wrote: Package: debian-installer Followup-For: Bug #742485 Dear Maintainer, I tested installing from debian-testing-amd64-CD-1.iso obtained at http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/, expecting the Gnome desktop to be installed. This image was dated 2014-08-18 08:52, MD5 sum was: f8003d7bad1724027efc41e629673eb1 Instead XFCE was installed. That's entirely as expected. debian-testing-amd64-CD-1.iso will install the default desktop, which at the moment is XFCE. If you want Gnome, grab debian-testing-amd64-gnome-CD-1.iso instead. -- Steve McIntyre, Cambridge, UK.st...@einval.com I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop -- Vivek Dasmohapatra -- 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/20140819151315.gh7...@einval.com
Bug#742485: debian-installer: debian-testing-amd64-gnome-CD1.iso installs XFCE
Hi Fabian, Fabian Rodriguez magic...@member.fsf.org (2014-08-19): Package: debian-installer Followup-For: Bug #742485 Dear Maintainer, I tested installing from debian-testing-amd64-CD-1.iso obtained at http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/, expecting the Gnome desktop to be installed. This image was dated 2014-08-18 08:52, MD5 sum was: f8003d7bad1724027efc41e629673eb1 Instead XFCE was installed. possibly the setup for the weekly builds wasn't updated with the patches used for Jessie Beta 1? Using beta images at this point would probably be a better idea than weekly builds anyway. Mraw, KiBi. signature.asc Description: Digital signature
Bug#742485: debian-installer: debian-testing-amd64-gnome-CD1.iso installs XFCE
Cyril Brulebois k...@debian.org (2014-08-19): Hi Fabian, Fabian Rodriguez magic...@member.fsf.org (2014-08-19): Package: debian-installer Followup-For: Bug #742485 Dear Maintainer, I tested installing from debian-testing-amd64-CD-1.iso obtained at http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/, expecting the Gnome desktop to be installed. This image was dated 2014-08-18 08:52, MD5 sum was: f8003d7bad1724027efc41e629673eb1 Instead XFCE was installed. possibly the setup for the weekly builds wasn't updated with the patches used for Jessie Beta 1? Using beta images at this point would probably be a better idea than weekly builds anyway. Also, what Steve said. Having different things in your mail subject and mail body is a bit confusing… Mraw, KiBi. signature.asc Description: Digital signature
Bug#485586: debian-installer: Default to graphical install
Hi, Brian Potkin claremont...@gmail.com wrote: On Mon 18 Aug 2014 at 23:07:11 +0200, Holger Wansing wrote: 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. Defaulting to a graphical (gtk) frontend on i386 and amd64 would mean that it becomes the regular frontend, unless it is desired to credit the newt frontend with some special status. From a global point of view, the graphical frontend is still something special, an exceptional case, since it's only available on 2 archs out of 8 in Jessie. So I would leave the text installer on 'regular' status IMO. In the context of Section 5.3.2. there is a difference between the text and newt frontends. But for many users the distinction is lost and the present regular frontend as presented in the user interface is a text one. 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). Section 6.1 uses character-based instead of text. It would be nice to have some consistency in referring to the alternative to the default graphical installation. Ok, I could take that into account. But not in the first step. At first I want (where possible) to move the paragraphs around without changing the content, to avoid unnecessary work for translators. There will be further changings needed later IMO, though (when Cyril shakes the order of boot entries around, for example :-) ). 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. I'd restructure that to draw attention to the default highlighting and to have it read better. For a normal installation, select either the “Install” or the “Graphical install” entry — using either the arrow keys on your keyboard or by typing the first (highlighted) letter — and press Enter to boot the installer. The entry Graphical install is already selected by default. Yes, that's sounds better. But I would implement that later on in a second step, see above. +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. Replace regular with text? As stated above, I personally would leave it at regular. I'm unsure whether a reference to the X Window System is useful, even for those who know what it is. For users who have worked with Debian in the past already, it would not hurt to leave that hint in place. And novice users don't get irritated too much by this IMO. In Section 6,1 the paragraph beginning For this architecture the would need the default user interface and the link altering. There are also a few other links in the manual to Sections D.6. and D.6.1.. In Section 5.3.2. should the default frontend reference become gtk? Not for all archs, so that would at least have to be conditioned. Will look into it. Thanks! Holger -- Holger Wansing hwans...@mailbox.org -- 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/20140819173918.caeb041c498457df16a98...@mailbox.org
Re: Use dedicated partition for /boot/grub instead of /boot
On Tue, Aug 19, 2014 at 09:45:03PM +0900, Joel Rees wrote: 2014/08/18 14:57 Christopher Chavez 2000...@gmail.com: 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? I guess it depends on what you mean by easy access. If you mean, to keep the kernel where it can be easily found by the boot manager, yeah, that's one of the big reasons. Old systems used to have a strong restriction on which part of the hard drive could be read by the initial firmware bootloader. The exact boundary changed from time to time, as the dcades wore on, but there was such a restriction often enough that some measure wsas needed so that the initial boot would sastisfy this restriction. The easy way to manage this was to have a separte partition for the these files, and place it near the start of the hard drive. Hence /boot was born. It's probably wise to keep /boot for this purpose, since one of these years we're going to hit the next order-of-magitude restriction. But just what files are subject to such a restriction, and what the file format of that partition should be probably depende on the firmware-level bootloader. At the moment, /boot and the EFI partition seem to have boot-time restrictions, either because of firmware or bootloader restrictions. -- hendrik That information used to be a lot more available, until some IPidiots started trying to claim rights to it. IPidiots? Can I have more details or a reference on these IPidiots? -- 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/20140819172902.ga29...@topoi.pooq.com
Re: Bug#485586: debian-installer: Default to graphical install
Didier 'OdyX' Raboud wrote: 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. This used to be the case via the default64 option patched into syslinux, but then #505243 complicated it and #505496 saw the default64 option removed from syslinux. It would certainly be worth fixing this reversion in the multiarch CD. -- see shy jo signature.asc Description: Digital signature
Bug#640789: Crash on folder name with spaces
Hi KiBi,
On Mon, Jul 07, 2014 at 03:56:21AM +0200, Cyril Brulebois wrote:
Modestas Vainius mo...@debian.org (2013-12-29):
thanks for the patch but I'm not convinced, see below:
--- a/debian/iso-scan.postinst
+++ b/debian/iso-scan.postinst
@@ -162,7 +162,7 @@ scan_device_for_isos() {
elif [ $look_subdirs = 1 ]; then
opt=-type f
fi
- isolist=$(find $dir $opt -name *.iso -o -name *.ISO
2/dev/null)
+ isolist=$(find $dir $opt -name *.iso -o -name
*.ISO 2/dev/null)
This part is certainly OK; at least I can't think of a reason why that
wouldn't be a good thing.
TOPLEVEL_DIRS_COUNT=$(($TOPLEVEL_DIRS_COUNT + 1))
for iso in $isolist; do
but then that means we're possibly going to fail here. Example:
[snip]
I guess it would make sense to fix this for real instead of hiding it a
bit further. Unfortunately 4am isn't a great time to set up a reproducer
and to keep on hacking. :/
There are in effect two bugs here. The first, which the patch fixes,
is that any folder with spaces in its name will cause iso-scan's
postinst to fail, preventing the installation. The second, which the
patch doesn't fix, is that any ISO found in a folder with spaces in
its name won't be handled correctly.
The first bug is extremely confusing, since an otherwise OK USB key
with all the appropriate files in the right place will fail to
install, with no explicit error message, and worse than that with a
message on the fourth terminal indicating that the ISO was found and
is usable...
The second bug, which is mitigated in part by the existence test (line
170), will only prevent certain ISOs from being used, and won't abort
the installation.
Wouldn't it be acceptable to apply the patch, and add an erratum
indicating that ISOs shouldn't be placed in folders containing spaces
in their names?
Regards,
Stephen
signature.asc
Description: Digital signature
Bug#640789: Crash on folder name with spaces
Hi Stephen ,
Stephen Kitt sk...@debian.org (2014-08-19):
On Mon, Jul 07, 2014 at 03:56:21AM +0200, Cyril Brulebois wrote:
Modestas Vainius mo...@debian.org (2013-12-29):
thanks for the patch but I'm not convinced, see below:
--- a/debian/iso-scan.postinst
+++ b/debian/iso-scan.postinst
@@ -162,7 +162,7 @@ scan_device_for_isos() {
elif [ $look_subdirs = 1 ]; then
opt=-type f
fi
- isolist=$(find $dir $opt -name *.iso -o -name *.ISO
2/dev/null)
+ isolist=$(find $dir $opt -name *.iso -o -name
*.ISO 2/dev/null)
This part is certainly OK; at least I can't think of a reason why that
wouldn't be a good thing.
TOPLEVEL_DIRS_COUNT=$(($TOPLEVEL_DIRS_COUNT + 1))
for iso in $isolist; do
but then that means we're possibly going to fail here. Example:
[snip]
I guess it would make sense to fix this for real instead of hiding it a
bit further. Unfortunately 4am isn't a great time to set up a reproducer
and to keep on hacking. :/
There are in effect two bugs here. The first, which the patch fixes,
is that any folder with spaces in its name will cause iso-scan's
postinst to fail, preventing the installation. The second, which the
patch doesn't fix, is that any ISO found in a folder with spaces in
its name won't be handled correctly.
The first bug is extremely confusing, since an otherwise OK USB key
with all the appropriate files in the right place will fail to
install, with no explicit error message, and worse than that with a
message on the fourth terminal indicating that the ISO was found and
is usable...
The second bug, which is mitigated in part by the existence test (line
170), will only prevent certain ISOs from being used, and won't abort
the installation.
Wouldn't it be acceptable to apply the patch, and add an erratum
indicating that ISOs shouldn't be placed in folders containing spaces
in their names?
Thanks for your analysis. If the consequences are those you mention I
agree that fixing the first bug right away (backporting as needed) is
desirable.
I'll probably clone this bug report for the second one, and deal with
the first one in a moment.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Bug#485586: debian-installer: Default to graphical install
On Tue 19 Aug 2014 at 17:39:18 +0200, Holger Wansing wrote: Brian Potkin claremont...@gmail.com wrote: Defaulting to a graphical (gtk) frontend on i386 and amd64 would mean that it becomes the regular frontend, unless it is desired to credit the newt frontend with some special status. From a global point of view, the graphical frontend is still something special, an exceptional case, since it's only available on 2 archs out of 8 in Jessie. So I would leave the text installer on 'regular' status IMO. That thought went through my mind too but I discounted it because it seemed we were looking at i386 and amd64 documentation. If -user had a question about the regular/normal/usual/default user interface for Jessie I would say it is definitely the graphical one. However, since you are doing the work it is your call. :) (I wonder whether using Debian makes either of us regular guys?). I'm unsure whether a reference to the X Window System is useful, even for those who know what it is. For users who have worked with Debian in the past already, it would not hurt to leave that hint in place. And novice users don't get irritated too much by this IMO. It was an aside. I'm sure you are correct. Thank you for considering. Regards, Brian -- 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/19082014201811.def77e25f...@desktop.copernicus.demon.co.uk
Bug#485586: debian-installer: Default to graphical install
Holger Wansing hwans...@mailbox.org (2014-08-19): Hi, Brian Potkin claremont...@gmail.com wrote: On Mon 18 Aug 2014 at 23:07:11 +0200, Holger Wansing wrote: 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. Defaulting to a graphical (gtk) frontend on i386 and amd64 would mean that it becomes the regular frontend, unless it is desired to credit the newt frontend with some special status. From a global point of view, the graphical frontend is still something special, an exceptional case, since it's only available on 2 archs out of 8 in Jessie. So I would leave the text installer on 'regular' status IMO. Well, amd64+i386 is probably close to almost all installations… Mraw, KiBi. signature.asc Description: Digital signature
Re: Plan of action for Secure Boot support
On Thu, 2014-08-14 at 23:38 +0200, Cyril Brulebois wrote: [...] 1. Colin Watson will prepare dak changes to support upload and subsequent signing of EFI executables. (This is an embedded, not detached, signature.) 2. Steve Langasek will prepare and upload a package of the 'shim' EFI boot loader. This will embed our own set of public keys (corresponding to those used by dak) and can load any other EFI executable signed by one of them. Later, there will be a shim-signed package containing the same executable with a Microsoft signature. (This costs money and takes several days, but shim should require only very infrequent changes.) 3. Colin Watson will update the GRUB package to build a to-be-signed monolithic EFI executable separate from the package. Then he will add a grub-signed package that includes the Debian-signed executable from the archive. This executable would be suitable for use on both removable media and the installed system. 4. The kernel team may also need to upload kernel images for signing and add linux-image-signed packages with the Debian-signed kernel images. This is because some quirks in the kernel should be run before calling ExitBootServices(). could you please tell us whether anything changed during the past year? Is there any chance we could think of having SB in jessie, or should we consider it an unreasonable goal for this release and concentrate on other things? So far as I know, no progress has been made on the above steps or any alternate approach. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#485586: debian-installer: Default to graphical install
Hi, Cyril Brulebois k...@debian.org wrote: Holger Wansing hwans...@mailbox.org (2014-08-19): Hi, Brian Potkin claremont...@gmail.com wrote: On Mon 18 Aug 2014 at 23:07:11 +0200, Holger Wansing wrote: 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. Defaulting to a graphical (gtk) frontend on i386 and amd64 would mean that it becomes the regular frontend, unless it is desired to credit the newt frontend with some special status. From a global point of view, the graphical frontend is still something special, an exceptional case, since it's only available on 2 archs out of 8 in Jessie. So I would leave the text installer on 'regular' status IMO. Well, amd64+i386 is probably close to almost all installations… Hmm, we should change regular installer - text installer then and don't use regular installer anymore, as proposed by Brian? Might lead to several changes and several outdated translations... Holger -- Holger Wansing hwans...@mailbox.org -- 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/20140819224928.ec400790939e8cfedb840...@mailbox.org
Re: Plan of action for Secure Boot support
On Tue, Aug 19, 2014 at 01:38:44PM -0700, Ben Hutchings wrote: So far as I know, no progress has been made on the above steps or any alternate approach. Ditto, I've not seen (or done) anything about this. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- 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/20140819211641.gi7...@einval.com
Re: Bug#485586: debian-installer: Default to graphical install
On Tue, Aug 19, 2014 at 02:02:17PM -0400, Joey Hess wrote: Didier 'OdyX' Raboud wrote: 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. This used to be the case via the default64 option patched into syslinux, but then #505243 complicated it and #505496 saw the default64 option removed from syslinux. It would certainly be worth fixing this reversion in the multiarch CD. Definitely - we're already tracking this in #752133 -- Steve McIntyre, Cambridge, UK.st...@einval.com I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. -- Linus Torvalds -- 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/20140819211952.gj7...@einval.com
Bug#485586: debian-installer: Default to graphical install
On Tue, Aug 19, 2014 at 01:17:02AM +0200, Cyril Brulebois wrote: [ 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? I'm more tempted to have: #if (amd64) via syslinux 64 bit Graphical install 64 bit Text install #endif 32 bit Graphical install 32 bit Text install Advanced options Help #if (amd64) via syslinux Install with speech synthesis (64 bit) #endif Install with speech synthesis (32 bit) or do we split things even more? That menu is already too long, and causes scrolling for people to see the lower options (if they realise such a thing is possible!). How about we split things up some more, assuming we can get the auto-detect to work: #if (amd64) via syslinux 64 bit Graphical install 64 bit Text install 32 bit install options Advanced options Help Install with speech synthesis (64 bit) #else 32 bit Graphical install 32 bit Text install Install with speech synthesis (32 bit) #endif It'll need some extra work to deal with different paths through for i386 and amd64 here, but meh. It's possibly worth separating them totally, and make sure each path is clear in terms of which arch. On the multi-arch CD and DVD, the deeper advanced options menus are a bit too spread I think, so splitting at the top level would be a good plan for simplicity maybe? 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? Definitely - see above! 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? Definitely - see above! -- Steve McIntyre, Cambridge, UK.st...@einval.com Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast. Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.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/20140819214516.gk7...@einval.com
Bug#485586: debian-installer: Default to graphical install
Steve McIntyre st...@einval.com (2014-08-19): or do we split things even more? That menu is already too long, and causes scrolling for people to see the lower options (if they realise such a thing is possible!). How about we split things up some more, assuming we can get the auto-detect to work: #if (amd64) via syslinux 64 bit Graphical install 64 bit Text install 32 bit install options Advanced options Help Install with speech synthesis (64 bit) #else 32 bit Graphical install 32 bit Text install Install with speech synthesis (32 bit) #endif That looks very nice (except the missing Advanced options in the #else part). It'll need some extra work to deal with different paths through for i386 and amd64 here, but meh. It's possibly worth separating them totally, and make sure each path is clear in terms of which arch. On the multi-arch CD and DVD, the deeper advanced options menus are a bit too spread I think, so splitting at the top level would be a good plan for simplicity maybe? Having the per-arch code to detangle the mess looks like a nice idea, thanks. That means Didier (or someone else) will have to get it to work as a first step. I'd prefer if we made the switch for all images at a single time (even if that happens through several commits), so that we only have a single documentation update. As Holger mentioned, it's going to have *some* impacts in various areas; I'd rather avoid too many steps if at all possible. (And of course: Thanks for your input.) Mraw, KiBi. signature.asc Description: Digital signature
Bug#485586: debian-installer: Default to graphical install
On Tue, Aug 19, 2014 at 11:58:27PM +0200, Cyril Brulebois wrote: Steve McIntyre st...@einval.com (2014-08-19): or do we split things even more? That menu is already too long, and causes scrolling for people to see the lower options (if they realise such a thing is possible!). How about we split things up some more, assuming we can get the auto-detect to work: #if (amd64) via syslinux 64 bit Graphical install 64 bit Text install 32 bit install options Advanced options Help Install with speech synthesis (64 bit) #else 32 bit Graphical install 32 bit Text install Install with speech synthesis (32 bit) #endif That looks very nice (except the missing Advanced options in the #else part). Doh, yes! It'll need some extra work to deal with different paths through for i386 and amd64 here, but meh. It's possibly worth separating them totally, and make sure each path is clear in terms of which arch. On the multi-arch CD and DVD, the deeper advanced options menus are a bit too spread I think, so splitting at the top level would be a good plan for simplicity maybe? Having the per-arch code to detangle the mess looks like a nice idea, thanks. That means Didier (or someone else) will have to get it to work as a first step. I'd prefer if we made the switch for all images at a single time (even if that happens through several commits), so that we only have a single documentation update. As Holger mentioned, it's going to have *some* impacts in various areas; I'd rather avoid too many steps if at all possible. Of course, Oh, and after I've thought about this a little more - I believe it will make the amd64 UEFI menus in grub slightly easier to make, as well. They're post-processed from the syslinux menus in debian-cd via a horrid perl script... -- Steve McIntyre, Cambridge, UK.st...@einval.com This dress doesn't reverse. -- Alden Spiess -- 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/20140819220240.gm7...@einval.com
Bug#757985: kfreebsd-* release status?
On 19/08/14 00:40, Cyril Brulebois wrote: [ 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. ] I was drafting a quite long reply to this, but after 15 minutes, I realised whatever precious time we have, needs to be spent fixing the bugs, not discussing this. So I'll reply to each of the bugs individually. In short, yes I think kfreebsd does have high workload right now; we could use more help as the freeze approaches, but I'm not worried. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#757711: Bug#757988: kfreebsd: troubles with dhcp (configuration going away)
On 14/08/14 18:32, Cyril Brulebois wrote: Now, I think there are several questions to answer: 1. What were the reasons for having arch-dependent dhcp clients? I'd speculate because udhcpc from busybox is very small, and isc-dhcp-client-udeb was about 2 MiB. It targets (currently only builds on) Linux; there is a bug open somewhere about porting it to kfreebsd; it's infeasible before the jessie freeze, and IMHO I think I prefer to keep the ISC version (mostly from a security POV). 2. Are those reasons still valid? Having the same across all arches sounds nice, but I don't think I have time to get into this right now; there are more urgent kfreebsd issues I must focus my attention on, sorry. I still think my patch is the best resolution for this bug, but Philipp mentioned rdnssd, which is currently being killed by netcfg as well. Someone may want to look into that. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#757711: Bug#757988: kfreebsd: troubles with dhcp (configuration going away)
Steven Chamberlain ste...@pyro.eu.org (2014-08-20): On 14/08/14 18:32, Cyril Brulebois wrote: Now, I think there are several questions to answer: 1. What were the reasons for having arch-dependent dhcp clients? I'd speculate because udhcpc from busybox is very small, and isc-dhcp-client-udeb was about 2 MiB. It targets (currently only builds on) Linux; there is a bug open somewhere about porting it to kfreebsd; it's infeasible before the jessie freeze, and IMHO I think I prefer to keep the ISC version (mostly from a security POV). 2MiB looks like a candidate for huge savings, which might make some sense since we're repeatedly hitting ENOSPC with kfreebsd-*, don't you think? Not trying to impose any decision, just a bit shocked while discovering its size. Mraw, KiBi. signature.asc Description: Digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
On 14/08/14 18:15, Cyril Brulebois wrote: [...] 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. The fixed-size d-i initrds had to be carefully sized for kfreebsd wheezy. We discussed about a year ago the possibility of adding a variable-sized ramdisk to avoid ENOSPC, for anna/cdebconf in particular. It may affect our minimum RAM requirements. And/or we could maybe lose some unnecessary udebs. I mentioned partman-iscsi as an example to start with (I also didn't understand how/why that was being included in the image at all?) but there are probably other and larger candidates. This has a higher priority than the other issues. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Steven Chamberlain ste...@pyro.eu.org (2014-08-20): On 14/08/14 18:15, Cyril Brulebois wrote: [...] 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. The fixed-size d-i initrds had to be carefully sized for kfreebsd wheezy. That this was the case for wheezy already isn't an excuse. I really don't think it's viable to play the let's save a byte here or there game. Even if that were the case, someone has to care, and commit to actually ensuring that constraints are met, and that d-i works. Look, I don't like releasing broken things. Especially when it looks to me I'm the only user, and not even a real one, just a beta tester. We discussed about a year ago the possibility of adding a variable-sized ramdisk to avoid ENOSPC, for anna/cdebconf in particular. It may affect our minimum RAM requirements. Is that a viable option for jessie? And/or we could maybe lose some unnecessary udebs. I mentioned partman-iscsi as an example to start with (I also didn't understand how/why that was being included in the image at all?) but there are probably other and larger candidates. If you're trying to insinuate I/we deliberately broke kfreebsd-* by introducing partman-iscsi, rest assured that: no. Can we please figure out a way to unbreak kfreebsd *most of the time* and stop caring about this single package? Extra udebs are sometimes added. That shouldn't be the end of the world for release architectures. And when breakages happen, there really should be someone to detect them, and deal with them. Mraw, KiBi. signature.asc Description: Digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
On 20/08/14 01:49, Cyril Brulebois wrote: If you're trying to insinuate I/we deliberately broke kfreebsd-* by introducing partman-iscsi, [...] No, I was not insinuating that. But I am still asking: how is it that partman-iscsi is being installed into a kfreebsd d-i image (by APT I believe)? I'd expect it to be uninstallable due to missing dependencies. Could that be a bug, or is it a known limitation? Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Steven Chamberlain ste...@pyro.eu.org (2014-08-20): On 20/08/14 01:49, Cyril Brulebois wrote: If you're trying to insinuate I/we deliberately broke kfreebsd-* by introducing partman-iscsi, [...] No, I was not insinuating that. But I am still asking: how is it that partman-iscsi is being installed into a kfreebsd d-i image (by APT I believe)? I'd expect it to be uninstallable due to missing dependencies. Could that be a bug, or is it a known limitation? Feel free to use another bug report to investigate/track that. I'd really appreciate if we could concentrate on the other points of my mail, instead of deflecting on this point of detail. Mraw, KiBi. signature.asc Description: Digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Steven Chamberlain ste...@pyro.eu.org (2014-08-20): But I am still asking: how is it that partman-iscsi is being installed into a kfreebsd d-i image (by APT I believe)? I'd expect it to be uninstallable due to missing dependencies. Could that be a bug, or is it a known limitation? Thanks. I've meanwhile found the answer to this. It's actually not being installed in the images, but is installed later by anna. I think all we need to do is add the expected-uninstallable packages to /var/cache/anna/exclude (perhaps referring to http://d-i.debian.org/edos/#unstable for packages we probably want to exclude) On 20/08/14 02:50, Cyril Brulebois wrote: I'd really appreciate if we could concentrate on the other points of my mail, instead of deflecting on this point of detail. But it *is* also relevant here. Each udeb in our image takes up space for the extracted files, but also I suspect _considerable_ space in cdebconf data. Addressing this may already fix the ENOSPC error, and if we can keep the anna excludes up-to-date, we could avoid some unwanted udebs (meant for Linux) appearing in the future. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
Steven Chamberlain ste...@pyro.eu.org (2014-08-20): But it *is* also relevant here. Each udeb in our image takes up space for the extracted files, but also I suspect _considerable_ space in cdebconf data. Addressing this may already fix the ENOSPC error, and if we can keep the anna excludes up-to-date, we could avoid some unwanted udebs (meant for Linux) appearing in the future. I did *not* say it wasn't relevant… Now, to be more precise, getting back one of my main points, which you didn't quote, or replied to: | That this was the case for wheezy already isn't an excuse. | | I really don't think it's viable to play the let's save a byte here or | there game. Even if that were the case, someone has to care, and commit | to actually ensuring that constraints are met, and that d-i works. | | Look, I don't like releasing broken things. Especially when it looks | to me I'm the only user, and not even a real one, just a beta tester. Who among the kfreebsd porters is going to make sure that d-i gets in to a somewhat reasonable shape, and going to keep it that way, so that we avoid the current mess? KiBi. signature.asc Description: Digital signature
Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded
I've finished testing these hypotheses: On 20/08/14 03:14, Steven Chamberlain wrote: I think all we need to do is add the expected-uninstallable packages to /var/cache/anna/exclude That works. I think on each architecture, any uninstallable udeb (according to http://d-i.debian.org/edos/#unstable) belongs in the anna excludes file. Maybe it could be automated, perhaps determined at debian-installer build time. [...] Each udeb in our image takes up space for the extracted files, but also I suspect _considerable_ space in cdebconf data. Addressing this may already fix the ENOSPC error, [...] Skipping 21 surplus udebs was not enough. The biggest problem is indeed cdebconf templates: | /var/lib/cdebconf # ls -alS | -rw-r--r--1 root root 10886119 Aug 20 02:28 templates.dat | -rw-r--r--1 root root 10886119 Aug 20 02:27 templates.dat-old I wonder if -old is really needed in d-i? There is also a temporary templates.dat-new while it is processing. So at its peak, this directory accounts for some 30MiB or more in the d-i filesystem (in memory). That's half as big as the whole rest of d-i. I'm surprised this hasn't caused a problem yet on non-kfreebsd architectures -- a machine with only just enough memory to support graphical mode (instead of falling back to lowmem install mode where I think cdebconf localisation is disabled?). Anyway, I also tried using a tmpfs for /var/lib/cdebconf. That works very well, and seems like the best way we can fix this bug. It also helped slightly to mount a tmpfs on /var/cache/anna, where udebs are downloaded to one-at-a-time, before each is extracted then deleted. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#757711: Bug#757988: kfreebsd: troubles with dhcp (configuration going away)
On Tue, Aug 19, 2014 at 8:10 PM, Cyril Brulebois wrote: Steven Chamberlain ste...@pyro.eu.org (2014-08-20): On 14/08/14 18:32, Cyril Brulebois wrote: Now, I think there are several questions to answer: 1. What were the reasons for having arch-dependent dhcp clients? I'd speculate because udhcpc from busybox is very small, and isc-dhcp-client-udeb was about 2 MiB. It targets (currently only builds on) Linux; there is a bug open somewhere about porting it to kfreebsd; it's infeasible before the jessie freeze, and IMHO I think I prefer to keep the ISC version (mostly from a security POV). 2MiB looks like a candidate for huge savings, which might make some sense since we're repeatedly hitting ENOSPC with kfreebsd-*, don't you think? Not trying to impose any decision, just a bit shocked while discovering its size. dhclient in the udeb is around 1.7 MiB because of embedded bind, which was introduced in isc-dhcp 4.2. I plan to spend some time to switch that to dynamically link, which will reduce size since only the parts of bind actually used will be needed rather than the whole thing. Best wishes, Mike -- 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/CANTw=monxvufootejlzc2n0p16uvu8xy+lt1mi1sgnu-nqm...@mail.gmail.com
