Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On 2023.05.08 21:02, Lennart Sorensen wrote: Well devicetree is part of open firmware aka IEEE-1275, from 1994. ACPI is from 1996. Interesting; TIL. I guess I'm probably not the only person who thought DT was something that was only cooked recently by Linux kernel maintainers, since that's when it became mainstream for the majority of the x86/PC based end-user crowd. And of course since I don't think Sun cared at all what Microsoft thought when they designed the firmware interface, I don't think that matters. Since open firmware or at least devicetree has then ended up used on SPARC, PowerPC, ARM, MIPS, and who knows what else, while ACPI is x86 and now some ARM but nothing else as far as I can tell, other than in terms of overall units using it, ACPI certainly has a lot less interest. Well, the thing is overall units tends to correlate pretty closely to overall end-users. And, while one may try to plan for what one expects/hopes the end-user landscape to shift towards, one must still strive to create software that makes life easier for the current one. In terms of units, ACPI has certainly been more widespread, even if it's mostly due to the homogeneity of the dominant arch and platform (x86 based PC). Apple is almost certainly back to devicetree on their arm devices since they used it on their powerpc based systems already in the past. If that's the case, then (I'm going to assume that) it's shame Apple didn't use their position to join the discussion and provide some opposition to Microsoft, when it came to going with ACPI-only for SBBR... Well unfortunately for years it seems the status quo has also been 64 bit arm servers being annonced, but not able to be purchased anywhere I'd venture to say that there's been a bit of a chicken and egg problem there, which SBBR is in part trying to solve, by attempting to remove one of the hurdle people face when getting an ARM64 server, i.e. how the heck am I going to install my OS/distro of choice on this machine, instead of being constrained by whatever custom version of some other OS/distro the manufacturer of the platform decided to go with. I do agree that we're still early in the game here, if game there eventually is, which is the *precise* reason why a group of us worked together to provide an SBBR implementation on the commonplace and relatively limited Pi platforms, i.e. something that is everything but an ARM server, to both provide an easy to access working implementation as well as demonstrate to ARM64 system manufacturers that, if this can be accomplished for the Pi with limited effort, this should certainly be achievable for their platform. Well supported across architectures: yes. Well supported across OSes: Unfortunately no, when you do consider Windows. Any OS that ever ran on an openfirmware system, which is a lot of them. Again, I'd prefer to go with number end-users as a better measure, since we're not developing for the greater variety but for is likely to benefit the greater masses. Of course, if ARM64 system manufacturers collectively decide they want to ignore Windows and SBBR, and go with openfirmware, I'll be more than happy to let Microsoft add openfirmware compatibility to Windows on ARM, as long as the end-users stop having to jump through system-specific hoops to install the OS they want. It seems that it benefits only one OS, the one it seems just about no one cares to run on arm systems. I'm going to go further than that and say that not even Microsoft appears/appeared to care that much about running Windows on ARM systems, as we pretty much offered them a golden opportunity to chase a goal they should be exceedingly familiar with, and, what's more, one that Apple will never challenge them on, namely running their OS on *cheap* commonplace hardware. But they pretty much ignored the crowd that was interested in running Windows on the Pi, even as Windows 11 21H2 does run very decently on an 8 GB Pi 4 and, current hardware price hike notwithstanding, could have gained significant traction with the low income masses. This, in turn, could have provided Microsoft with a means to bring (or should I say lock-in) those masses into the Windows ecosystem. But instead, it appears they looked at what Apple was doing with controlling both the hardware and software through an expensive platform, and decided they wanted a piece of that pie, which I doubt will benefit them much in terms of trying to keep Windows as the dominant OS. Now, as an aside, since the above may make it look like I'm trying to advocate for Microsoft and we're on a GNU/Linux mailing list after all, please bear in mind that, even as I am primarily a Windows developer these days, I am far from rooting for Microsoft or any proprietary software company for that matter. In fact, the main software I develop on Windows is also designed to allow people break away from the abomination that is
installation-guide_20230508_source.changes ACCEPTED into unstable
Thank you for your contribution to Debian. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 08 May 2023 22:47:33 +0200 Source: installation-guide Architecture: source Version: 20230508 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Samuel Thibault Closes: 1032940 1033524 1033535 Changes: installation-guide (20230508) unstable; urgency=medium . [ Samuel Thibault ] * Update figures. Update text about root vs /usr, as the latter is now systematically in root. . [ Holger Wansing ] * Document minimal required harddisc space as 4 gigabytes instead of 2 gigabytes. (Closes: #1032940) * Update chapter for preparing installation media. (Closes: #1033524) * simplify instructions for making bootable USB media * remove mentions of mini.iso image * remove mentions of loadlin * Remove chapter about booting the installer from Windows. Support for win32-loader has been removed from the installer. . [ Chris Hofstaedtler ] * Remove dmraid (sata raid) from the doc; src:dmraid has dropped its udebs, and the experimental support from the installer was also removed. Closes: #1033535. . [ New translations ] * Romanian by Remus-Gabriel Chelu, many thanks! . [ Updated translations ] * Catalan by d * Greek by galaxico * Spanish by gallegonovato * French by Baptiste Jammet * German by Holger Wansing * Indonesian by Andika Triwidada * Italian by Luca Monducci * Korean by Changwoo Ryu * Dutch by Frans Spiesschaert * Portuguese by Miguel Figueiredo * Chinese (simplified) by Wenbin Lv Checksums-Sha1: b5b910828e137da03f4609dce668375c4226408b 2843 installation-guide_20230508.dsc 41cf5c25d1ad36296b1a4f8eea4149bd77afb7cd 3980032 installation-guide_20230508.tar.xz 47304cfaa85216d01fa634ff225cc99a78d19e88 6903 installation-guide_20230508_source.buildinfo Checksums-Sha256: cbfc1e0ab001a4976af5fe99a648751b761eca3628b83b29544f10e4989c71ab 2843 installation-guide_20230508.dsc 7e9c04d87a5fb1dc00a39e192176cf054be58087b2d13c8a949de0bd574c975a 3980032 installation-guide_20230508.tar.xz 633292bd4fec5b9319a68bc45b6461276c5e65a247f2dee0092ceb9b84b0e545 6903 installation-guide_20230508_source.buildinfo Files: d8b942477be00f5ae811a3fbf436e777 2843 doc optional installation-guide_20230508.dsc e955e5d2d92d36fd625999a26f95a542 3980032 doc optional installation-guide_20230508.tar.xz 0dd2a2f2a8977dfa24ff687f2d225be1 6903 doc optional installation-guide_20230508_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi6MnFvk67auaclLJ5pG0tXV4H2IFAmRZZNEACgkQ5pG0tXV4 H2I0fA/+LlqAq5F8QpEhWRvBusTlj+RKR5HazuyYpALURgnFqOtLriz89GOoaOVm yQRzevVOb4wKxVHF7U+PGtWTh1Q7snj2KZWfnP/zROmKMCOeT3Qvm4Zv3hx9UpBa hEy7uWZAH6ISjQgqEnzj/00qICspKVVHeiKapLLcW52R7HgSeHCHwJGyUZDje+Pj VLzPUdzjybAXV9Vz/Ds2EkAqiCy+bd1nw3g2lnFAQ0vDEhjCgwLcyHC8bQR/q+Sy HgsX0ilVkmf5spwFT8BwMN0zQuB6Y66vG0VjazEhckHrJOP2DDmMzaqPfHWAarFh SuYJrjx1vewKogUGHQRjP9oUJxwnv9zyU6ugZlUvS1AtyBQ+3NTXTwkHwPiOCO6R S3KWgRwkzkdiCJ7edF8HST3zDv9uP3dyhmhzPYJ9ZkH8PmOC9Ed8guF91gDOWnNy I8oylT3fx8GSHQU8WJ6fSAbVqHg3enIi5SbyojF2xM5eICK8Ft7UwsgjymgiL4wl U4TQLSWnVCxTgHLZBK/uQn2JQGGzOTZviHZg6f7/lx2+vHjPFJOk77VPTlkBengS lP6zlm/E71hzW4fFWcl9qKlgh7To/9e2536+fc95j6uG/A+ON9oTh6yIrEv7/jdu 5+yad4iX8i5T5jANYHSQ1+7ilnEOC74pE0A/lVE1gnA1Hkd1YME= =7a6g -END PGP SIGNATURE-
Processing of installation-guide_20230508_source.changes
installation-guide_20230508_source.changes uploaded successfully to localhost along with the files: installation-guide_20230508.dsc installation-guide_20230508.tar.xz installation-guide_20230508_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#1033535: marked as done (installation-guide: Remove dmraid information)
Your message dated Mon, 08 May 2023 21:18:52 + with message-id and subject line Bug#1033535: fixed in installation-guide 20230508 has caused the Debian Bug report #1033535, regarding installation-guide: Remove dmraid information 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.) -- 1033535: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033535 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: installation-guide Version: dmraid support was removed Severity: normal Tags: patch Please remove information related to dmraid from the installation-guide. Installer support for dmraid was removed in #864423. MR: https://salsa.debian.org/zeha/installation-guide/-/merge_requests/2 Chris --- End Message --- --- Begin Message --- Source: installation-guide Source-Version: 20230508 Done: Samuel Thibault We believe that the bug you reported is fixed in the latest version of installation-guide, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1033...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Samuel Thibault (supplier of updated installation-guide package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 08 May 2023 22:47:33 +0200 Source: installation-guide Architecture: source Version: 20230508 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Samuel Thibault Closes: 1032940 1033524 1033535 Changes: installation-guide (20230508) unstable; urgency=medium . [ Samuel Thibault ] * Update figures. Update text about root vs /usr, as the latter is now systematically in root. . [ Holger Wansing ] * Document minimal required harddisc space as 4 gigabytes instead of 2 gigabytes. (Closes: #1032940) * Update chapter for preparing installation media. (Closes: #1033524) * simplify instructions for making bootable USB media * remove mentions of mini.iso image * remove mentions of loadlin * Remove chapter about booting the installer from Windows. Support for win32-loader has been removed from the installer. . [ Chris Hofstaedtler ] * Remove dmraid (sata raid) from the doc; src:dmraid has dropped its udebs, and the experimental support from the installer was also removed. Closes: #1033535. . [ New translations ] * Romanian by Remus-Gabriel Chelu, many thanks! . [ Updated translations ] * Catalan by d * Greek by galaxico * Spanish by gallegonovato * French by Baptiste Jammet * German by Holger Wansing * Indonesian by Andika Triwidada * Italian by Luca Monducci * Korean by Changwoo Ryu * Dutch by Frans Spiesschaert * Portuguese by Miguel Figueiredo * Chinese (simplified) by Wenbin Lv Checksums-Sha1: b5b910828e137da03f4609dce668375c4226408b 2843 installation-guide_20230508.dsc 41cf5c25d1ad36296b1a4f8eea4149bd77afb7cd 3980032 installation-guide_20230508.tar.xz 47304cfaa85216d01fa634ff225cc99a78d19e88 6903 installation-guide_20230508_source.buildinfo Checksums-Sha256: cbfc1e0ab001a4976af5fe99a648751b761eca3628b83b29544f10e4989c71ab 2843 installation-guide_20230508.dsc 7e9c04d87a5fb1dc00a39e192176cf054be58087b2d13c8a949de0bd574c975a 3980032 installation-guide_20230508.tar.xz 633292bd4fec5b9319a68bc45b6461276c5e65a247f2dee0092ceb9b84b0e545 6903 installation-guide_20230508_source.buildinfo Files: d8b942477be00f5ae811a3fbf436e777 2843 doc optional installation-guide_20230508.dsc e955e5d2d92d36fd625999a26f95a542 3980032 doc optional installation-guide_20230508.tar.xz 0dd2a2f2a8977dfa24ff687f2d225be1 6903 doc optional installation-guide_20230508_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEi6MnFvk67auaclLJ5pG0tXV4H2IFAmRZZNEACgkQ5pG0tXV4 H2I0fA/+LlqAq5F8QpEhWRvBusTlj+RKR5HazuyYpALURgnFqOtLriz89GOoaOVm yQRzevVOb4wKxVHF7U+PGtWTh1Q7snj2KZWfnP/zROmKMCOeT3Qvm4Zv3hx9UpBa hEy7uWZAH6ISjQgqEnzj/00qICspKVVHeiKapLLcW52R7HgSeHCHwJGyUZDje+Pj VLzPUdzjybAXV9Vz/Ds2EkAqiCy+bd1nw3g2lnFAQ0vDEhjCgwLcyHC8bQR/q+Sy HgsX0ilVkmf5spwFT8BwMN0zQuB6Y66vG0VjazEhckHrJOP2DDmMzaqPfHWAarFh SuYJrjx1vewKogUGHQRjP9oUJxwnv9zyU6ugZlUvS1AtyBQ+3NTXTwkHwPiOCO6R
Bug#1033524: marked as done (Simplify the instructions for making bootable media)
Your message dated Mon, 08 May 2023 21:18:52 + with message-id and subject line Bug#1033524: fixed in installation-guide 20230508 has caused the Debian Bug report #1033524, regarding Simplify the instructions for making bootable media 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.) -- 1033524: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033524 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: installation-guide Severity: important Almost all of section 4.3 (Preparing Files for USB Memory Stick Booting) needs to go away. We should *not* be telling most users about manually formatting media, copying installer files, etc. My strong preference would be to simply remove *everything* after the text "Simply writing the installation image to USB like this should work fine for most users." The rest of the text here is massively overblown for anybody except developers, and is causing confusion. If anybody *does* want to keep the rest of the text, please put it in an appendix called "extra USB options that nobody needs" or similar. We should also remove mentions of the mini.iso in the "normal users" section - it's totally not a sensible option for most people to ever be trying to use it here. We should definitely also kill section 4.4.2: Loadlin is *dead* - *nobody* has DOS any more. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- End Message --- --- Begin Message --- Source: installation-guide Source-Version: 20230508 Done: Samuel Thibault We believe that the bug you reported is fixed in the latest version of installation-guide, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1033...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Samuel Thibault (supplier of updated installation-guide package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 08 May 2023 22:47:33 +0200 Source: installation-guide Architecture: source Version: 20230508 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Samuel Thibault Closes: 1032940 1033524 1033535 Changes: installation-guide (20230508) unstable; urgency=medium . [ Samuel Thibault ] * Update figures. Update text about root vs /usr, as the latter is now systematically in root. . [ Holger Wansing ] * Document minimal required harddisc space as 4 gigabytes instead of 2 gigabytes. (Closes: #1032940) * Update chapter for preparing installation media. (Closes: #1033524) * simplify instructions for making bootable USB media * remove mentions of mini.iso image * remove mentions of loadlin * Remove chapter about booting the installer from Windows. Support for win32-loader has been removed from the installer. . [ Chris Hofstaedtler ] * Remove dmraid (sata raid) from the doc; src:dmraid has dropped its udebs, and the experimental support from the installer was also removed. Closes: #1033535. . [ New translations ] * Romanian by Remus-Gabriel Chelu, many thanks! . [ Updated translations ] * Catalan by d * Greek by galaxico * Spanish by gallegonovato * French by Baptiste Jammet * German by Holger Wansing * Indonesian by Andika Triwidada * Italian by Luca Monducci * Korean by Changwoo Ryu * Dutch by Frans Spiesschaert * Portuguese by Miguel Figueiredo * Chinese (simplified) by Wenbin Lv Checksums-Sha1: b5b910828e137da03f4609dce668375c4226408b 2843 installation-guide_20230508.dsc 41cf5c25d1ad36296b1a4f8eea4149bd77afb7cd 3980032 installation-guide_20230508.tar.xz 47304cfaa85216d01fa634ff225cc
Bug#1032940: marked as done (1,5 gig disk not accepted by installer)
Your message dated Mon, 08 May 2023 21:18:52 + with message-id and subject line Bug#1032940: fixed in installation-guide 20230508 has caused the Debian Bug report #1032940, regarding 1,5 gig disk not accepted by installer 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.) -- 1032940: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032940 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: installation-reports Severity: normal Tags: d-i (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) Boot method: CD image Image version: https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/debian-bookworm-DI-alpha2-amd64-netinst.iso download on 2023-03-14 Date: Machine: KVM VM Partitions: none, disk empty, parted saying "unrecognised disk label" Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O ] Detect network card:[O ] Configure network: [O ] Detect media: [O ] Load installer modules: [O ] Clock/timezone setup: [O ] User/password setup:[O ] Detect hard drives: [O ] Partition hard drives: [E ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: No formal installation report since the install didn't complete. An empty disk image of 1,5 Gigabytes in size is rejected by the Installer after the "Guided - use entire disk" choice and selecting vda with the message "Failed to partition the selected disk, this probably happened because the selected disk or free space is too small to be automatically partitioned." The release notes Chapter 2.5 "Memory and disk requirements" say that 920 MB of hard disk space should be enough. Either the release notes are wrong or the installer is wrongly detecting the disk too small or there is some by-condition that I missed (maybe the swap partition?). With a 2 GB partition, installation proceeds. Greetings Marc --- End Message --- --- Begin Message --- Source: installation-guide Source-Version: 20230508 Done: Samuel Thibault We believe that the bug you reported is fixed in the latest version of installation-guide, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1032...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Samuel Thibault (supplier of updated installation-guide package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 08 May 2023 22:47:33 +0200 Source: installation-guide Architecture: source Version: 20230508 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Samuel Thibault Closes: 1032940 1033524 1033535 Changes: installation-guide (20230508) unstable; urgency=medium . [ Samuel Thibault ] * Update figures. Update text about root vs /usr, as the latter is now systematically in root. . [ Holger Wansing ] * Document minimal required harddisc space as 4 gigabytes instead of 2 gigabytes. (Closes: #1032940) * Update chapter for preparing installation media. (Closes: #1033524) * simplify instructions for making bootable USB media * remove mentions of mini.iso image * remove mentions of loadlin * Remove chapter about booting the installer from Windows. Support for win32-loader has been removed from the installer. . [ Chris Hofstaedtler ] * Remove dmraid (sata raid) from the doc; src:dmraid has dropped its udebs, and the experimental support from the installer was also removed. Closes: #1033535. . [ New translations ] * Romanian by Remus-Gabriel Chelu, many thanks! . [ Updated translations ] * Catalan by d * Greek by galaxico * Spanish by gallegonovato * French by Baptiste Jammet * German by Holger Wansing * Indonesian by Andika Triwidada * Italian by Luca Monducci * Korean by Changwoo Ryu * Dutch by Frans Spiesschaert * Portuguese by Miguel Figueiredo * Chinese
Re: Upload for installation-guide?
Hello, Holger Wansing, le ven. 28 avril 2023 22:43:17 +0200, a ecrit: > what do you think about a last upload of installation-guide for bookworm? > Maybe in one or two weeks, or similar? I have uploaded it. Samuel
partman-iscsi_75_source.changes ACCEPTED into unstable
Thank you for your contribution to Debian. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 08 May 2023 21:57:36 +0200 Source: partman-iscsi Architecture: source Version: 75 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Holger Wansing Changes: partman-iscsi (75) unstable; urgency=medium . * Team upload . [ Updated translations ] * Norwegian Nynorsk (nn.po) by Kjetil Sørlund Checksums-Sha1: 0c9b980edb06996053c3d21b0aff13007602c4e5 1657 partman-iscsi_75.dsc 779cbf2f5d01fd20c660e90ad31b12678d6ac85e 79244 partman-iscsi_75.tar.xz 1c60125afb84e7194d33b1128de02fcdaa59deee 6094 partman-iscsi_75_amd64.buildinfo Checksums-Sha256: 330874eaf3b9db73a142fccd5e9b6cf163f3080548bfc702d9cd156b873464f5 1657 partman-iscsi_75.dsc d6bfc509e1f4ff5f383f997db4ec3418cb47e3f0777dc3eb05ba6f5edf21e3a8 79244 partman-iscsi_75.tar.xz 95aea561b0ab2a03525ba4f310605e7b1f5f7c0dc93743b0c24d1817e21717d6 6094 partman-iscsi_75_amd64.buildinfo Files: 8d174f4feed895c4cd9b73e50c08b5d6 1657 debian-installer standard partman-iscsi_75.dsc 0afb0004c16cf30c2e005afd83e7adef 79244 debian-installer standard partman-iscsi_75.tar.xz 5186afa99da0db2c3a362f65e3268a89 6094 debian-installer standard partman-iscsi_75_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJJBAEBCgAzFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAmRZVQ4VHGh3YW5zaW5n QG1haWxib3gub3JnAAoJEFnxh8oVbrB2YXQQAJ8dMLC2UhdGl2nj1e4ijBxI2gZm xNC2C60Ij4JK2djj0ROjEVqCmBSrbbD91WFfVsKht+58NxASxMI44OSKmpZz8lS4 VdVnP8/hmJzMxOZcITJLEkfyuRsAywHzxaMjSJfBueQDGvpYRJXfFMC8D7SwCh7p OFwczA9UXwdED2F82UvE5fJVvLazR/yJEv5C0tULk51pMaKfdQ+oINRW678z56zx OLSY5LNgW+eprr7b8hrG5TNMh/ITnY0/SVenAp+3nHW5TEbi4FJvkUDem8SKUznk za4ixdzmc/k/PUbp+WrK7FvFknLKf84qdHq4igx9phnHR48n/1O6D7ypNwMH3fff VXhZl57ZXF153ikM8vnBi4s6DCDQI34RMStoYit48PoRYK4tAAQ2+FtTIimr4yHx BZSPyJ/Dn4x5ryZPTTDqB97VG70q69xpN3YzCk1OpTNlC1F6htgzeiuZsoqhRzK/ y2AYMvY4z6BBIlt0CecuKq7G34Obj4+Sz6xdrTkXJWs6BMP0ZJ2bJXNHtxhWRX+6 hlewhzlGvG/ejNSOi3vXUqJrfWB+SQo2GawFtlVCGW/zL5VzAIjCqXrlNeRCpV5J 0uscOTPVRbuE/4qwrb70XhVv+m2oH3XhEjMJC+Aclwr8L+8Jaoiju4Aje69NGYoH A6/eWLHihFZW6UgA =ACcQ -END PGP SIGNATURE-
partman-crypto_120_source.changes ACCEPTED into unstable
Thank you for your contribution to Debian. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 08 May 2023 21:44:34 +0200 Source: partman-crypto Architecture: source Version: 120 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Holger Wansing Changes: partman-crypto (120) unstable; urgency=medium . * Team upload . [ Updated translations ] * Norwegian Nynorsk (nn.po) by Kjetil Sørlund Checksums-Sha1: d493f22bd3b67f3de904f76e340872dd297f7fc8 1799 partman-crypto_120.dsc 153db8234dd736ac9dfba910df7cf1ebdd8cc530 274764 partman-crypto_120.tar.xz eb60ae926ae0060b8c300c9318e632c98b57ca70 6395 partman-crypto_120_amd64.buildinfo Checksums-Sha256: 7f77138a184b38764efc08fcb2032c7fd8619fdba1c4750347a4d9dda536e276 1799 partman-crypto_120.dsc 051e92c2ea7efeab3a8d8972fd621246c80a45c24f37428199fd66c026243088 274764 partman-crypto_120.tar.xz b42f682c28364317884236dd001adcd732a1f761baf448ac17d2ae63dea03d1c 6395 partman-crypto_120_amd64.buildinfo Files: 9121060053f6f9f10788f1359dce78c0 1799 debian-installer optional partman-crypto_120.dsc 5ea4a9da2689a85987a3af69108b951f 274764 debian-installer optional partman-crypto_120.tar.xz cd2d7ba37dc64256e166ad45311b7d6c 6395 debian-installer optional partman-crypto_120_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJJBAEBCgAzFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAmRZUooVHGh3YW5zaW5n QG1haWxib3gub3JnAAoJEFnxh8oVbrB2yHQP/0GBL7mDhZPd9eizI20IUc9GMtM/ UIC3WMrkUAk5f5lJX/fup8RIpEtIaB3A9OJSfOPOtYSxIPEXxO8Z8LBiyCPm7/9Q 0rFWgLgb9DcJCWfEb79FzRErKmvstQ3qtFpLcAKi4gtW4lpT6mte+/isp4Boahwr DAzu4XBKxaYjm812NwJtqxpkZ5DREcIm2KddZbtuPF2YNgDZicfcFzhBYBG7zHVp ZEjZe1JFAiuuxDMyblMn11ibbmDa/iVg6HHEo4iufrs+OPZp6N4xODSFV5Dp+1zq J7NJb0Ms1Ow17/uiV9sNUgy6KlYf6fujiQzRiU3heaSa2doYNA9lc2Bskr1Zb43F aGh1GH2asnGnhe/l1CrG5VCNbV00S28d0z5IKFSjVcXakX+mlXWPkU9yUqY4tsV4 PLdIcW39PJqG8B+sZlRlbADmPe27tFkLOtBAyRiGtw391c1fq5DLcxWTgQq6hJGy 9Ipzvo7Dqp10q+TEsURJ9uzPch5Li0B0D0aCvlF31LGYManb79sZ0hyoeAMxh1Uh bPci4ev2qSGrBqO1DEObd9U7PnsKZFuGD2YA8o7gDaPfJcVUBHht2m4Gdukn+MVh trk+mQ4tM8M90LBAq87LiCNGRsa7ixtwQ8Hf0/SdVQos1GsfxABvi6aWWbnRfKSm 7ik+3WFaJ9Ye1t54 =fXnJ -END PGP SIGNATURE-
partman-base_224_source.changes ACCEPTED into unstable
Thank you for your contribution to Debian. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 08 May 2023 21:36:19 +0200 Source: partman-base Architecture: source Version: 224 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Holger Wansing Changes: partman-base (224) unstable; urgency=medium . * Team upload. . [ Updated translations ] * Norwegian Nynorsk (nn.po) by Kjetil Sørlund Checksums-Sha1: 859e8041d5f902cd89b69a2ed25481d301b93ed0 1856 partman-base_224.dsc 0eb3b7cb3947a83fcc478e8aee2d25f5798e5485 177784 partman-base_224.tar.xz 02e1da0606ea6077c068d192410b2ee0a3ce2aa1 6984 partman-base_224_amd64.buildinfo Checksums-Sha256: 004edf4a709405a3824d51bc2f41b6efb2a90e32753638592016e4b255805c43 1856 partman-base_224.dsc 70adcb0425e013501f8100bd7d34a1a81474462f1efb6a9491b3e0ab7366dff8 177784 partman-base_224.tar.xz ae02ed82859c290021dbad67b15b3d16390011ee155614a54ecc4794bb24d444 6984 partman-base_224_amd64.buildinfo Files: ed267d96fc8bda00954d322fcd4f7e97 1856 debian-installer standard partman-base_224.dsc 82be1d417e39fd55bde5a46836e29076 177784 debian-installer standard partman-base_224.tar.xz 899d78c2c9eb0e89db278b147f59dc7d 6984 debian-installer standard partman-base_224_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJJBAEBCgAzFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAmRZT94VHGh3YW5zaW5n QG1haWxib3gub3JnAAoJEFnxh8oVbrB2VXwP/2cJd4z7Vium5grMnaOiURmx+ocA eeAYF6Trj9YjHQuIw1N71Iz8hHbRXiMvZhYqJCNgh0xS3V4Hl1TYS8XAB6Faf0dI JkkTrcKIrMk3N3H1eXAK6Lv3V+Yr2sEAZqk1BijN/ZeuR8qOKfKmBgEeUo8Rb5xC NVSMhH6YBKc8CpNgG4I1bqO0SVpB/KRgntpUyz6MwywgnXh4XVrIMXOUKaqY3Hlz u8Uq0B74cbDF6qn3jJMipPaEQ1UsdBlE+3f5ZYYUT1EqSUEhLmDWsOBixOfBu+eW Z1Q7R7MLwiYLkYEZm8B1v4Zn4FNInfWAZM6huCMi6ruy/cFUXMB1oymZHE/7AIs6 tbQDW61rhKTiAtqwkWEqKtbinmpjNb27uotcdQ6+ujyT9bd8Z7NQWUItoFwbqmy6 wGPeHgiiDIKS1ok9p7y9JFVOJsPLcA2Y+WbIZQ9yBuy9zq8MYht1MiFeROLsM2z+ HzFjYpT0LO6cniq0NOvwTy3Gp1XzhT3i9xbxk1S8wH6lFtcyOIu0EfBkJXV0gCrU DZ9waUEwARqcY8BL9VW4MHD0v8fEXitB39CmyTu4kBGHkda9erZ65mN6xFTXzoY0 LcMts6KwORWWBj9yg3gaYMh55OwXAO3I5LYR1/mzP2HQgfvW2/Is1G0fT5Rm5Ykc Vb6kkX5SVvpxRG8V =YIkM -END PGP SIGNATURE-
Processing of partman-iscsi_75_source.changes
partman-iscsi_75_source.changes uploaded successfully to localhost along with the files: partman-iscsi_75.dsc partman-iscsi_75.tar.xz partman-iscsi_75_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Processing of partman-crypto_120_source.changes
partman-crypto_120_source.changes uploaded successfully to localhost along with the files: partman-crypto_120.dsc partman-crypto_120.tar.xz partman-crypto_120_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#1035085: Bookworm RC2 grub-installer/os-prober quirks
On 29/04/2023 at 11:22, I wrote:
1) In expert install (or low priority), the new os-prober dialog
displayed by grub-installer lists only unsupported OS but not supported OS.
(Patch attached)
2) "efi" os-prober type is considered unsupported.
In EFI mode, os-prober detects EFI boot loaders such as Windows Boot
Manager with type "efi". GRUB can add menu entries for these boot
loaders so this type should be in the supported list instead of the
unsupported list. (AFAICS it does not matter much because the supported
OS list is used only when installing GRUB for legacy boot and not EFI
boot.)
(Patch attached)
Another one:
If the installer was booted in EFI mode but detected existing operating
systems already installed using "BIOS compatibility mode" and the user
chose to not force UEFI installation, update-grub executed in the target
chroot still behaves in EFI mode: it detects and adds entries for EFI
boot loaders and UEFI firmware settings to the GRUB menu and ignores
legacy boot loaders. It should do the opposite, even though running
update-grub again after booting the installed system will fix the GRUB menu.
(Patch attached)
I tested the 3 patches together with BIOS boot, EFI boot + installation,
EFI boot + BIOS installation.From 5adc3dd8bf3118f40018bc3447a9f60684f1343e Mon Sep 17 00:00:00 2001
From: Pascal Hambourg
Date: Sun, 30 Apr 2023 09:06:52 +0200
Subject: [PATCH 3/3] Do no run EFI probes in target chroot if ignore_uefi is
set
If partman-efi set /var/lib/partman/ignore_uefi, we do not want
os-prober to skip legacy probes and perform EFI probes, so create
ignore_uefi in /target. We also do not want grub 30_uefi-firmware
to probe UEFI firmware settings, so do not mount efivarfs (only
needed when installing grub-efi).
---
debian/postinst | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/debian/postinst b/debian/postinst
index 85714195..1ff3f851 100755
--- a/debian/postinst
+++ b/debian/postinst
@@ -43,6 +43,16 @@ mountvirtfs () {
# target. Maybe /proc too?
mountvirtfs proc /target/proc
mountvirtfs sysfs /target/sys
-mountvirtfs efivarfs /target/sys/firmware/efi/efivars
+
+if [ -e /var/lib/partman/ignore_uefi ]; then
+ # prevent os-prober EFI probes in target chroot
+ mkdir -p /target/var/lib/partman
+ touch /target/var/lib/partman/ignore_uefi
+else
+ mountvirtfs efivarfs /target/sys/firmware/efi/efivars
+fi
grub-installer /target
+
+rm -f /target/var/lib/partman/ignore_uefi
+rmdir /target/var/lib/partman 2>/dev/null || true
--
2.30.2
Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Mon, May 08, 2023 at 06:16:52PM +0100, Pete Batard wrote: > Plus, UEFI has an official standard, and standards are (for the most part) a > good thing. IEEE-1275 is a standard too. > However, with what I have mentioned initially and the weight that Microsoft > has, the only way you're going to have vendors moving away from ACPI is if > Microsoft decides to add support for DT in Windows (or something else that > they see better than ACPI)... which I don't really see happening in the near > to medium term, since, much to their benefit, Microsoft did manage to get > the ARM SBBR specs to go with ACPI and thus continue business as usual as > far as Windows is concerned. > > Again, I am hoping that there was some consideration given by Microsoft and > other members of the SBBR committee as to whether it made sense to go with > Device Tree. One of the problems I would see however is that, I doubt the > Linux folks consulted with Microsoft when they introduced Device Tree (then > again why and how would they) to see if Microsoft had some interest for > using it in the long run, and if so, what they could do to make it more > palatable for Windows usage. Well devicetree is part of open firmware aka IEEE-1275, from 1994. ACPI is from 1996. And of course since I don't think Sun cared at all what Microsoft thought when they designed the firmware interface, I don't think that matters. Since open firmware or at least devicetree has then ended up used on SPARC, PowerPC, ARM, MIPS, and who knows what else, while ACPI is x86 and now some ARM but nothing else as far as I can tell, other than in terms of overall units using it, ACPI certainly has a lot less interest. > And that's the old problem of ecosystems being split on OS lines, when it > would be nice if we could look a bit further than that, with Linuxfolks most > likely not that eager to ask Microsoft if they have some input on the > direction they wanted to take when they introduced DT, and, likewise, > Microsoft unlikely to want to use some "Not Invented Here" technologies like > DT, even more so when you have the other elephant in the room for the "Not > Invented Here", i.e. Apple, which seems so adverse to compromising with > anybody that it provides the worst example to follow such as, using their > own version of EFI on x86 based hardware rather than UEFI, and then dropping > that altogether on their ARM based silicon, to now use their own completely > custom pre OS execution environment. At this stage, I should probably add > that it's going to be fat chance to ever see Apple use SBBR on their > hardware even, if on paper, it should have been a perfect target for it and > sure would have make booting and installing Debian on Apple Silicon > easier... even if one were to be constrained to use ACPI over DT. Apple is almost certainly back to devicetree on their arm devices since they used it on their powerpc based systems already in the past. > To me, it looks like mostly a question of reducing development cost as well > as what one can get away with by not going out of their way to try to talk > and seek compromise with other parties. And, as usual, it's the end-users > that pay the price by having hardware and OSes that restrict what they > should be able to do with it, starting with their ability to install the OS > they prefer on modern ARM64 hardware. > > And that's actually the reason why I think efforts like SBBR should be > supported, because they are trying to break the status quo, even if it > appears that Microsoft might have gotten what they wanted at the detriment > of Linux, and even if Apple are unlikely to ever want to touch SBBR with a > ten foot pole... Well unfortunately for years it seems the status quo has also been 64 bit arm servers being annonced, but not able to be purchased anywhere unless you were google or amazon or some other large cloud provider. Apparently they didn't actually want to sell their systems. Then they complained that there was no market for arm servers. Maybe it has gotten better in the last few years, but in my current job having arm servers is no longer relevant unfortunately. I sure wanted some 8 or 10 years ago when they were announcing them but not actually selling them. > Well supported across architectures: yes. > Well supported across OSes: Unfortunately no, when you do consider Windows. Any OS that ever ran on an openfirmware system, which is a lot of them. > And that is the main issue here. SBBR is not just for Linux, or for Windows. > So, yes, someone, on the OS side, is likely to have to do extra work, whose > only purpose will be to allow people to install a completely different OS. > And yes, that sucks. But if it benefits end-users, it's the price one has to > pay. It seems that it benefits only one OS, the one it seems just about no one cares to run on arm systems. Doesn't mean that long term ACPI and UEFI might not be better for SBBR. I highly doubt the decision was made without
Processing of partman-base_224_source.changes
partman-base_224_source.changes uploaded successfully to localhost along with the files: partman-base_224.dsc partman-base_224.tar.xz partman-base_224_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
partman-auto-lvm_90_source.changes ACCEPTED into unstable
Thank you for your contribution to Debian. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 08 May 2023 21:26:48 +0200 Source: partman-auto-lvm Architecture: source Version: 90 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Holger Wansing Changes: partman-auto-lvm (90) unstable; urgency=medium . * Team upload . [ Updated translations ] * Norwegian Nynorsk (nn.po) by Kjetil Sørlund Checksums-Sha1: 3b3e91b0b5dd8e2575b4af676334ece4e914849b 1699 partman-auto-lvm_90.dsc d8104dad89a6f89ef6e3dd147a0bed9f38142a4f 124064 partman-auto-lvm_90.tar.xz 1adf32444f7c0b8f9fb416272651d2d5980a1cb0 6124 partman-auto-lvm_90_amd64.buildinfo Checksums-Sha256: f567d3d6c6e96a03ed2a8d8ce13464ca2bfaa302a61de13245d1cecf6d8a5186 1699 partman-auto-lvm_90.dsc f8ac465e623d9a9fa9ab9fe0ac7acdf451fd1cf89bb0861a8698ea2555e1f847 124064 partman-auto-lvm_90.tar.xz 0190171d670726ac5488ef6157f4a34ca18e91ef4f704f059eb7fe022665c008 6124 partman-auto-lvm_90_amd64.buildinfo Files: 2a2e38b0811d1f0a0eaea13998ca1994 1699 debian-installer optional partman-auto-lvm_90.dsc 7e4503b409e00a4f94a62e5472f7e88a 124064 debian-installer optional partman-auto-lvm_90.tar.xz 2e775c66ef5c85c6cc06264546b479a4 6124 debian-installer optional partman-auto-lvm_90_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJJBAEBCgAzFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAmRZTgMVHGh3YW5zaW5n QG1haWxib3gub3JnAAoJEFnxh8oVbrB20o8QAJFDJ8yr9rtJyaYACSwl/ZVvOgro o8CJFCC+vGbOLtEhfsfvh719HeytS5kAcuU4oEd2GV/Y39kUz/0BJKwAKPB0+INn jlnJM+64hPg9CJQTvx1Ss0q1fjYhhB7XnB8PNGX90CWp6qnixBZXS2dLCtVJ/leO ejRnjjuS6yzJ97ql2MqzclCoz2vqazs91NeQ/lJE7YRYLLBn5FsrWxFX1wfOG8lX 9K4Z4NAuzzXcprPP6OvQwm8ZkA5tIUEJ1e4EO9ZSXfClJliFUEgQg3QF/lUMIDXN sIjnpyu6CNIX6osp1cvgOk+U+LnkvI8bMW/H97iT3pEY+TKC2U4vl1R/7o8QJvyl dGVMy9hStjWI1d0JBobRr29DRjZoRKZd6ekiYzvm6q+MBVyQnks3tl4CxVcUL4Br UcyvzGr1k5rEqw4q5FV1VhMamF2xODyzq+nt3NhHd+U6P21XUFKaberJt4Ke7Hrq J+PR+3SN5kDpJffDvXhDn9SbdIHK/AT3gcrGIOnEKU/UKmkb4cynm7Mn4xg323Ut yuWnmr8+6BI4rs0gpI4nhdAZ+ic5jmGxDI74NY5YU+lKRFEUZh+GESI8TIDsd1Kh 6mI7IQe03KAv570bvKys3/WAFTftoLHzuGJq8xyXdyaZNAVOBG0r+TSEg9QOGl5z nVVYrVo28pCKpKU4 =+sna -END PGP SIGNATURE-
Processing of partman-auto-lvm_90_source.changes
partman-auto-lvm_90_source.changes uploaded successfully to localhost along with the files: partman-auto-lvm_90.dsc partman-auto-lvm_90.tar.xz partman-auto-lvm_90_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
Well, I guess at this stage, and to help provide some more context about the DT vs ACPI conundrum, I'm going to stop tiptoeing around the literal elephant in the room, but not without first adding a preliminary notice that I wasn't privy to whatever discussions occurred with regards to the SBBR standard (I'm just a mere downstream developer, that got involved well after SBBR was crafted), so part of it is yet again going to be pure speculation. The "elephant" in the room, in our case, is Microsoft since, from what I understand, they did drive part of the design of the standard... which of course makes sense since they do have an OS that they would like to see people install on ARM servers and therefore will be interested in an emerging ARM standard that's likely to affect them. And likewise, the ARM folks, when devising a new standard, most certainly wanted feedback from the company that still holds the lion's share of installed OSes out there. So, any decision that was taken as part of the writing of the standard is likely to have had Microsoft's footprint in one way or another. That's not to say that (again from what I understand) Microsoft got free reign, and that people interested in promoting the standard for Linux, BSD or something else got the short end of the stick. But of course, now that you know that Microsoft did play a part in this whole SBBR endeavour, it might give you yet a different perspective on this whole ACPI vs DT matter... On 2023.05.08 12:15, James Addison wrote: Somewhat agree, yep - although I think that in this case, there should be various paths available (u-boot, EDK2, ACPI/DT), and if possible I'd like to understand what is the approach that provides the most compatibility and free software support with the fewest moving parts. To me, the reliability and human-time cost savings from simpler, more open and straightforward systems outweigh many other factors, especially over the long term. Agreed. But to others such as Microsoft, not having to integrate something foreign when they already have good support for both UEFI and ACPI in their OS was probably something that they had some strong opinions about. In other words, while I like to imagine that Microsoft did consider whether it would make sense to add support for DT for Windows on ARM, and ultimately decided against it on a technical basis rather than on an "it'll make life simpler for us", it appears that the consensus settled on not having DT being part of the standard. That's partly the reason I've been wondering about the power consumption and operating-system-compatibility questions: as I understand it, those were key reasons that server hardware vendors had a preference for ACPI when determining the server standards in the mid-2010s, and so a few years since then, it could be helpful to figure out whether those continue to make a difference, and how Devicetree/FOSS driver implementations compare. If Microsoft and the people who drove the SBBR standard did review things objectively, this might indeed be part of why they decided not to add DT support. I think that's great, and I've had a good experience with EDK2 + Devicetree. My concerns about ACPI are basically that it seems like a less-readable, larger-surface-area standard with more opaque processes surrounding it. But I'm not an expert. Yeah, neither am I, and I'll trust Linus and the kernel folks when they decided that ACPI was such a liability that they had to devise something better... This being said, I do wonder if DT has been holding all its promises and doesn't come with its own pitfalls, now that we've seen it used in practice for a few years. At least, as someone who has had to help with implementing code that *alters* the original DT provided by the Pi Foundation, so that it can actually be used downstream of UEFI boot (which is something we have to do in the current Pi UEFI firmware [1]) and has had to look from the sidelines at the annoyance of still having to use a compiled-in format (couldn't some bz2 of plaintext, with a little extra processing/runtime compilation from the kernel, work well enough so that one could make editing of DT a lot friendlier for the end users? Talk about doing away with binary formats...), I can't say I'm entirely convinced that DT couldn't have been improved further. Getting slightly further off-topic, but for my own education: what is an example of a UEFI feature that a user might want to use? Well, the big one would of course be Secure Boot. Others would be the ability to have an interface from the OS, that allows one to modify boot order/boot entries and read/write some (relatively) standardised pre-boot environment variables. Oh and don't forget the ESP, which is a lot more user friendly as a means to alter your bootloaders and boot environment (just copy/edit at the file system level, from your OS and with your utilities of choice, or use a full
Re: Bug#1029843: Missing symlinks for RPi 4 (to brcmfmac43455-sdio.raspberrypi,4-model-b.txt)
On Mon, 8 May 2023 at 14:57, Diederik de Haas wrote: > > On Monday, 8 May 2023 14:08:14 CEST James Addison wrote: > > On Mon, 1 May 2023 11:18:03 +0100, James Addison > > wrote: > > > > Diederik de Haas (2023-04-30): > > > > > And that's exactly what happens or will happen. Even though the RPi4 > > > > > filename doesn't contain spaces, there are several in the `brcm` > > > > > directory that do. I didn't check other directories, but I'd expect > > > > > that filenames with a space is NOT an anomaly. > > > > > > Since more files with that pattern are appearing upstream in > > > linux-firmware.. yes, slightly reluctantly it does seem that this will > > > be needed. > > > > FWIW: After learn the root cause of the spaces-in-filenames problem for > > packages derived from linux-firmware.git -- that is, the contents of the > > 'WHENCE' file in linux-firmware.git -- in fact the RPi4 is the only > > affected[1] firmware currently. > > Triggered by your statement, I did a VERY crude search for spaces > in "File: " or "Link: " lines in the WHENCE file: > > diederik@bagend:~/dev/kernel.org/linux-firmware$ grep -E "^Link: .* .* -> .*" > WHENCE > Link: brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ 4\ > Model\ B.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt > Link: brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ > Compute\ Module\ 4.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt > Link: nvidia/gm206/acr/bl.bin -> ../../gm200/acr/bl.bin > diederik@bagend:~/dev/kernel.org/linux-firmware$ grep -E "^File: .* .*" WHENCE > File: "brcm/brcmfmac43241b4-sdio.Intel Corp.-VALLEYVIEW C0 PLATFORM.txt" > File: "brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-TF103CE.txt" > File: "brcm/brcmfmac43430a0-sdio.ONDA-V80 PLUS.txt" > File: "brcm/brcmfmac43455-sdio.MINIX-NEO Z83-4.txt" > File: "brcm/brcmfmac4356-pcie.Intel Corporation-CHERRYVIEW D1 PLATFORM.txt" > File: "brcm/brcmfmac4356-pcie.Xiaomi Inc-Mipad2.txt" Ah, okie doke. Thanks for catching those. > The last "Link: " line can be ignored due to being too crude ... > but it does appear that it ONLY exists in the `brcm` directory ... > > > (that surprised me, but does seem to be the case. I'm writing to counteract > > any sense that the proposed patch[2] could affect and fix many firmwares. > > it won't, at least not today) > > > > [2] - > > https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/65 > > https://lore.kernel.org/linux-firmware/20230301-fixes-and-compression-v2-0-e2b71974e...@gmail.com/ > seems related as f.e. 1 patch deals with the inconsistent " " vs "\ ". > > While I was inclined based on my findings above to mark it as an anomaly, > that patch set seems to indicate that the spaces won't be removed in > the future, just that its use would probably more consistent. Ok, thanks again; perhaps it's worthwhile waiting a little longer for upstream to decide on the preferred line format(s) they'll accept.
Re: Bug#1029843: Missing symlinks for RPi 4 (to brcmfmac43455-sdio.raspberrypi,4-model-b.txt)
On Monday, 8 May 2023 14:08:14 CEST James Addison wrote: > On Mon, 1 May 2023 11:18:03 +0100, James Addison wrote: > > > Diederik de Haas (2023-04-30): > > > > And that's exactly what happens or will happen. Even though the RPi4 > > > > filename doesn't contain spaces, there are several in the `brcm` > > > > directory that do. I didn't check other directories, but I'd expect > > > > that filenames with a space is NOT an anomaly. > > > > Since more files with that pattern are appearing upstream in > > linux-firmware.. yes, slightly reluctantly it does seem that this will > > be needed. > > FWIW: After learn the root cause of the spaces-in-filenames problem for > packages derived from linux-firmware.git -- that is, the contents of the > 'WHENCE' file in linux-firmware.git -- in fact the RPi4 is the only > affected[1] firmware currently. Triggered by your statement, I did a VERY crude search for spaces in "File: " or "Link: " lines in the WHENCE file: diederik@bagend:~/dev/kernel.org/linux-firmware$ grep -E "^Link: .* .* -> .*" WHENCE Link: brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ 4\ Model\ B.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt Link: brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ Compute\ Module\ 4.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt Link: nvidia/gm206/acr/bl.bin -> ../../gm200/acr/bl.bin diederik@bagend:~/dev/kernel.org/linux-firmware$ grep -E "^File: .* .*" WHENCE File: "brcm/brcmfmac43241b4-sdio.Intel Corp.-VALLEYVIEW C0 PLATFORM.txt" File: "brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-TF103CE.txt" File: "brcm/brcmfmac43430a0-sdio.ONDA-V80 PLUS.txt" File: "brcm/brcmfmac43455-sdio.MINIX-NEO Z83-4.txt" File: "brcm/brcmfmac4356-pcie.Intel Corporation-CHERRYVIEW D1 PLATFORM.txt" File: "brcm/brcmfmac4356-pcie.Xiaomi Inc-Mipad2.txt" The last "Link: " line can be ignored due to being too crude ... but it does appear that it ONLY exists in the `brcm` directory ... > (that surprised me, but does seem to be the case. I'm writing to counteract > any sense that the proposed patch[2] could affect and fix many firmwares. > it won't, at least not today) > > [2] - > https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/65 https://lore.kernel.org/linux-firmware/20230301-fixes-and-compression-v2-0-e2b71974e...@gmail.com/ seems related as f.e. 1 patch deals with the inconsistent " " vs "\ ". While I was inclined based on my findings above to mark it as an anomaly, that patch set seems to indicate that the spaces won't be removed in the future, just that its use would probably more consistent. signature.asc Description: This is a digitally signed message part.
Bug#1029843: Missing symlinks for RPi 4 (to brcmfmac43455-sdio.raspberrypi,4-model-b.txt)
Package: firmware-brcm80211 Followup-For: Bug #1029843 X-Debbugs-Cc: k...@debian.org, didi.deb...@cknow.org, debian-boot@lists.debian.org, p...@akeo.ie On Mon, 1 May 2023 11:18:03 +0100, James Addison wrote: > > Diederik de Haas (2023-04-30): > > > And that's exactly what happens or will happen. Even though the RPi4 > > > filename > > > doesn't contain spaces, there are several in the `brcm` directory that do. > > > I didn't check other directories, but I'd expect that filenames with a > > > space is > > > NOT an anomaly. > > Since more files with that pattern are appearing upstream in > linux-firmware.. yes, slightly reluctantly it does seem that this will > be needed. FWIW: After learn the root cause of the spaces-in-filenames problem for packages derived from linux-firmware.git -- that is, the contents of the 'WHENCE' file in linux-firmware.git -- in fact the RPi4 is the only affected[1] firmware currently. (that surprised me, but does seem to be the case. I'm writing to counteract any sense that the proposed patch[2] could affect and fix many firmwares. it won't, at least not today) [1] - https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/WHENCE#n2708 [2] - https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/65
Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Fri, 5 May 2023 at 12:52, Pete Batard wrote: > On 2023.05.04 14:16, James Addison wrote: > > Yep, and for those situations, that's a point in favour of the third > > "System Table Selection" value that I failed to mention: > > "ACPI+Devicetree". > > Indeed, the firmware provides that that option as well. > > > I'm cautious about recommending it, given an understanding that > > enabling ACPI could increase the amount of non-free code (ACPI Machine > > Language, in particular) that may run on the system as a result. > > I think with current CPUs (especially on the x86 side with Management > Engines as well as proprietary blobs), we're alas way past the point of > being able to prevent non-free code from running. Somewhat agree, yep - although I think that in this case, there should be various paths available (u-boot, EDK2, ACPI/DT), and if possible I'd like to understand what is the approach that provides the most compatibility and free software support with the fewest moving parts. To me, the reliability and human-time cost savings from simpler, more open and straightforward systems outweigh many other factors, especially over the long term. That's partly the reason I've been wondering about the power consumption and operating-system-compatibility questions: as I understand it, those were key reasons that server hardware vendors had a preference for ACPI when determining the server standards in the mid-2010s, and so a few years since then, it could be helpful to figure out whether those continue to make a difference, and how Devicetree/FOSS driver implementations compare. > The Raspberry Pi SoC has also some very non-free code running that > executes prior to the running of the UEFI firmware and also in parallel > to the UEFI firmware and OS. There's basically a Management Engine > running on the GPU, which, among other things, provides a mailbox that > the UEFI firmware uses to retrieve or set hardware configuration data. Yep, I've still got quite a lot to learn about that, I think. > On the other hand in this specific case, though I understand you're > speaking in a more general manner about ACPI usage, the whole ACPI blob > generation comes entirely from open source code. I think that's great, and I've had a good experience with EDK2 + Devicetree. My concerns about ACPI are basically that it seems like a less-readable, larger-surface-area standard with more opaque processes surrounding it. But I'm not an expert. > As far as I'm concerned, the main reason I wouldn't advocate ACPI + > Device Tree is that it can create user confusion as to what is really > being used behind the scenes. A bit like when PC end-users enable Legacy > boot in their UEFI settings and end up installing their OS in Legacy > mode on a UEFI capable system, then find themselves in a situation where > they want to use UEFI features but can't. Getting slightly further off-topic, but for my own education: what is an example of a UEFI feature that a user might want to use? (to my mind, most of my preferences are: I want to use a standard, easily-obtained installer, for each system install to be straightforward and for the system to boot, for each system's devices to function correctly, and for those to occur while minimizing the amount of extraneous runtime code and I/O (roughly in that order of precedence, and with FOSS practices helping a lot to achieve and maintain those in the long-term). perhaps ranty, but it's intended to explain why I don't love standards that include unusual and/or unproven quirks, and binary blobs) > Also, again, since part of our goal has been to promote the emerging > SBBR standard (because we think it should ultimately help making > installation of various OSes on par with what is the case for x86 based > PCs, where you can pretty much just create a universal boot media as > well as have the OS install and use unified boot loaders, rather than > force users to concern themselves about the low-level system specifics > of their system, and play with yet another custom version of u-boot), > and SBBR made the choice to go with ACPI only rather than > ACPI+DeviceTree, we decided to propose ACPI+DeviceTree as a means not to > restrict user choice for people who want to use both, but knowing that > it's not something we really want to officially support. Yep, that makes sense and your decision-making logic is sound. If I were to imagine a two-line chart of device and hardware support over time, with one line each representing the ACPI and Devicetree approaches, then based on this standardization and industry backing, I would expect ACPI to be the upper line for some duration of time (decade?) until the point at which the drawbacks and disadvantages of the extraneous functionality and complexity that I sense (but can't really confirm, yet) outweigh the industry momentum placed behind it. And I think that's a shame, because if the same effort and backing had been placed behind a simpler, more open
