Re: Planning for 12.6/11.10
On Mon, May 27, 2024 at 01:07:17PM +0100, Jonathan Wiltshire wrote: >Hi, > >The final bullseye point release 11.10 (and therefore also 12.6 for >versioning) should be soon after 10th June, when security team support >will end. > >Please indicate availability for: > > Saturday 15th June > Saturday 22nd June > Saturday 29th June Any of those are feasible for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Re: DD application (Re: Next attempt to add Blends to Debian installer)
On Sat, May 11, 2024 at 10:07:44PM +0200, Cyril Brulebois wrote: >Hi, > >Holger Wansing (2024-05-10): >> I know you repeatedly suggested this. Especially every time I ask for >> more packages to get dm permissions for :-)) > >Just in case that's not clear: I'm not trying to get rid of you as if >you were a burden (which you're clearly not), I'm suggesting you get >recognized as an uploading DD (which you certainly qualify for >already!). +1000 Holger, you're great. Stop arguing :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183
Re: Re-planning for 12.6
On Sat, Apr 20, 2024 at 05:41:13PM +0100, Jonathan Wiltshire wrote: >On Thu, Apr 18, 2024 at 10:58:41PM +0100, Steve McIntyre wrote: >> Hiya! >> >> Not wanting to pester *too* much, but where are we up to? >> > >Right now I can still have 27th April on the cards but we're missing FTP and >press. It's next week, we'd have to know this weekend and get frozen. >Mark indicated "maybe" and no answer from press. > >If that date works please reply urgently otherwise we're looking into May >and possibly just skipping to line up with the final bullseye anyway. It works for me, I guess. Dunno about other folks. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183
Re: Re-planning for 12.6
Hiya! Not wanting to pester *too* much, but where are we up to? On Tue, Apr 02, 2024 at 10:53:49PM +0100, Steve McIntyre wrote: >On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam Barratt wrote: >>Hi, >> >>As we had to postpone 12.6, let's look at alternative dates. >> >>April 13th >>- Not great for me for personal reasons, mhy previously said no. I >>could probably do if need be > >Works for me. > >>April 20th >>- Doesn't work for me; I'm away from the Tuesday before until late on >>the Friday > >Works for me. > >>April 27th >>- Doesn't work for me; I have a pre-existing appointment which means >>I'll be AFK much of the day > >Works for me. > >>May 4th >>- Apparently doesn't work for me; long weekend in the UK >> > >Works for me. > >>May 11th >>- Should work for me > >Nope, already booked for that Saturday. > >-- >Steve McIntyre, Cambridge, UK.st...@einval.com >"...In the UNIX world, people tend to interpret `non-technical user' > as meaning someone who's only ever written one device driver." -- Daniel Pead -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Re: Re-planning for 12.6
On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam Barratt wrote: >Hi, > >As we had to postpone 12.6, let's look at alternative dates. > >April 13th >- Not great for me for personal reasons, mhy previously said no. I >could probably do if need be Works for me. >April 20th >- Doesn't work for me; I'm away from the Tuesday before until late on >the Friday Works for me. >April 27th >- Doesn't work for me; I have a pre-existing appointment which means >I'll be AFK much of the day Works for me. >May 4th >- Apparently doesn't work for me; long weekend in the UK > Works for me. >May 11th >- Should work for me Nope, already booked for that Saturday. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: debian 12.5 fails installation
Hi David, On Fri, Mar 15, 2024 at 10:37:19AM +1100, David wrote: > >debian 12.5 direct or live version fails to find boot device >after install. (AMD-64) on 1Tbit HDD. > >Why is the EFI directory blank ?. > >HDD previously able to load Fedora , Voyager ,Kylin , Ubuntu ,KaOS etc. We've done lots of test installations using exactly those images. See https://wiki.debian.org/Teams/DebianCD/ReleaseTesting/Bookworm_r5 for more information about the tests that were performed on release day. If you're having problems with installation on your system and would like some support, then please give us more details about that system, what options you chose during installation etc. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Bug#1065807: installation-reports: Verify Installtion Media Fails
Hi Neal, On Sat, Mar 09, 2024 at 08:45:28PM -0500, Neal wrote: > >(Please provide enough information to help the Debian >maintainers evaluate the report efficiently - e.g., by filling >in the sections below.) > >Boot method: USB >Image version: https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso- >cd/debian-testing-amd64-netinst.iso 2024-03-07 >Date: 3/9/24 > >Machine: Lenovo Thinkcenter >Partitions: Failed be being set > >Base System Installation Checklist: >[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it > >Initial boot: [O ] >Detect network card:[ ] >Configure network: [ ] >Detect media: [ O] >Load installer modules: [ ] >Clock/timezone setup: [ ] >User/password setup:[ ] >Detect hard drives: [ ] >Partition hard drives: [ ] >Install base system:[ ] >Install tasks: [ ] >Install boot loader:[ ] >Overall install:[ ] > >Comments/Problems: > >It always detects a file corruption. I verified hash on download and verified >good usb stick. Same usb was used to install Debian 12 after, which correctly >verified. Hmmm. I've just grabed the latest weekly amd64 netinst and tried to reproduce your issue. Things work here just fine in a VM, using this image: e618afbebbbdf9495c74140bc87f2a4b debian-testing-amd64-netinst.iso Does that match your image? If the integrity check fails, it should say which file is wrong. What did it report for please? -- Steve McIntyre, Cambridge, UK.st...@einval.com "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." -- Bruce Schneier
Re: Planning for 12.6
On Mon, Feb 12, 2024 at 06:04:17PM +, Jonathan Wiltshire wrote: >Hi, > >12.6 should be around 10th April, so please indicate availability for: > >7 April >13 April >20 April Any of those should work for me, assuming (re Adam) that you mean 6 April and not 7 April. -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Re: install isos with 6.1.0-16
Hi! On Mon, Jan 01, 2024 at 12:32:41PM +0100, Zargos wrote: > >Sorry if i'm not on the right list address (i'd like to know which is the >good one). > >When will the install ISO will use 6.1.0-16 kernel? as when creating >unofficial ISO all actual process use 6.1.0-15 kernel. Because of this, >install failed with error because the version difference. > >This is what happen with simple-cdd/debian-cd use to generate ISOs. > >or maybe there is a trick to know to avoid the generation using 6.1.0-16 >udebs? 6.1.0-16 isn't in stable yet, only in stable-updates. If you're using simple-cdd, I'm guessing it (or your config) is trying to include stable-updates too and that is the cause of your problem. As to how to do that, check the docs for simple-cdd. I can't help much with that, as I've never used it. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Re: Planning for 12.5/11.9
On Tue, Dec 19, 2023 at 09:25:06PM +, Jonathan Wiltshire wrote: >Hi, > >It's time to set a date for 12.5 (taking account of the emergency .4) and >11.9. I expect this to be the penultimate update for bullseye before LTS. > >Please indicate availability for: > > Saturday 3rd February (preferred for cadence) > Saturday 10th February > Saturday 17th February Any of those *should* be OK for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Re: Mounting EFI partition: default to `uid=0,gid=0`
[ Argh, please turn off the crappy auto-encryption with your protonmail setup. It's utterly pointless when discussion is going to a mailing list too... ] Hi Danny, On Tue, Nov 21, 2023 at 07:20:31PM +, Danny van Heumen wrote: >On Nov 21, 2023, 4:59 PM, Steve McIntyre < st...@einval.com> wrote: >>In normal use, the EFI partition isn't mounted by a user. What are >>you trying to solve here? > >I wanted to make the partition user-mountable such that I can mount >it before upgrading packages. The partition would not be mounted by >default. (\`noauto,users\`) Then I found out that it defaults to >ownership of mounting users, which is not good. > >As I mentioned previously, I would argue that the ESP should always >mount with owner 0, even if my use case/experiment itself is an >outlier. I spotted my mistake, but was surprised by how owner is >chosen (in such a case). > >Yes, even when using sudo this shouldn't be a problem, however the >behavior does deviate from other filesystems which have their own >permission bits therefore have "protection" (maybe a strong word) >against this situation. Debian's standard installation setup works here as expected. If you want to break that, then I think it's up to you to handle the consequences I'm afraid. You're *already* modified the fstab to do what you want, you get to make the other changes you want too. OK? -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Re: Mounting EFI partition: default to `uid=0,gid=0`
On Tue, Nov 21, 2023 at 03:16:42PM +, Danny van Heumen wrote: >Hi, > >AFAICT, there was no follow-up to this. Does this mean that it is >preferred that ownership is determined solely by the user who mounts >the EFI partition? In normal use, the EFI partition isn't mounted by a user. What are you trying to solve here? -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Re: usr-merge in debian-installer
On Thu, Nov 16, 2023 at 06:06:00PM +0100, John Paul Adrian Glaubitz wrote: >Hi! > >I just built updated installation images for Debian Ports and noticed that the >generated /init script tried to start "start-udev" from /lib/debian-installer/ >instead of /usr/lib/debian-installer which naturally fails. > >I could figure out so far where the path names for tools in the /init script >are set. > >Does anyone have any idea where to look? I've just merged https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/39 from Helmut (thanks!) which should in theory do everything we need. The first salsa CI build has failed after that merge, but AFAICS this isn't to blame... -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: Planning for 12.3
On Fri, Oct 27, 2023 at 11:28:21AM +0100, Steve McIntyre wrote: >Argh, forgot to respond to this. :-( > >On Sat, Oct 07, 2023 at 06:59:03PM +0100, Jonathan Wiltshire wrote: >>Hi, >> >>The next point release for bookworm should be around the end of November >>2023. We're about a week behind cadence anyway, but I already know the 28th >>November will be unsuitable (Cambridge mini-debconf) and the weekend >>following is probably recovery time for a lot of people. >> >>Much after that we get into holidays and well off cadence. >> >>How about: >> 4th December (better for cadence) >> 11th December (more likely suitable in practice) > >Both of those currently look feasible for me. Do we have a decision being made yet please? -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Re: Planning for 12.3
Argh, forgot to respond to this. :-( On Sat, Oct 07, 2023 at 06:59:03PM +0100, Jonathan Wiltshire wrote: >Hi, > >The next point release for bookworm should be around the end of November >2023. We're about a week behind cadence anyway, but I already know the 28th >November will be unsuitable (Cambridge mini-debconf) and the weekend >following is probably recovery time for a lot of people. > >Much after that we get into holidays and well off cadence. > >How about: > 4th December (better for cadence) > 11th December (more likely suitable in practice) Both of those currently look feasible for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Bug#1054459: debian-installer: Debian 12.2 amd64 netinst failes to find a kernel image for a Dell 7812
Hi David, On Mon, Oct 23, 2023 at 10:02:44PM -0700, David George Henderson III wrote: >Package: debian-installer >Version: debian installer found on amd64 12.2 netinst.iso >Severity: important > >Dear Maintainer, > >I have several systems and have experienced this difficulty only with the >Dell 7812 with an Xeon E5 CPU. > >The debian 12.2.0 amd64 netinst.iso boots normally and seems to start >normally. > When it gets to finding a kernel to install, it complains that it cannot >find a suitable kernel. > >I had the same results with debian 12.2 adm64 dvd-1.iso and dlbd-1.iso That's very odd. I can't reproduce this here in simple testing in a VM, and there shouldn't be anything system-specific here. Could you please test again and grab the installer syslog for us? That'll help us to see what's going wrong here. > When I booted the debian 12.2 amd64 live.iso system, its installer ran OK. >I am running on the system installed from the live installer right now. This >is what made the lspci. > >I also successfully managed to perform a dist-upgrade from an install of >debian 11.6. -- Steve McIntyre, Cambridge, UK.st...@einval.com "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." -- Bruce Schneier
Re: reiserfsprogs udebs
On Tue, Sep 19, 2023 at 12:37:41PM +0200, Cyril Brulebois wrote: >Felix Zielcke (2023-09-19): >> Am 18.09.2023 22:23, schrieb Pascal Hambourg: >> > On 18/09/2023 at 19:20, Cyril Brulebois wrote: >> > > >> > > I would think so, yes. If that's not too much of a hassle, maybe >> > > wait a >> > > few days in case someone can think of a clever case where keeping them >> > > would make sense; but seeing it unsupported upstream, with the partman >> > > part removed already, I can't see why that would be the case… >> > >> > Rescue mode ? >> >> But then it still would make sense, to at least remove the >> mkreiserfsprogs-udeb >> The reiserfsprogs-udeb which contains fsck maybe could be kept. > >While it can do that as well (to some extent), the installer's primary >focus isn't to rescue systems but to install new ones; there are better >tools for that anyway. > >Since the plan for mainline is to eventually drop support for ReiserFS, >I don't think we should actively keep support for it “just in case >someone needs to rescue a system”. If some user really wants to use d-i >for that, we have a very wide range of versions available. Agreed, let's just kill it here. -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Bug#1051964: adding a local preseed file into the initrd breaks CD/USB media usage
Source: debian-installer-utils Version: 1.147 Severity: normal I'm hacking together an installer for an rpi4 locally, copying all the files onto a FAT-formatted USB drive. I also want to do some minor config in a preseed late_command, so I've modified the initrd to add a preseed file. Unfortunately, once I added the preseed file d-i fails in cdrom-detect. Digging further, I've found that this is because the USB drive is already mounted on /media. This is caused by the "fetch-url" command in preseed/preseed_fetch. In fetch-url-methods/file, we call mountmedia to allow for preseed via USB from netboot - see commit 916a613577c5cd747d15b3d20f16b9518d7d54ea in 2013!! This mountmedia is not needed in my case, and is what's breaking things. As a workaround, I've added a preseed early_command for now to *unmount* /media and all is well. But this code needs changing to not run mountmedia unconditionally! We already had a report from Bogdan Veringioiu about this problem back in 2018... :-( [1] [1] https://lists.debian.org/debian-boot/2018/04/msg00057.html -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-23-amd64 (SMP w/8 CPU threads) Kernel taint flags: 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
Re: Daily d-i images for i386 not being built?
On Tue, Sep 05, 2023 at 09:53:38PM +0200, Holger Wansing wrote: >Hi, > >Cyril Brulebois wrote (Wed, 30 Aug 2023 22:33:08 +0200): >> Holger Wansing (2023-08-30): >> > So you mean a changing like attached... >> >> I'm so sorry, I had assumed the other image section was built using a >> loop on devel image list, that's why I thought we'd need an addition >> there. Since that's using an hardcoded list of download links, no need >> to change that, and the single change required is adjusting devel and >> trixie images list? > >Done. >https://salsa.debian.org/webmaster-team/webwml/-/commit/b943a80cdd64fe6421d841054d7fae8fc0768ede > > >BTW: mipsel CD (netinst) images are no longer being built apparently? >Can they be removed as well? Yes. >The netboot images for mipsel seem to stay, as it is for i386? No, mipsel is going away totally. We'll be killing it completely from trixie, archive-wide. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Rarely is anyone thanked for the work they did to prevent the disaster that didn’t happen.” -- Mikko Hypponen (https://twitter.com/mikko/)
Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty
On Wed, Jul 12, 2023 at 11:15:57AM +0200, Cyril Brulebois wrote:
>Hi Michael,
>
>Cyril Brulebois (2023-06-28):
>> Control: reassign -1 busybox-udeb 1:1.36.1-3
>
>[…]
>
>> With a local build, confirmed -3 is buggy, and that reverting only
>> busybox-udeb to -1 is sufficient to restore syslog support in the
>> installer.
>>
>> Reassigning there; the GRUB thing can be filed separately once we have
>> actual information via syslog.
>
>A fix would be appreciated, we've got reports piling up about things we
>have no logs for.
After weeks with this breakage, I've just uploaded a minimal NMU to
fix it, reverting the syslog changes since -1. I've buit and tested
successfully locally.
Here's the NMU diff.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...
diff -Nru busybox-1.36.1/debian/changelog busybox-1.36.1/debian/changelog
--- busybox-1.36.1/debian/changelog 2023-06-14 22:01:54.0 +0100
+++ busybox-1.36.1/debian/changelog 2023-08-03 21:22:44.0 +0100
@@ -1,3 +1,11 @@
+busybox (1:1.36.1-3.1) unstable; urgency=medium
+
+ * NMU
+ * Revert recent changes that have broken syslogd in d-i.
+Closes: #1039710
+
+ -- Steve McIntyre <93...@debian.org> Thu, 03 Aug 2023 21:22:44 +0100
+
busybox (1:1.36.1-3) unstable; urgency=medium
* syslogd-avoid-nulling-devlog.patch - fix overriding dev/log
diff -Nru busybox-1.36.1/debian/patches/series
busybox-1.36.1/debian/patches/series
--- busybox-1.36.1/debian/patches/series2023-06-14 21:55:08.0
+0100
+++ busybox-1.36.1/debian/patches/series2023-08-03 21:22:44.0
+0100
@@ -14,6 +14,7 @@
platform-linux.diff
fix-non-linux-build.patch
#
-syslogd-decrease-stack-usage-50-bytes.patch
-syslogd-daemonize-after-init-make-errs-visible.patch
-syslogd-avoid-nulling-devlog.patch
+syslogd-fork-after-init-not-before.patch
+#syslogd-decrease-stack-usage-50-bytes.patch
+#syslogd-daemonize-after-init-make-errs-visible.patch
+#syslogd-avoid-nulling-devlog.patch
diff -Nru
busybox-1.36.1/debian/patches/syslogd-fork-after-init-not-before.patch
busybox-1.36.1/debian/patches/syslogd-fork-after-init-not-before.patch
--- busybox-1.36.1/debian/patches/syslogd-fork-after-init-not-before.patch
1970-01-01 01:00:00.0 +0100
+++ busybox-1.36.1/debian/patches/syslogd-fork-after-init-not-before.patch
2023-08-03 21:22:44.0 +0100
@@ -0,0 +1,58 @@
+From: Michael Tokarev
+Date: Tue, 6 Jun 2023 17:08:18 +0300
+Subject: [PATCH] syslogd: fork after init on a regular system, not before
+
+Current syslogd performs all init after daemonizing, meanwhile
+main process exits successfully. This means any errors during init
+will not be even shown up because at this time the process has its
+stderr redirected to /dev/null already.
+
+On a MMU system, delay daemonizing to after init.
+On non-MMU system, keep current code.
+
+Signed-off-by: Michael Tokarev
+---
+ sysklogd/syslogd.c | 13 -
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/sysklogd/syslogd.c b/sysklogd/syslogd.c
+index 6ddfd771a..2f9a727cd 100644
+--- a/sysklogd/syslogd.c
b/sysklogd/syslogd.c
+@@ -1025,7 +1025,6 @@ static void do_syslogd(void)
+ signal(SIGALRM, do_mark);
+ alarm(G.markInterval);
+ #endif
+- xmove_fd(create_socket(), STDIN_FILENO);
+
+ if (option_mask32 & OPT_circularlog)
+ ipcsyslog_init();
+@@ -1033,6 +1032,16 @@ static void do_syslogd(void)
+ if (option_mask32 & OPT_kmsg)
+ kmsg_init();
+
++ {
++ int fd = create_socket();
++#if BB_MMU
++ if (!(option_mask32 & OPT_nofork)) {
++ bb_daemonize(DAEMON_CHDIR_ROOT);
++ }
++#endif
++ xmove_fd(fd, STDIN_FILENO);
++ }
++
+ timestamp_and_log_internal("syslogd started: BusyBox v" BB_VER);
+ write_pidfile_std_path_and_ext("syslogd");
+
+@@ -1179,9 +1188,11 @@ int syslogd_main(int argc UNUSED_PARAM, char **argv)
+ G.hostname = safe_gethostname();
+ *strchrnul(G.hostname, '.') = '\0';
+
++#if !BB_MMU
+ if (!(opts & OPT_nofork)) {
+ bb_daemonize_or_rexec(DAEMON_CHDIR_ROOT, argv);
+ }
++#endif
+
+ do_syslogd();
+ /* return EXIT_SUCCESS; */
Re: installation-guide: MS-DOS and Windows
On Thu, Aug 03, 2023 at 10:03:34PM +0200, Holger Wansing wrote: >Hi all, > >I'm planning to do some changings to finally remove MS-DOS from the doc and >make some unification regarding the different Windows versions. > > >A patch is attached. LGTM! -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Re: 11.8/12.2 planning
Apologies, I don't think I've responded to this yet :-( On Mon, Jul 24, 2023 at 07:25:13PM +0100, Jonathan Wiltshire wrote: >I think I confused matters with my messy thread; let's start again. > >I originally suggested: > >Jonathan Wiltshire (2023-06-28): >> The proper cadence for 11.8 and 12.2 is the weekend of 30th September >> 2023. Please indicate your availability for: >> >> 23 Sep >> 30 Sep (preferred) >> 7 Oct > >Let's say 30 Sep is still preferred, 7th Oct or at a stretch 14th Oct are >options. Please indicate your availability for those three. 23rd and 7th are fine, 30th may be more awkward for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Bug#1042563: installation-reports: installation OK, screen remains blank during boot and GDM Greeter
>dmidecode: Port Connector Information >dmidecode: Internal Reference Designator: J6A1 >dmidecode: Internal Connector Type: None >dmidecode: External Reference Designator: Audio Line In >dmidecode: External Connector Type: Mini Jack (headphones) >dmidecode: Port Type: Audio Port >dmidecode: >dmidecode: Handle 0x0010, DMI type 8, 9 bytes >dmidecode: Port Connector Information >dmidecode: Internal Reference Designator: J6B1 - AUX IN >dmidecode: Internal Connector Type: On Board Sound Input From CD-ROM >dmidecode: External Reference Designator: Not Specified >dmidecode: External Connector Type: None >dmidecode: Port Type: Audio Port >dmidecode: >dmidecode: Handle 0x0011, DMI type 8, 9 bytes >dmidecode: Port Connector Information >dmidecode: Internal Reference Designator: J6B2 - CDIN >dmidecode: Internal Connector Type: On Board Sound Input From CD-ROM >dmidecode: External Reference Designator: Not Specified >dmidecode: External Connector Type: None >dmidecode: Port Type: Audio Port >dmidecode: >dmidecode: Handle 0x0012, DMI type 11, 5 bytes >dmidecode: OEM Strings >dmidecode: String 1: 5404A62B4BF0 >dmidecode: String 2: 11233067003704011122659206870 >dmidecode: String 3: 90OAM3JB26111A81E139Q >dmidecode: String 4: 742F68ED2829 >dmidecode: >dmidecode: Handle 0x0013, DMI type 13, 22 bytes >dmidecode: BIOS Language Information >dmidecode: Language Description Format: Long >dmidecode: Installable Languages: 1 >dmidecode: en|US|iso8859-1 >dmidecode: Currently Installed Language: en|US|iso8859-1 >dmidecode: >dmidecode: Handle 0x0014, DMI type 15, 35 bytes >dmidecode: System Event Log >dmidecode: Area Length: 4 bytes >dmidecode: Header Start Offset: 0x >dmidecode: Header Length: 2 bytes >dmidecode: Data Start Offset: 0x0002 >dmidecode: Access Method: Indexed I/O, one 16-bit index port, one 8-bit >data port >dmidecode: Access Address: Index 0x046A, Data 0x046C >dmidecode: Status: Invalid, Not Full >dmidecode: Change Token: 0x >dmidecode: Header Format: No Header >dmidecode: Supported Log Type Descriptors: 6 >dmidecode: Descriptor 1: End of log >dmidecode: Data Format 1: OEM-specific >dmidecode: Descriptor 2: End of log >dmidecode: Data Format 2: OEM-specific >dmidecode: Descriptor 3: End of log >dmidecode: Data Format 3: OEM-specific >dmidecode: Descriptor 4: End of log >dmidecode: Data Format 4: OEM-specific >dmidecode: Descriptor 5: End of log >dmidecode: Data Format 5: OEM-specific >dmidecode: Descriptor 6: End of log >dmidecode: Data Format 6: OEM-specific >dmidecode: >dmidecode: Handle 0x0015, DMI type 16, 15 bytes >dmidecode: Physical Memory Array >dmidecode: Location: System Board Or Motherboard >dmidecode: Use: System Memory >dmidecode: Error Correction Type: None >dmidecode: Maximum Capacity: 2 GB >dmidecode: Error Information Handle: Not Provided >dmidecode: Number Of Devices: 1 >dmidecode: >dmidecode: Handle 0x0016, DMI type 19, 15 bytes >dmidecode: Memory Array Mapped Address >dmidecode: Starting Address: 0x000 >dmidecode: Ending Address: 0x0007FFF >dmidecode: Range Size: 2 GB >dmidecode: Physical Array Handle: 0x0015 >dmidecode: Partition Width: 4 >dmidecode: >dmidecode: Handle 0x0017, DMI type 17, 28 bytes >dmidecode: Memory Device >dmidecode: Array Handle: 0x0015 >dmidecode: Error Information Handle: Not Provided >dmidecode: Total Width: 64 bits >dmidecode: Data Width: 64 bits >dmidecode: Size: 2048 MB >dmidecode: Form Factor: SODIMM >dmidecode: Set: None >dmidecode: Locator: DIMM0 >dmidecode: Bank Locator: BANK0 >dmidecode: Type: DDR3 >dmidecode: Type Detail: Synchronous >dmidecode: Speed: 667 MT/s >dmidecode: Manufacturer: Manufacturer00 >dmidecode: Serial Number: SerNum00 >dmidecode: Asset Tag: AssetTagNum0 >dmidecode: Part Number: ModulePartNumber00 >dmidecode: Rank: Unknown >dmidecode: >dmidecode: Handle 0x0018, DMI type 20, 19 bytes >dmidecode: Memory Device Mapped Address >dmidecode: Starting Address: 0x000 >dmidecode: Ending Address: 0x0007FFF >dmidecode: Range Size: 2 GB >dmidecode: Physical Device Handle: 0x0017 >dmidecode: Memory Array Mapped Address Handle: 0x0016 >dmidecode: Partition Row Position: 1 >dmidecode: Interleaved Data Depth: 1 >dmidecode: >dmidecode: Handle 0x0019, DMI type 32, 20 bytes >dmidecode: System Boot Information >dmidecode: Status: No errors detected >dmidecode: >dmidecode: Handle 0x001A, DMI type 41, 11 bytes >dmidecode: Onboard Device >dmidecode: Reference Designation: To Be Filled By O.E.M. >dmidecode: Type: Video >dmidecode: Status: Enabled >dmidecode: Type Instance: 0 >dmidecode: >dmidecode: Handle 0x001B, DMI type 41, 11 bytes >dmidecode: Onboard Device >dmidecode: Reference Designation: To Be Filled By O.E.M. >dmidecode: Type: SCSI Controller >dmidecode: Status: Disabled >dmidecode: Type Instance: 0 >dmidecode: >dmidecode: Handle 0x001C, DMI type 127, 4 bytes >dmidecode: End Of Table >dmidecode: >/proc/fb: 0 VESA VGA > > -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
Hi, and thanks for your bug report! On Mon, Jul 10, 2023 at 05:27:50PM +0200, yogg wrote: >Package: installation-reports >Severity: serious >Tags: d-i >Justification: https://wiki.debian.org/MachineId > ... >After installation was finished and the system has been restarted the >files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not linked >in any way (no soft or hardlink) and the ID inside the files differ >from each other. I've confirmed this bug just now, doing a clean installation from the 12.0.0 amd64 netinst. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Re: Strange MBR CHS partition values created by debian-installer
Hi Valdikss, On Sat, Jul 08, 2023 at 09:17:54PM +0300, ValdikSS wrote: >Hello list, > >I was getting very slow boot speeds on old WYSE C10LE thin client with VIA C7 >CPU and Phoenix bios (year 2008). This is due to combination of BIOS, GRUB, >and what I assume Debian-installer bugs. > >Long story short, Debian writes strange/incorrect C/H/S values to the MBR >partition table upon installation, to which testdisk software complains as >"Bad relative sector". Nothing should be caring about C/H/S at all in the 21st century. Using C/H/S only allows you to access 515MB of disk [1]. *Everything* these days uses LBA instead. What makes you think that the BIOS on this old machine cares about C/H/S? What happens if you tweak the partitioning by hand when installing? >I've tried to install Debian 12 i386 to a 8G disk, using qemu, with guided >automatic partitioning. Testdisk data right after the installation: > >> Disk testz.img - 8589 MB / 8192 MiB - CHS 1045 255 63 >> Current partition structure: >> Partition StartEndSize in sectors >> >> 1 P Linux0 32 33 919 199 48 14774272 >> >> Bad relative sector. >> 2 E extended 919 232 16 1044 52 321996802 >> >> Bad relative sector. >> No partition is bootable >> 5 L Linux Swap 919 232 18 1044 52 321996800 >> >> Bad relative sector. > > >It seems that testdisk automatically recalculates C/H/S values and shows >corrected data (in the table above). > >Here's what really is present in the MBR (data of the first partition entry): > >> $ ./mbr_my.py testz.img Status: 0x0 >> C/H/S start: 4 4 1 >> Part type: 0x83 >> C/H/S end: 1023 254 2 >> LBA of first sector: 2048 >> Sector count:14774272 > > >fdisk/cfdisk and parted all create partitions for which testdisk does not >complain. d-i drives parted to make partitions... [1] https://forums.tomshardware.com/threads/lba-chs-bios-prob.685748/ -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Bug#1039872: Improve firmware package inclusion
On Wed, Jul 05, 2023 at 08:30:03AM +0200, Pascal Hambourg wrote: >On 05/07/2023 at 00:50, Steve McIntyre wrote: >> >> I think that's quite a result! Comparing the ISOs, the differences are >> just 5 missing firmware debs: >> >> firmware-nvidia-gsp_525.116.04-1_amd64.deb >> firmware-nvidia-tesla-gsp_525.105.17-2_amd64.deb >> firmware-qcom-soc_20230515-2_all.deb >> firmware-samsung_20230515-2_all.deb >> raspi-firmware_1.20220830+ds-1_all.deb > >As mentioned in #1032071, AFAICS firmware-ti-connectivity also contains >ARM-only firmware. Hmmm, OK. The description isn't 100% clear here. I'll filter it now for non-arm as well. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Bug#1039872: Improve firmware package inclusion
On Thu, Jun 29, 2023 at 06:17:49AM +0100, Steve McIntyre wrote: >Package: debian-installer >Severity: normal > >As mentioned in #1038440 and elsewhere, some of our media builds are >too big and this is mostly due to inclusion of firmware packages. Some >growth is not unexpected, but we're including firmware packages that >are not useful, e.g.: > > * nvidia firmware packages from the nvidia-graphics-drivers* source > package are not useful without non-free drivers that we're not > shipping in our images > (https://lists.debian.org/debian-boot/2023/01/msg00157.html) > * we're currently including raspi-firmware for all arches, while it's > only useful for arm* > >I think we could really do with some extra metadata for the firmware >packages to help us determine what to include on media. Maybe: > > * "this firmware works/does not work with free drivers in Debian" > * "this is generic firmware, useful for all arches" > * "this firmware is useful for arches <> only" > >What other information would be helpful? > >In the meantime, I'm about to add support for firmware-ignore list(s) >in debian-cd. And I've just pushed that into unstable now - see commit 1824a6693304cd8923da288610c378b6b18ed62a . The difference is clear, comparing amd64 trixie netinst images: before: -rw-r--r-- 1 debian-cd debian-cd 788529152 Jul 4 15:14 sid_d-i/20230704-5/amd64/iso-cd/debian-testing-amd64-netinst.iso after: -rw-r--r-- 1 debian-cd debian-cd 673185792 Jul 4 17:05 sid_d-i/20230704-6/amd64/iso-cd/debian-testing-amd64-netinst.iso I think that's quite a result! Comparing the ISOs, the differences are just 5 missing firmware debs: firmware-nvidia-gsp_525.116.04-1_amd64.deb firmware-nvidia-tesla-gsp_525.105.17-2_amd64.deb firmware-qcom-soc_20230515-2_all.deb firmware-samsung_20230515-2_all.deb raspi-firmware_1.20220830+ds-1_all.deb -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Bug#1036400: partman-jfs: JFS is on its way out, please remove from the installer
On Fri, Jun 30, 2023 at 04:56:37PM +0200, Adam Borowski wrote: >On Sun, May 21, 2023 at 07:35:36AM +0200, Cyril Brulebois wrote: >> Adam Borowski (2023-05-20): >> > The JFS filesystem is deprecated in the kernel: on life support since 2009 >> > and with talks of removal altogether. Thus, we really shouldn't offer to >> > format new setups with it. There are people who kind-of remember JFS being >> > the fastest back in the day, and it's irresponsible to set them for failed >> > upgrades past Bookworm. >> > >> > Thus: please remove JFS from the installer. >> >> It doesn't seem reasonable to do that weeks away from the release, without >> any kind of heads-up. That can be done during the Trixie release cycle, >> e.g. in Alpha 1. > >Aye, sorry for having distracted you during the most busy time. I filed the >bug when I learned about plans of giving JFS the axe. > >> Feel free to ping this bug report a few weeks/months into the next release >> cycle > >So... it might be a better time now. Agreed, we'll pick this up shortly. -- Steve McIntyre, Cambridge, UK.st...@einval.com "The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." -- Bertrand Russell
Bug#1039872: Improve firmware package inclusion
Package: debian-installer Severity: normal As mentioned in #1038440 and elsewhere, some of our media builds are too big and this is mostly due to inclusion of firmware packages. Some growth is not unexpected, but we're including firmware packages that are not useful, e.g.: * nvidia firmware packages from the nvidia-graphics-drivers* source package are not useful without non-free drivers that we're not shipping in our images (https://lists.debian.org/debian-boot/2023/01/msg00157.html) * we're currently including raspi-firmware for all arches, while it's only useful for arm* I think we could really do with some extra metadata for the firmware packages to help us determine what to include on media. Maybe: * "this firmware works/does not work with free drivers in Debian" * "this is generic firmware, useful for all arches" * "this firmware is useful for arches <> only" What other information would be helpful? In the meantime, I'm about to add support for firmware-ignore list(s) in debian-cd. -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-22-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
Re: 11.8/12.2 planning
On Wed, Jun 28, 2023 at 10:09:42AM +0200, Cyril Brulebois wrote: >Jonathan Wiltshire (2023-06-28): >> The proper cadence for 11.8 and 12.2 is the weekend of 30th September >> 2023. Please indicate your availability for: >> >> 23 Sep >> 30 Sep (preferred) >> 7 Oct > >I should be able to make any of those work for the installer team, and >optionally for the images team. 23rd and 7th are fine, 30th may be more awkward for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: wrong sha256sum
Hi! On Sun, Jun 25, 2023 at 05:05:07PM +, rudi wrote: >my shs256sum > >3b0e9718e3653435f20d8c2124de6d363a51a1fd7f911b9ca0c6db6b3d30d53e >debian-12.0.0-amd64-netinst.iso > >https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/SHA512SUMS > >b462643a7a1b51222cd4a569dad6051f897e815d10aa7e42b68adc8d340932d861744b5ea14794daa5cc0ccfa48c51d248eda63f150f8845e8055d0a5d7e58e6 >debian-12.0.0-amd64-netinst.iso You're looking in the wrong file - see SHA256SUMS. Both the checksums are correct, sha256sum and sha512sum are different algorithms. -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Re: 11.8 planning
On Sat, Jun 24, 2023 at 03:17:22PM +0100, Jonathan Wiltshire wrote: >On Tue, Jun 20, 2023 at 06:15:30PM +0100, Adam D. Barratt wrote: >> The traditional cadence for oldstable point releases is four months, >> rather than two. That technically means that 11.8 would be due >> somewhere in late August to mid-September. So we could either punt 11.8 >> so it aligns with 12.2 rather than 12.1, or do 11.8 together with 12.1 >> and then align 11.9 with 12.3. >> >> I think I'd prefer the latter option, i.e. we do 11.8+12.1 in July, >> 12.2 probably September, then 11.9+12.3 Novemberish. >> > >Yes, I had forgotten about the transition to oldstable candece. I was going >to suggest, though, that 11.8 gets pushed back to cadence with 12.2 and we >just do 12.1 on its own first. How does that sound? WFM. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: 11.8 planning
On Mon, Jun 19, 2023 at 10:02:27PM +0100, Jonathan Wiltshire wrote: >Hi, > >I'm sending this separately to a similar mail for 12.1. That's because the >timings are far enough out that they would make sense on separate weekends, >but they could also be stretched[1] and combined. > >Two months from 29th April is around the 1st July, so I propose: > >1st July >8th July >15th July at a push > > >1: a shame that joke hasn't worked for some years now 1st July is out for me, but I can do the others fine. -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Re: 12.1 planning
On Mon, Jun 19, 2023 at 10:04:06PM +0100, Jonathan Wiltshire wrote: >Hi, > >The promised 4-6 weeks following release for 12.1 looks like: > > 8th July (4) >15th July (5) >22nd July (6) > >The first of them would combine with a very stretched 11.8; SRM might >prefer to get 11.8 done earlier and leave more time for 12.1 to mature. All of those work for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Bug#1036371: debian-installer: Blu-ray double-level iso is too large to burn to DLBD disk
Hi Bud, On Sat, May 20, 2023 at 02:54:00AM -0400, Bud Heal wrote: >Package: debian-installer >Version: 20210731+deb11u8 >Severity: important >Tags: d-i >X-Debbugs-Cc: budheal...@gmail.com > >Dear Maintainer, > > * What led up to the situation? >Since the DLBD .iso install neither sets up sources.list with a mirror to >download from nor requests more disks to complete the set, a test of the >DLBD install when using actual Blu-ray disks were in order. > * What exactly did you do (or not do) that was effective (or > ineffective)? >RC3, packaged at 61-62GB per volume, can not be burned into DLBD media. Just looking at the files on the server, those numbers surprise me... debian-bookworm-DI-rc3-amd64-DLBD-1.jigdo:# Image size 48415279104 bytes debian-bookworm-DI-rc3-amd64-DLBD-2.jigdo:# Image size 44362018816 bytes Could you show exactly what size your images are coming out as, please? -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Re: dosfstools for EFI partition?
On Sun, May 14, 2023 at 08:39:24AM +0200, Cyril Brulebois wrote: >Hi, > >Richard Hector (2023-05-14): >> Hopefully this is the right, or close enough, place ... >> >> Given that EFI is common, should dosfstools now be a standard package, >> so that we can fsck the partition when required? >> >> Happy to file as a bug, if I know what to file it against. > >I'm not familiar with the whole machinery but at least one component >looks like it was meant to do the job: > > https://salsa.debian.org/installer-team/partman-basicfilesystems/-/blob/master/finish.d/aptinstall_basicfilesystems#L37-39 > >Whether any of this works remains to be confirmed; if that code is still >active, it might just need to be taught about some EFI-specific case. > >I'd file a bug report there if I were you, thanks already. Oh wow, that code is ancient and clearly is not picking up on the ESP. I'll fix that now. Richard: thanks for reporting! -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: Translation updates for grub-installer
On Thu, May 11, 2023 at 10:52:41PM +0200, Holger Wansing wrote: >Hi, > >Steve McIntyre wrote (Thu, 11 May 2023 00:40:40 +0100): >> Here's a big set of extra translations... > >Thanks. > > >> From: Kevin Scannell >> To: Steve McIntyre >> Cc: Irish >> Subject: Re: grub-installer 1.189: Please update debconf PO translation for >> the package grub-installer >> Date: Tue, 25 Apr 2023 06:41:56 -0500 >> >> >> >> Hi Steve, >> >> Translated file attached. >> >> Best regards >> Kevin > >Here I see, that a call for translation update was sent to previous translators >for the grub-installer package. >Maybe this happened in a semi-automated way together with a package upload >or similar, but for packages under the hood of debian-installer it does not >make sense, to sent such calls, at least not in this form quoted above: >If such a call is sent, it should point to the "master po files" in the >d-i repo: >https://salsa.debian.org/installer-team/d-i/-/tree/master/packages/po >and not to the po files of the individual packages. The master po files are >the only files, where translators should work on!!! >Maybe some workflow has to be adapted somewhere, to avoid such calls? > >Sorry for the noise, if you are already aware of this :-) Argh, sorry. I used podebconf-report-po and that seems to be a trap for d-i packages... :-/ -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: Tags and l10n uploads
On Wed, May 10, 2023 at 10:03:27PM +0200, Holger Wansing wrote: >Hi, > >Am 10. Mai 2023 21:04:35 MESZ schrieb Steve McIntyre : >>On Wed, May 10, 2023 at 06:22:53PM +0200, Cyril Brulebois wrote: >>>Hey Holger, >>> >>>I've seen a bunch of uploads and refreshed master branches, but it looks >>>like we're missing a number of tags. Please push them when you have a >>>chance? Nothing time sensitive though. >>> >>>For what it's worth, once we get a little closer to the tentative release >>>dates, I start looking at https://d-i.debian.org/translations.txt and >>>uploading packages with l10n changes (as I did for previous releases). >>> >>>Hopefully between your uploads and mine, we won't be leaving any l10n work >>>behind! :) >>> >>>(There's even a script to help me spot + unblock l10n-only changes on the >>>release side, so that I can focus on reviewing the less easy packages.) >> >>I've still got a stack of grub-installer l10n updates that were just >>sent to me (AFAICS). What's the best way to apply those? > >I can take care of that. >Could you sent them here? Doing that now, thanks! -- Steve McIntyre, Cambridge, UK.st...@einval.com "The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." -- Bertrand Russell
Re: Tags and l10n uploads
On Wed, May 10, 2023 at 06:22:53PM +0200, Cyril Brulebois wrote: >Hey Holger, > >I've seen a bunch of uploads and refreshed master branches, but it looks >like we're missing a number of tags. Please push them when you have a >chance? Nothing time sensitive though. > >For what it's worth, once we get a little closer to the tentative release >dates, I start looking at https://d-i.debian.org/translations.txt and >uploading packages with l10n changes (as I did for previous releases). > >Hopefully between your uploads and mine, we won't be leaving any l10n work >behind! :) > >(There's even a script to help me spot + unblock l10n-only changes on the >release side, so that I can focus on reviewing the less easy packages.) I've still got a stack of grub-installer l10n updates that were just sent to me (AFAICS). What's the best way to apply those? -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: https://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Tue, May 09, 2023 at 09:53:54AM -0400, Lennart Sorensen wrote: >On Tue, May 09, 2023 at 12:22:02AM +0100, Pete Batard wrote: > >> 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. > >Well certainly devicetree makes the kernel and driver handling much >simpler and more consistent, but the boot loader on all the different >arm systems isn't standardized. Using UEFI on SBBR means a standard >grub2 uefi boot loader should work on any system, so that does seem >like a benefit. Of course that really just means UEFI might be a big >improvement, not that ACPI vs devicetree is. No idea if UEFI can work >with devicetree or not. Being an intel thing I would not be surprised >if ACPI is rather tied into it, since that would make sense. A quick >look at wikipedia says UEFI actually provides devicetree services on >RISC processor systems. I guess that makes sense since pretty much all >RISC systems seem to have used openfirmware or something similar so >their OS would expect that. Little endian only though of course. UEFI doesn't have to push ACPI, no. Indeed, some of the UEFI platforms out there (e.g. Macchiatobin) let you choose whether to pass on DT or ACPI to the boot loader / OS. AIUI the main reason that Microsoft went with ACPI on the Arm platform is just that they already had ACPI for x86. It's therefore much easier for them to push the same requirements onto new platforms, of course. DT for Arm is very much *not* just for Linux (see FreeBSD and other OSes, and of course various boot loaders). However, there is still an outstanding historical mess: lofs of Linux developers think that the DT configuration on various platforms is theirs to change as they please to suit the Linux kernel. The original DT plan was to only ever include DT sources with the Linux tree as a *temporary* thing until a reasonable number of platforms provided DT data directly from firmware. DT was just meant to be a static description *of the hardware*. But (like a lot of "temporary" things), we're now a lot of years later and there's no sign this is ever going to change. There's certainly no will to have a fight about this. Against that background, I genuinely think Microsoft have done the sensible thing by sticking to ACPI rather than embracing DT for Arm platforms... -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Bug#958218: update-grub fails to process more than one argument to initrd
Hi Krzmbrzl, On Mon, May 01, 2023 at 02:42:41PM +0200, Krzmbrzl wrote: >Hi everyone, > >In this report, there seems to be an indication that this issue was fixed >with grub2/2.04-5. At least that's how I interpret the auto-generated line >"No longer marked as found in versions grub2/2.04-5" that was somehow >triggered by Colin Watson (though when checking the respective mail, it seems >like that is only about reassignment and not about a resolution). > >In either case, I want to report that this issue still exists when having >grub2-common/2.06 installed (on Ubuntu 22.04), which comes with >os-prober/1.79. If you're seeing this in Ubuntu, then you'll need to talk to the Ubuntu developers. There are two parts to this, one in os-prober itself and one in GRUB. The os-prober part was fixed in version 1.80 in Debian. The fix in GRUB will be included shortly in Debian - see https://salsa.debian.org/grub-team/grub/-/commit/358e8faa1329e9ed3467f6f9cacaa781fc34a7b8 I'd suggest you ask the Ubuntu folks to pick that up. >Furthermore, I can explain exactly where this issue occurs. I have written up >a question on the Unix StackExchange about this, that contains the >explanation: https://unix.stackexchange.com/q/744624/203826 ACK. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver
On Tue, May 02, 2023 at 07:27:05AM +, Schwibinger Michael wrote: > EPSON ET M 1120 new printer: If You can read this, you are using the wrong >driver > > >Good morning. >Somebody here familiar with a printer? > >Regards >Sophie This is not the correct list for user support. Please go back to debian-user or debian-german. -- 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
Bug#1035096: installation-report Bookworm RC2 GRUB not installed
On Sat, Apr 29, 2023 at 08:51:48AM -0700, Peter Ehlert wrote: > >On 4/29/23 07:23, Steve McIntyre wrote: >> Hi Peter, >> >> Could you please share a copy of the installer logs? You should be >> able to find them in /var/log/installer on the installed system. >there is no file "installer" in /var/log Right, it's a directory with multiple files in it. Could you also share the other files please? >I found /var/log/installer/syslog Thanks... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Bug#1035096: installation-report Bookworm RC2 GRUB not installed
itial boot worked: [E ] >Configure network HW: [O ] >Config network: [O ] >Detect CD: [O ] >Load installer modules: [O ] >Detect hard drives: [O ] >Partition hard drives: [O ] >Create file systems: [O ] >Mount partitions: [O ] >Install base system: [O ] >Install boot loader: [O ] >Reboot: [E ] > >Comments/Problems: > >Legacy aka BIOS booting >system has 4 physical disk drives, all GPT partition tables >only one drive has a partition with bios_grub > >install was on a drive without bios_grub > >when install was finished, a list of drives was displayed, asking where to >install GRUB. >the install drive was highlighted >I selected the drive with bios_grub >the display showed "installing GRUB on (...drive it was installed on...) > >(several other OS's are on that drive if that matters) > >reboot gave me the Old GRUB menu, not including my new system. > >boot from another OS: ># grub-install /dev/sde && update-grub >now my GRUB menu includes the new system > >system now boots and runs as expected > >PS: this is repeatable. >Tried it on a couple other machines with a similar install procedure. >Same experience with the RC1 netinstall and the RC1 live ISO > > -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Debian installer can't install Debian testing in VirtualBox when EFI enabled
*Please* reply to all and respond to the debian-boot list, I'm not the only person working on stuff here... On Thu, Apr 20, 2023 at 12:45:17PM +0800, Licheng Hsu wrote: >Hi > >> Thanks, it does. It seems there's a problem with video setup and it's >> not starting X. What options do you have under Display? > >There're 4 options to choose from "Graphics Controller" in VirtualBox. >They're VBoxVGA, VMSVGA, VBoxSVGA, and None. VirtualBox suggests >VMSVGA, but they all don't work. Hmmm. >> If you start with "Install" rather than "Graphical Install" then that >> should work for now. > >I have tried "Install", even "Expert install" in "Advanced >options...", but still doesn't work. They all end with blank gray >screen just as the videos I attached show. Argh. I've no idea what's going on here... :-( >"Graphical rescue mode" or "Rescure mode" in "Advanced options..." >doesn't work, neither. > >By the way, thanks for your hard work. You're welcome! -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Bug#1030938: os-prober: Does not detect OpenSuse Tumbleweed
Hi Frank, On Thu, Feb 09, 2023 at 11:58:58AM -0500, Frank McCormick wrote: >Package: os-prober >Version: 1.81 >Severity: wishlist >X-Debbugs-Cc: bea...@videotron.ca > > >Debian Sid updated Grub today and when os-prober ran via update-grub it did >not detect >my OpenSuse Tumbleweed partition. >The update had installed the new Grub so I could not boot into >Tumbleweed. > >Now I have held all the grub packages so I won't be faced >with this again. The Tumbleweed grub installation and it's version >of os-prober does detect both Debian and Fedora on another partition. >FYI Fedoras os-prober also doesn't detect Tumbleweed but that's a >problem I'll report to them. This is most likely a grub issue - the defaults have changed to *not* run os-prober by default. If so, edit /etc/default/grub and set GRUB_DISABLE_OS_PROBER=false then run update-grub this will fix your problem. Or run dpkg-reconfigure on your grub package (either grub-pc or grub-efi-amd64) and the latest grub packages will ask you about os-prober. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Re: 11.7 planning + bookworm planning
On Sun, Apr 23, 2023 at 09:13:40PM +0200, Paul Gevers wrote: >Hi all, > >Let's book June 10 as the bookworm release date. A more formal announcement >will follow. \o/ -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: 11.7 planning + bookworm planning
On Thu, Apr 20, 2023 at 08:20:51PM +0200, Paul Gevers wrote: >Hi all, > >TL;DR: ftp & press input for June needed. > >On 20-04-2023 18:29, Adam D. Barratt wrote: >> The 13th does seem a bit close now, without having announced. > >After some consideration today, and the vibe felt in this discussion, let's >not rush this, so let's skip May 13 (also giving Press some time, see below). > >> One other thing of note is that, unless I've missed some mail, there's >> no press / publicity team member confirmed as available, which is >> really a requirement. > >Jonathan (DPL) mentioned earlier: >""" >Press team is in some slight limbo at the moment, I hope to help fix that >after the DPL election is over, in the mean time, it might be a good idea not >to block on them. >""" >If press is "really a requirement", we'll have to wait until this is settled. > >From the CD side we know that with May 13 out, the rest of May is also out. >So we're looking for a date in June. For June, starting with 10, we have: >kibi - 10, 17, 24d-i >Luna - 10, 17, 24CD testing >elbrus- 10, 24release team >adsb - 10, 17, 24release team Sledge - 10, 17, 24images team -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Re: 11.7 planning + bookworm planning
On Thu, Apr 20, 2023 at 11:32:49AM +0200, Paul Gevers wrote: >Dear all, > >Progress \o/. > >On 13-04-2023 11:29, Paul Gevers wrote: >> For me to do the release, I'd need to get my hands on the key. > >I'm in contact with Jonathan and we're convinced we'll be able to get the key >to me in time. > >Which leaves finding a date (and me learning what to do :) ). OK... >We have (if earlier mentioned dates still work for those involved): >May | June >> kibi - 13, 20, 27 d-i >> mhy - 13, 20, 27 ftp >> Sledge- 13 CD >> Luna - 20 CD testing >> elbrus- 13 27, (3), 10, 24 release team > >It seems a tiny bit late for 13 already, but still, would be awesome. What do >we think? I'm still OK for the 13th. >If we have somebody from CD to do 27 (yes, I remember Sledge can't >do that one), that would be great as it would be my preference; I'll have >lots of Debian people physically around me. As the DPL mentioned, we might >not want to block on press availability, although it would be real great if >we had them. Unfortunately, the other person on the images team who has the knowledge to do a release (Andy) is also away - we're on the same vacation! May 27 and June 3 are both out for that reason. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183
Re: Debian installer can't install Debian testing in VirtualBox when EFI enabled
[ re-adding the CC to debian-boot, and without attachments ] On Thu, Apr 20, 2023 at 12:31:02AM +0800, Licheng Hsu wrote: >Hi > >When I enable EFI in VirtualBox > >Screenshot from 2023-04-20 00-17-17.png >and try to install Debian testing, it just... well, the video attached may >explain something. Thanks, it does. It seems there's a problem with video setup and it's not starting X. What options do you have under Display? If you start with "Install" rather than "Graphical Install" then that should work for now. >Sorry, I'm just a regular user and don't know how to report problem I >encountered. That's fine! Thanks for helping to debug this. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Re: Debian installer can't install Debian testing in VirtualBox when EFI enabled
Hi! On Wed, Apr 19, 2023 at 01:41:37PM +0800, Licheng Hsu wrote: >I don't know if it's the bug of Debian installer or VirtualBox, >anyway, when EFI is enabled in VirtualBox, Debian testing just can't >install whatever Graphics Controller is in VirtualBox. > >I am using VirtualBox 7.0.8 and 6.1.44, and the lastest Debian testing >ISO released on April 17, 2023. Could you expand a little, please? What exactly do you mean by "can't install"? What errors do you see, for example? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Bug#1033913: partman-auto-lvm: Broken "Guided - use entire disk and set up LVM" in UEFI mode
I've just pushed an update to the code here... On Mon, Apr 10, 2023 at 05:45:15PM +0200, Pascal Hambourg wrote: >On 10/04/2023 at 15:13, Steve McIntyre wrote: >> >> Overall comment: I'm not trying to make the heuristics 100% reliable >> here, as I don't think that's actually possible. Instead, I'm trying >> to tread the fine line of: >> >> * minimising false negatives - let's try to pick up on the most >> common cases where people are dual-booting with other systems and >> might not understand the issues here. That's 99%+ going to be >> people with Windows installed >> >> * minimising false positives - the issue that angered Cyril in >> particular, with an incomplete LVM setup triggering the "bios >> bootable OS" warning > >IMO it is more important to avoid false positives, because switching to a >BIOS installation on systems which are not BIOS-boot capable would create a >non bootable system. In case oft is easier to install GRUB for BIOS boot on >an running EFI system than the other way around. No. The reason I added this check and warning in the first place is to avoid breaking existing (all-too-common) systems where Windows users have a BIOS-booting installation but their BIOS is set to boot both UEFI and BIOS. That's a stupid combination, but again all too common. :-( New users who are just trying to install Debian dual-boot are much less likely to be able to diagnose this kind of problem. >> > - Other BIOS boot loaders such as syslinux/extlinux do not need or use a >> > BIOS >> > boot partition. >> >> Also not a use case I'm particularly caring about, I'll be >> honest. They're also *really* not likely to work well without another >> filesystem in use, which I expect we'll detect anyway. > >Indeed other partitions are needed and will be detected, but they will not >increment $NUM_NOT_ESP if the disk is GPT and has no BIOS boot partition (so >$DISK_BIOS_BOOT=no), so it might cause a false negative. So why not just >treat MSDOS and GPT disk labels equally and treat BIOS boot partitions like >any other non-ESP ? It's a false negative that I really don't believe or care about very much, I'll be honest. This is getting to be an edge case on an edge case. >> > 1b) IIUC the patch fixes #1033913 because the disk selected for >> > installation >> > has received a new GPT disklabel without a BIOS boot partition, so further >> > checking is skipped. But IMO the root cause of #1033913 is that changes are >> > not committed to disk after setting the 'boot' and 'esp' flags to the newly >> > created ESP partition before stopping parted_server. > >I originally thought about fixing partman-auto-lvm but it appears that other >transient states can also trigger the "force UEFI installation" dialog during >partitioning, for example after setting up LVM in manual partitioning if >there is no ESP partition yet. As discussed in #debian-boot, a more general >fix might be to run the check only once because only existing partitions >before partitioning are relevant. Are there any use cases for which this >might cause a false negative ? So I've now modded the code to add a flag file - it'll only run the check and (maybe) raise the warning on the first entry into partman. Thanks for the suggection, this is clearly the correct answer. >> > 4) It appears that partman fails to detect the specially crafted partition >> > table on the installation media created with a debian image. Is it intended >> > or fortunately unintentional ? If partman could see the EFI partition on >> > the >> > installation media, the detection of BIOS-bootable systems would fail. >> >> That's not a worry for today... :-) > >Sure, but the issue can also happen if another removable media is present. >For instance the USB drive I use to provide missing firmware has an ESP >partition (and a regular partition table) thus can cause a false negative. Again, we're hitting edge cases. We can't know for sure what the user wants here, so we can't just ignore removable media (for example). -- Steve McIntyre, Cambridge, UK.st...@einval.com "Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters." -- Ignatios Souvatzis
Bug#1033913: partman-auto-lvm: Broken "Guided - use entire disk and set up LVM" in UEFI mode
Hey Pascal, and thanks for the review! Overall comment: I'm not trying to make the heuristics 100% reliable here, as I don't think that's actually possible. Instead, I'm trying to tread the fine line of: * minimising false negatives - let's try to pick up on the most common cases where people are dual-booting with other systems and might not understand the issues here. That's 99%+ going to be people with Windows installed * minimising false positives - the issue that angered Cyril in particular, with an incomplete LVM setup triggering the "bios bootable OS" warning On Mon, Apr 10, 2023 at 01:01:01PM +0200, Pascal Hambourg wrote: >partman-efi "Fix detection of BIOS-bootable systems" provides a significant >improvement over previous behaviour. However I have a few comments. > >1a) The patch assumes that a GPT disk may be BIOS-bootable only if it has a >BIOS boot partition. But a GPT disk can be BIOS-bootable even without a BIOS >boot partition: >- GRUB may be installed without a BIOS boot partition if /boot is a plain >partition (using blocklists), even though it is less reliable so a BIOS boot >partition is strongly recommended. Yeah, GRUB installed using blocklists is so much *not* a thing anybody should be doing these days. >- Other BIOS boot loaders such as syslinux/extlinux do not need or use a BIOS >boot partition. Also not a use case I'm particularly caring about, I'll be honest. They're also *really* not likely to work well without another filesystem in use, which I expect we'll detect anyway. >1b) IIUC the patch fixes #1033913 because the disk selected for installation >has received a new GPT disklabel without a BIOS boot partition, so further >checking is skipped. But IMO the root cause of #1033913 is that changes are >not committed to disk after setting the 'boot' and 'esp' flags to the newly >created ESP partition before stopping parted_server. >This can be seen in /var/log/partman: > >/bin/autopartition-lvm >NEW_LABEL sda gpt >NEW_PARTITION 1 sda ext2 538MB (future ESP) >NEW_PARTITION 2 sda ext2 512MB (future /boot) >NEW_PARTITION 3 sda ext3 159GB (future LVM) >SET_FLAGS sda3 lvm >(user prompt to write changes to the disk) >COMMIT sda >... >/lib/partman/update.d/21efi_sync_flag >SET_FLAGS sda1 boot esp >... >/bin/perform_recipe_by_lvm >QUIT <- esp and boot flags have not been committed yet so are lost >... >/lib/partman/init.d/50efi >GET_FLAGS sda1 -> none > >2) The patch considers the 'esp' and 'boot' flags to be equal. But this is >true only with GPT. With MSDOS, they have totally different meanings: >- 'esp' means that the partition has the ESP type identifier. >- 'boot' means that the partition has the active/boot indicator set. The UEFI >specification says that this indicator is ignored by EFI boot. ACK, I think you're correct here. Yay parted and its inconsistent "flags" concept. :-( >3) The patch considers LVM and RAID partitions not bootable. But both LVM and >RAID superblocks can have a boot loader reserved area. Also, GRUB may boot >them directly without a /boot partition. Hmmm, maybe. >4) It appears that partman fails to detect the specially crafted partition >table on the installation media created with a debian image. Is it intended >or fortunately unintentional ? If partman could see the EFI partition on the >installation media, the detection of BIOS-bootable systems would fail. That's not a worry for today... :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Bug#1034101: installation-reports: bookworm rc1 successful install to Levono T470
On Sun, Apr 09, 2023 at 01:53:11AM +0200, Cyril Brulebois wrote: >Hi Jeremy, > >and thanks for your report. > >Jeremy Davis (2023-04-09): >> Machine: Lenovo T470 (20HD) >> >> Had to disable secure boot to get USB to boot, but otherwise, >> everything "just worked". > >Why is that? We've been supporting Secure Boot for a very long while. And one of my standard test machines here is my old T470. Jeremy: what problem are you seeing please? -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control.
Bug#1033524: Simplify the instructions for making bootable media
On Mon, Apr 03, 2023 at 09:44:14PM +0200, Holger Wansing wrote: >Hi, > >Holger Wansing wrote (Mon, 3 Apr 2023 21:16:41 +0200): >> Holger Wansing wrote (Sat, 1 Apr 2023 20:52:08 +0200): >> > I have added such wiki page under >> > https://wiki.debian.org/DebianInstaller/CreateUSBMedia >> > and overworked my patch a bit, to include a link to this page (amongst >> > some more minor things). >> > >> > I will apply it shortly, if noone objects. >> >> Applied. > >FYI: I have also removed the chapter for booting the installer from Windows >(spotted just today), since win32-loader support has been removed from the >installer as well. Awesome stuff. Thanks Holger! \o/ -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI
On Thu, Mar 30, 2023 at 09:12:05AM -0700, Dima Kogan wrote: >Pascal Hambourg writes: > >> On 30/03/2023 at 01:21, Dima Kogan wrote: >>> I had to turn off >>> secure-boot and UEFI in the BIOS. >> >> Why ? What happens if UEFI boot is enabled ? > >If UEFI was enabled, the USB device isn't seen by the machine in its >list of valid boot devices Ugh, that sounds like a *particularly* crappy firmware bug then :-( What boot options does the firmware list in that case? Hmm, checking: https://www.dell.com/support/manuals/en-uk/latitude-14-5420-laptop/lati_5420_om/uefi-bios?guid=guid-892bb204-aa23-43e3-aa1f-0c2b66c0ddc3=en-us the "Important Information" section looks like it might be relevant? >> How did you prepare the USB drive ? What installation image did you >> use (full file name and URL please) ? > >>From yesterday's email: > > I downloaded this: > >debian-bookworm-DI-alpha2-amd64-netinst.iso > > from here: > >https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/ > > and I wrote that .iso to /dev/sde > >I did "cp debian-bookworm-DI-alpha2-amd64-netinst.iso /dev/sde" OK, that all sounds fine. >>> I'm not 100% sure of the exact cause. But I suspect strongly is that >>> booting the install media without UEFI broke installing to an UEFI-only >>> disk. >> >> If the installer was booted in BIOS/legacy mode, it installed GRUB for >> legacy boot. > >Was this a choice the installer made, or was it the only option? I don't >actually have a workaround yet. And if the installer had a check box to >ask for a GPT even though the install media was booted without UEFI, >then I could at least get this working after some fiddling. This *might* help you: * partman: If the system is booted in EFI mode, partman defaults to GPT for disk partitioning. If not, it will default to MSDOS. In partman, hitting on the raw disk will allow you to create a new blank partition table; this will take thd default type normally, and you won't be asked. *If* you switch to expert mode from the main menu (i.e. drop question priority), then go back into partman, you can choose to use a different partition type. By all means try GPT here, and create an EFI system partition (ESP) too. * grub-installer: This depends on the system being booted in EFI mode to do the right thing. If you're not, you *might* be able to make things work by editing the script /usr/bin/grub-installer and replace the line ARCH="$(archdetect)" with ARCH="amd64/efi". I've not tested this, but you *might* be able to progress here. The installer is *very* much designed to only set up EFI-relevant stuff if you're booted in EFI mode. -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: https://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Bug#1033524: Simplify the instructions for making bootable media
On Mon, Mar 27, 2023 at 12:52:41AM +0200, Chris Hofstaedtler wrote: >* Steve McIntyre : >> We should definitely also kill section 4.4.2: Loadlin is *dead* - >> *nobody* has DOS any more. > >Section 5.1.4. "Booting from DOS using loadlin" should also go, I >guess. Yup, good call. -- 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
Bug#1033524: Simplify the instructions for making bootable media
On Sun, Mar 26, 2023 at 11:06:56PM +0200, Holger Wansing wrote: > > >Am 26. März 2023 19:48:09 MESZ schrieb Steve McIntyre : >>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 could add such info to the wiki, and point there from this guide, if it's >wanted to keep it (somewhere). Yes, that sounds like a good idea. :-) >>We should definitely also kill section 4.4.2: Loadlin is *dead* - >>*nobody* has DOS any more. > >Also remove it from the images as well then? Doing it right now, in fact! -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Re: 11.7 planning + bookworm planning
Hey Paul, Nobody else seems to have replied yet, so... :-) On Thu, Mar 23, 2023 at 01:31:22PM +0100, Paul Gevers wrote: >Hi, > >With the point release scheduled for April 29th, it's probably good to have >at least one weekend in between, or do people not mind doing two weekends in >a row? Definitely *not* two weekends on the run, please! >On 17-03-2023 15:59, Steve McIntyre wrote: >> On Thu, Mar 16, 2023 at 11:26:00AM +0100, Paul Gevers wrote: >> > So, shall we add availability for May too? 6th, 13th, 20th (Ascension >> > weekend), and 27th (coincides with DebianReunionHamburg)? >> >> I could do the 6th and 13th, but I'm away on vacation 20th and 27th >> (and 3rd June). > >If I did the bookkeeping correctly, the missing necessary teams are press and >release team, as I now have: >kibi - 6, 13, 20, 27 d-i >mhy - 6, 13, 20, 27 ftp >Sledge- 6, 13 CD >Luna - 6, 20 CD testing > >I can help 6 (probably), 13 and 27, but I don't have the signing key and I >haven't witnessed all details from our side so I'm not comfortable doing it >alone even if I could get my hands on the key. > >elbrus-13, 27 release team 13th could work. I'll admit I'm a little anxious about the amount of work needed before release, but tbh that's not a new thing here... :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Bug#1033524: Simplify the instructions for making bootable media
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
Re: Starting the weekly live images for Bookworm building again
Hey again, On Tue, Jan 31, 2023 at 03:36:53PM +, Steve McIntyre wrote: >> >>As you can see, this affects many teams: >>* live-setup: a MR to generate all live images for Bookworm [A2] So, after some delay from me and some further delays from various Debian machines committing suicide [1], I've got bookworm live builds running again. \o/ I've taken Roland's updated patches and tweaked a little more in the setup.git and live-setup.git repos, and we now have live builds integrated. Changes I've added: * turned on source tarball generation using LB_SOURCE=true, and disable the external source build that we dod for the older live-wrapper builds * when building on casulana, warn about archive updates rather than restarting builds * don't attempt to build i386 live images any more, they're not useful * tweaked logging So, *builds* work fine but I've not *yet* tested actually booting/using one of these images in any way. I've just triggered a full build of "testing" live images now, please help test if you can once they're in place at [2] in a couple of hours from now. I don't yet know how close we are to having full non-free-firmware integration with the live images; I expect there might be some more work needed there yet, but I'd love to be proven wrong. :-) [1] "yay" for the long-standing tradition of services failing as we get close to a release: this time it was casulana and salsa... [2] https://get.debian.org/images/weekly-live-builds/ -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: 11.7 planning + bookworm planning
On Thu, Mar 16, 2023 at 11:26:00AM +0100, Paul Gevers wrote: > >From where I'm looking, bookworm is looking pretty good. Obviously we'll have >to follow through on the flurry of unblock requests that came in after the >hard freeze, but that should be manageable in a couple of weeks. kibi just >told me on IRC that asking this question now is not crazy from a d-i point of >view. That hopefully means that around the end of April, also the bookworm >d-i should™ be ready for release (kibi, I'm sure you'll comment on this if I >got you wrong or if you want to provide more details). > >So, shall we add availability for May too? 6th, 13th, 20th (Ascension >weekend), and 27th (coincides with DebianReunionHamburg)? I could do the 6th and 13th, but I'm away on vacation 20th and 27th (and 3rd June). -- Steve McIntyre, Cambridge, UK.st...@einval.com 'There is some grim amusement in watching Pence try to run the typical "politician in the middle of a natural disaster" playbook, however incompetently, while Trump scribbles all over it in crayon and eats some of the pages.' -- Russ Allbery
Re: 11.7 planning
On Wed, Mar 15, 2023 at 08:33:47PM +, Jonathan Wiltshire wrote: >Hi, > >We're overdue for 11.7 and need it done with a keyring update included >before bookworm can be released. The wheels are turning on the keyring so >how do dates in April look for everybody? Saturdays are 1st (probably too >soon), 8th, 15th, 22nd and 29th. I think I'm clear for any of: 8th 22nd 29th -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: https://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Bug#1032852: debian-installer: Intel Corporation PRO/Wireless 2200BG doen't work for d-i, does work on installed Bookworm
s interface wlp2s2 succeeded. Mar 12 20:54:25 netcfg[5996]: INFO: Network chosen: . Proceeding to connect. Mar 12 20:54:25 netcfg[5996]: INFO: Couldn't connect to wpasupplicant Mar 12 20:54:25 netcfg[5996]: INFO: Activating interface wlp2s2 Mar 12 20:54:25 netcfg[5996]: INFO: Scan of wireless interface wlp2s2 succeeded. ... Mar 12 20:54:27 netcfg[5996]: INFO: Activating interface wlp2s2 Mar 12 20:54:28 netcfg[5996]: INFO: Scan of wireless interface wlp2s2 succeeded. Mar 12 20:54:28 netcfg[5996]: INFO: Network chosen: . Proceeding to connect. Mar 12 20:54:28 main-menu[265]: (process:5995): Successfully initialized wpa_supplicant Mar 12 20:54:28 main-menu[265]: (process:5995): nl80211: Driver does not support authentication/association or connect commands Mar 12 20:54:28 main-menu[265]: (process:5995): nl80211: deinit ifname=wlp2s2 disabled_11b_rates=0 Mar 12 20:54:28 main-menu[265]: (process:5995): wlp2s2: Failed to initialize driver interface Mar 12 20:54:28 main-menu[265]: (process:5995): nl80211: Driver does not support authentication/association or connect commands Mar 12 20:54:28 main-menu[265]: (process:5995): nl80211: deinit ifname=wlp2s2 disabled_11b_rates=0 Mar 12 20:54:28 main-menu[265]: (process:5995): wlp2s2: Failed to initialize driver interface Mar 12 20:54:28 main-menu[265]: (process:5995): wlp2s2: CTRL-EVENT-DSCP-POLICY clear_all Mar 12 20:54:28 main-menu[265]: (process:5995): Successfully initialized ... and these errors go on for a long time :-( You say that you're preseeding things. Could you also please share your preseed file in case that is relevant? Could you run the installation without preseeding and confirm if the wireless works that way please? -- 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
Re: Error debian Acer nitro 5
Hi Diego, On Mon, Mar 06, 2023 at 07:33:50PM -0300, Diego Santos wrote: >package: installation reports Boot method: DVD? usb pen? Network?> Image version: got> Data: Machine: an515-52-7974 Processor: i7 Intel acer nitro 5 an515-52-7974 | i7-8750h Memory: >16 Partitions: External use >hdc 1 2 with dual boot windows I tested it without it as main Output from lspci >-knn (or lspci -nn): Basic system installation checklist: [O] = OK, [E] = Error >(describe below), [ ] = did not try Initial boot: [ ]ok Detect network card: [ >]ok Configure network: [ ],,ok free kernel mode Detect installation medium: [ ] >gave installation error Load installer modules: [ ] loads davfail Detect hard >drives: [ ] ok Partition hard drives: [ ] ok Install base system: [ ] ok Clock/ >time zone setting: [ ]ok Set username/password: [ ]ok Installation tasks: [ ] >ok Install the bootloader: [ ] ok Installation total: [ ] not installed Accepts >Ubuntu 19.04 kernel firmware well I'm struggling to understand wha you're trying to tell us here. Could you give us a little more information please? What error did you get, exactly? Which Debian installer image were you trying to use? -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control.
Re: Bootaa64.efi and grubaa.efi are missing from the folder EFI/boot in EFI partition
On Sun, Mar 05, 2023 at 04:02:04PM +0800, gugudu wrote: >Hello, Developers. >I installed Debian 12 BooksWorm on KunPeng（鲲鹏） / Phytium（飞腾）'s >computer. These PCs are based on the ARM64 UEFI platform. After restarting, >UEFI can't find Debian's EFI boot file, and GRUB can't boot. These UEFI >firmware are made by Kunlun Tech（昆仑太科） or Byo software（百敖软件）. After >Debian operating system is installed, I found that bootaa64.efi and grubaa.efi >are missing from the folder EFI/boot in the EFI partition of the hard disk. If >you try to repair the boot, you need to copy shimaa64.efi and grubaa.efi in EFI >/debian to EFI/boot. Rename EFI/boot/shimaa64.efi to EFI/boot/bootaa64.efi. ># cp EFI/debian/shimaa64.efi EFI/boot/bootaa64.efi ># cp EFI/debian/grubaa64.efi EFI/boot/grubaa64.efi It sounds like your firmware does not support setting of EFI boot variables. Fully functional firmware should *not* need files in the removable media path (EFI/boot like that). See https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path for more information, and the correct way to work around this issue in your firmware. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: bookworm release date?
On Thu, Mar 09, 2023 at 05:05:28PM +, Adam Barratt wrote: > >Sorry for the delayed reply, apparently I'm further behind than I >realised. :-( :-/ *hugs* >On Fri, 2023-02-17 at 21:56 +0100, Paul Gevers wrote: >[...] >> What do people think of the idea >> to start picking a release date already? >> >[...] >> Adam, I think we'd also want to do a point release before that time, >> e.g. to include a fix for bug #1029803. What do you think about it? >> > >Yes. We also really want to get a debian-archive-keyring update into >bullseye before the release, or we can't use the new keys to sign the >bookworm release files. But first we need to get it into unstable. I'm >aware that we're very late here, sorry. :-( > >ftp-master have now published their bookworm keys, so we can get those >incorporated. For the SRM side, you probably saw that we've been >considering moving to an EC key. From the very limited responses to the >discussion I started on debian-release, I'm still not entirely sure if >that's feasible / a good idea. > >It would also be good to finally get the shim updates into bullseye at >the same time, unless Steve tells me that's a bad plan. :-) :-) I uploaded the latest signed shim last night expressly to have it in the next bullseye point release. Do you want an unblock for that? I'm also looking at some (small!) updates for grub too. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)
Bug#1032140: Lenovo Z16 Install issue
; > >Base System Installation Checklist: > >[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it > > > >Initial boot: [O] > >Detect network card:[E] > >Configure network: [ ] > >Detect CD: [ ] > >Load installer modules: [ ] > >Detect hard drives: [ ] > >Partition hard drives: [ ] > >Install base system:[ ] > >Clock/timezone setup: [ ] > >User/password setup:[ ] > >Install tasks: [ ] > >Install boot loader:[ ] > >Overall install:[ ] > > > >Comments/Problems:does not properly detest network wifi cardd, > >Related dmesg Logs > >[ 30.324093] ath11k_pci :04:00.0: BAR 0: assigned [mem >0xb000-0xb01f 64bit] > >[ 30.324449] ath11k_pci :04:00.0: MSI vectors: 32 > >[ 30.324454] ath11k_pci :04:00.0: wcn6855 hw2.1 > >[ 30.325448] ath11k_pci :04:00.0: failed to initialize qmi handle: -517 > >[ 30.325450] ath11k_pci :04:00.0: failed to initialize qmi :-517 > >[ 30.325450] ath11k_pci :04:00.0: failed to create soc core: -517 > >[ 30.325451] ath11k_pci :04:00.0: failed to init core: -517 > > > > > > > and ideas you had during the initial install.> > > > -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Non-free-firmware changes - initial cut released!
Hey all! Here's a status update on the non-free-firmware changes that we voted for last year [1]. Cyril has done a huge amount of work [2], implementing the bulk of what we need. We released d-i bookworm alpha 2 last weekend [3], including those changes. Our own testing shows that things work well on *our* test hardware, but we'd like some more assistance in testing! If you would like to help and you have a machine that wants firmware, please: 1. Boot the installer and verify that it identifies the necessary firmware correctly - go as far as configuring the network. If there are still missing firmware blobs, d-i will complain. If you stop before making any changes in the partitioner (partman), then this should a safe thing to do on your existing machine and won't make any permanent changes. 2. (If you can) complete an installation and check that all the hardware works as expected after normal bootup. We'd love people to do this to verify the more awkward blobs: audio and GPU. We're especially interested in wifi, NIC and GPU firmware here, as they have been the things blocking people installing Debian in the past. Please file bugs against "installation-reports" with whatever you find! Thanks in advance! We're also planning more updates before the full bookworm release - watch this space! [1] https://www.debian.org/vote/2022/vote_003 [2] https://debamax.com/blog/2023/02/27/debian-versus-non-free-firmware/ [3] https://lists.debian.org/debian-devel-announce/2023/02/msg5.html -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Bug#1031594: os-prober is disabled by default in /etc/default/grub - Windows not found
On Sun, Feb 19, 2023 at 12:42:10AM +, Andrew M.A. Cater wrote: >Package: os-prober >Version: 1.79 >Severity: normal > >Dear Maintainer, > >In testing for Debian Bookworm Alpha 2 release > >Windows not found when dist-upgrade from existing 11.6 system > >Disabled in /etc/default/grub > >* grub2: >Add commented-out GRUB_DISABLE_OS_PROBER to /etc/default/grub >to make it easier for users to turn os-prober back on if they want >it (#1013797, #1009336) > >This needs to be discussed Thinking something like: * *maybe* a debconf Q in grub to ask "do you want me to look for other OSes?" * we can set that if we find what looks like other OSes in d-i * and also check on upgrades - if we have other OSes listed in the current grub config Otherwise we *are* going to get panicky Windows users using d-i or upgrading and "losing" their Windows installation. -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Re: bookworm release date?
Hey folks, Cyril and I are in broad agreement on stuff, just adding a couple of points... On Fri, Feb 17, 2023 at 11:44:47PM +0100, Cyril Brulebois wrote: >Hi Paul, > >Paul Gevers (2023-02-17): >> Yes, I know the debian-installer is not a done deal, so kibi, please >> let us know where you think we stand with d-i (briefly is OK, I know >> you normally report extensively elsewhere) and when you think d-i can >> realistically be in a releasable state. (Saying: "in June" is fine, >> than we can plan accordingly). > >BEGIN VERY WILD GUESS > >With a release going out this week-end, I think the next one with >bugfixes or improvements based on user or developer feedback couldn't >happen before 2 weeks. And I'd expect 2 more releases after that to iron >things out, with at least 1 week between each. > >That'd mean end of March, beginning April at the soonest. > >Depending on what we encounter, and possible changes in other packages >in the archive, we might have various delays, so it's probably best to >add 2-4 extra weeks to that. +1 >I'll let Steve comment on the bootloader aspect (brand new shim just >arrived, not sure how much time / how many iterations we might need to >get it in shape for bookworm; plus we've gotten some fixes in grub but I >think some further changes are planned). Exactly. I'm just doing the packaging updates for shim-signed now, and obviously I'll be doing a lump of testing too. I don't expect any more updates for *shim* itself before bookworm, but there might be a couple of rounds of bugfixing and testing for shim-signed here. Grub could do with a bit more effort. There are a few edge-cases I'd like to pick up on, and (as you know!) quite a few RC bugs yet. Now we have a working arm64 shim, I suspect there will be a little more work needed to validate arm64 SB; I think we might be missing some needed patches there. Maybe 3-4 weeks for grub stuff altogether . -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Switched d-i boot screens to use the new emerald theme
[ Similar to my own mail about homeworld almost exactly 2 years ago! ] Hey folks, I've pushed changes into d-i just now so we'll use the lovely new Emerald theme from Juliette for our boot splash screens, both for isolinux and grub, and for mini.iso and debian-cd images. @Juliette: I've tweaked the size and positioning of the "debian 12" logo a little from what I found in your git repo. I hope you're ok with this! :-) Reference screenshots at https://www.einval.com/~steve/tmp/bookworm/2/ so you can see what I've done. The original placement for the logo clashed with the menus and help text in the various menus. I'd love to find the time to make the different menus etc. more consistent, but probably not this release... :-/ -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
dep11 files missing for bookworm (non-free-firmware)
Package: ftp.debian.org Severity: important Hi all, As part of the nff changes, debian-cd now looks for dep11 metadata to help work out what firmware might be needed. We have that working for all other arches, but *not* mipsel. Builds are failing looking for /dists/bookworm/main/dep11/Components-mipsel.yml.gz Please fix up archive config so this works. Cheers, Steve
Re: Bug#1030846: e2fsprogs: generates filesystems that grub-install doesn't recognize
Control: reassign -1 grub2 On Wed, Feb 08, 2023 at 02:02:44PM -0500, Theodore Ts'o wrote: > >The fix for this issue landed in the grub2 repository on June 11, >2021: > >commit 7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763 >Author: Javier Martinez Canillas >Date: Fri Jun 11 21:36:16 2021 +0200 ... >If we *are* going to backport some grub2 patches, may also make a plug >for this one, which is also in the upstream grub2 git repo: > >commit 2e9fa73a040462b81bfbfe56c0bc7ad2d30b446b >Author: Theodore Ts'o >Date: Tue Aug 30 22:41:59 2022 -0400 I've just queued these up in our repo for the next grub upload, due in a few days. -- Steve McIntyre, Cambridge, UK.st...@einval.com "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." -- Bruce Schneier
Re: Starting the weekly live images for Bookworm building again
Hey Roland, Apologies for leaving you waiting a while :-/ On Mon, Jan 16, 2023 at 05:35:50PM +0100, Roland Clobus wrote: > >This is a follow-up of my mail from 2022-11-21 [A1]. > >I've made progress in the last two months, but would like to have some merge >requests approved, to get more traction and to allow others to jump aboard >and make the live images for Bookworm possible. > >As you can see, this affects many teams: >* live-setup: a MR to generate all live images for Bookworm [A2] ACK, I'll take a look at this again shortly. >* localechooser: A minor fix [A3] No idea about that, leaving for somebody else. >* live-installer: A better user experience after the installer is finished >[A4] Merred just now. >* live-build: Various installer improvements, including off-line installation >[A5] Not sure who might review that, let's see -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Re: Re: Shim and secure boot status, leading up to bookworm
On Sun, Jan 29, 2023 at 12:56:28PM +0100, Andreas B. Mundt wrote: >Hi Steve, > >On Wed, 25 Jan 2023 20:27:20 +0000, Steve McIntyre wrote: >> On Wed, Jan 25, 2023 at 12:40:07PM -0700, Jeremy Hall wrote: >> > >> >When things get built, will there be a path forward for people who >> >might need grub modules like serial console for accessibility reasons? >> >> The serial module has already been added to the signed grub binary a >> while back (2.06-4). If you need anything else, please ask or file >> bugs. > >I would like to draw your attention to: > > https://salsa.debian.org/grub-team/grub/-/merge_requests/14 > https://bugs.debian.org/920610 > >For my use case, the inclusion of the http module would be appreciated. ACK, that's on my list to look at very soon. Just finishing off work on shim first, as that has external blockers too. -- 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
Bug#1029848: hw-detect: decide how to configure firmware support
On Mon, Jan 30, 2023 at 01:20:17AM +0100, Cyril Brulebois wrote: >Steve McIntyre (2023-01-30): >> Fine. I'd be *tempted* to maybe define the default to "always", to be >> 100% clear and (maybe?) more consistent to my OCD. At some point I >> expect we're likely to end up with a case statement in hw-detect, >> after all. > >I'd rather not name and define something if we don't need to. What if we >need or want to distinguish between loading files from the installation >images and/or from external storage, etc. later on? People might already >have written their preseed or whatever, and complain we're changing the >meaning behind that setting. > >Things would be much different if we were actually asking a question >(e.g. in expert mode). > > >(And as you know from our meeting, I totally agree with the “case >possibility” in the future. But I'd rather wait until we have new, >reasonable use cases that we want to implement, before deciding on new >names and semantics.) That's fair. +1 -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Bug#1029848: hw-detect: decide how to configure firmware support
On Sun, Jan 29, 2023 at 03:38:14AM +0100, Cyril Brulebois wrote: >Steve McIntyre (2023-01-29): >> >I'm proposing: >> > - “hw-detect/firmware” as template for hw-detect; >> >> I was thinking "hw-detect/load_firmware" might be better - we may >> want/need more firmware questions yet, so let's leave the namespace >> open? > >That's exactly what someone has already thought about, and used to >implement the “Load missing firmware from removable media?” prompt. Bah :-/ >If we really want not to use a bare /firmware, maybe /firmware-lookup? >But having something specialized in hw-detect and something much more >generic in preseed would look strange to me. I don't really mind either >way. tbh, I'm happy enough either way too! >> > - “firmware” or “fw” as an alias for shorter typing (“fw” feels like >> > extremely short); >> >> I'd just go for "firmware" here; "fw" might be confused with firewall >> (I see Andy had a similar thought). > >Agreed, let's go with “firmware”. > >> > - “never” value to skip firmware handling altogether, meaning >> > skipping both mechanisms mentioned above. >> >> Maybe, yeah. That's probably clearest. Then we'd default to "always". > >That's the *spirit* of it but not the letter: > - I'm implementing support for “never”. > - I'm not implementing support “always”. It doesn't exist. It isn't > specified. This isn't the value you're looking for! :) Fine. I'd be *tempted* to maybe define the default to "always", to be 100% clear and (maybe?) more consistent to my OCD. At some point I expect we're likely to end up with a case statement in hw-detect, after all. >More seriously, the template doesn't even come with a default value. I'm >using db_get and "$RET" = never to implement early exit, that's all. > >> >That would leave us a rather important flexibility regarding other >> >behaviours that we might want to implement, depending on the use >> >cases that might get identified (#1029543), without having to make a >> >decision about those (names and associated semantic) right now. >> >> Yup, good call. We can extend this more to add the nuanced options >> once we've got the basics - let's do it incrementally! > >Thanks for confirming the approach! -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Bug#934822: ath9k-htc free firmware still an issue in free software distributions
On Sun, Jan 29, 2023 at 10:22:34PM +, Andrew M.A. Cater wrote: > >I think that there has previously been a request from the maintainer to >move that package into the free firmware package from main so that it is >installed when someone installs the firmware-linux-free bundle. > >That makes sense as a starting point if you're looking for packages that >provide firmware. It's on our list to look at, ACK. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Bug#1029848: hw-detect: decide how to configure firmware support
Hey kibi! On Sat, Jan 28, 2023 at 08:09:58PM +0100, Cyril Brulebois wrote: >Package: hw-detect >Severity: important > >Hi, > > ># Context > >Quoting the text that was agreed to via the 2022 General Resolution >about non-free firmware: > >We will include non-free firmware packages from the "non-free-firmware" >section of the Debian archive on our official media (installer images >and live images). > >This means that images built by debian-cd (like netinst) will have main >and non-free-firmware packages available under /firmware, with metadata >under /firmware/dep11, making it easy for hw-detect to: > > - Resolve firmware files (spotted as missing by looking at dmesg) into > firmware packages (if available), deploy those packages in the > installer environment, tweak apt-setup's default configuration, and > install those packages in the target environment. > >→ Implemented by check-missing-firmware (detection & deployment in > the installer environment) and install-firmware hooks (enabling > apt-setup/non-free-firmware if relevant, installing in target > environment). > > - Detect firmware packages based on modalias information (in case > missing firmware didn't trigger lines in dmesg), not deploying them > in the installer environment, but queuing them for installation in > the target environment (also tweaking apt-setup's default config). > >→ Implemented by install-firmware hooks. Yup. >(Implementation detail: There are two install-firmware hooks, one after >base-installer, one before pkgsel.) > > ># Allowing for main-only > >The next sentence of the text that was agreed to is: > >The included firmware binaries will normally be enabled by default >where the system determines that they are required, but where >possible we will include ways for users to disable this at boot >(boot menu option, kernel command line etc.). > >I'd like us to determine the following things: > - the best name for an internal-only template for hw-detect; > - the best alias for it, to be used e.g. on the Linux command line, to > save some typing; > - what values it should support; > - what semantics should be attached to those values. > >Even before working on non-free-firmware integration, there were many >possible combinations. With the ongoing work, we aim at making it easy >for most users to just get a successful installation, and I've proposed >to streamline alternate use cases (see #1029543), so that we can focus >on supporting maybe fewer things, but supporting them well. > >hw-detect already has a loop, the concept of searching for firmware on >external media, the concept of asking, etc. > >It really doesn't make sense to me to have any kind of per-file, >per-module, or per-package granularity. This would mean many prompts, >possibly with way too many lines (see how many files iwlwifi can >request), and wouldn't really help users make an informed decision. >Extra templates would also mean more work for translators… > >Therefore, my current approach would be not to try and implement some >yes/ask/no trichoice as originally envisioned, but to provide users >wanting to avoid firmware altogether a way to do so. > > >I'm proposing: > - “hw-detect/firmware” as template for hw-detect; I was thinking "hw-detect/load_firmware" might be better - we may want/need more firmware questions yet, so let's leave the namespace open? > - “firmware” or “fw” as an alias for shorter typing (“fw” feels like > extremely short); I'd just go for "firmware" here; "fw" might be confused with firewall (I see Andy had a similar thought). > - “never” value to skip firmware handling altogether, meaning skipping > both mechanisms mentioned above. Maybe, yeah. That's probably clearest. Then we'd default to "always". >That would leave us a rather important flexibility regarding other >behaviours that we might want to implement, depending on the use cases >that might get identified (#1029543), without having to make a decision >about those (names and associated semantic) right now. Yup, good call. We can extend this more to add the nuanced options once we've got the basics - let's do it incrementally! -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone
Re: Shim and secure boot status, leading up to bookworm
Hi Jeremy, On Wed, Jan 25, 2023 at 12:40:07PM -0700, Jeremy Hall wrote: > >When things get built, will there be a path forward for people who >might need grub modules like serial console for accessibility reasons? The serial module has already been added to the signed grub binary a while back (2.06-4). If you need anything else, please ask or file bugs. In the longer term, some grub upstream developers are working on adding support for signing grub modules individually that might make it possible for people to add more themselves. But that's not going to happen before bookworm. HTH! -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)
Re: Shim and secure boot status, leading up to bookworm
Hey Antonio, On Wed, Jan 25, 2023 at 04:17:50PM -0300, Antonio Terceiro wrote: >On Wed, Jan 25, 2023 at 06:11:45PM +0000, Steve McIntyre wrote: >> >> The MS and cert issues are now both resolved, and I'm now working on a >> shim *15.7* upload. There's a little more work and testing to do, but >> I'm not far off. Yay? > >Have the issues with arm64 been fixed? Will this release provide a >signed arm64 shim? We should have a signed shim for arm64, yes. I need to test end to end again yet; I think we're still missing some arm64 SB patches for grub. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Rarely is anyone thanked for the work they did to prevent the disaster that didn’t happen.” -- Mikko Hypponen (https://twitter.com/mikko/)
Shim and secure boot status, leading up to bookworm
Hey all! Here's a status update and plans for SB and shim. If any of this is unclear or you have doubts, please say! We currently have *signed* shim *15.4* packages in the archive, for all of buster, bullseye, bookworm and sid. That works OK at the moment, but is getting old (July 2021) and needs updating soonish. I uploaded shim *15.6* in July 2022 and we attempted to get that signed too. Reviews were positive, but due to process problems around Microsoft uploads and then a long delay on getting a needed EV certificate renewed we never managed to get that signed. :-( The MS and cert issues are now both resolved, and I'm now working on a shim *15.7* upload. There's a little more work and testing to do, but I'm not far off. Yay? However, there are a couple of caveats to this... SBAT update --- The new shim build will need to block SB execution of older grub builds (anything with an SBAT level for grub.debian < 4). The oldest builds that will continue to work are: * 2.06-6 (unstable/bookworm) * 2.06-3~deb11u5 (bullseye) * 2.06-3~deb10u3 (buster) This is hopefully not unexpected, but I'm sharing here to be 100% clear. I'm planning on doing shim 15.7 builds for bullseye and buster again, so these all matter here. NX -- At the end of November 2022 (while unable to get anything signed) we passed a deadline; new shims since that point must be built with NX support enabled, and flagged as such. This extra hardening should improve security more, so it's not a bad thing in general. *However*, it does have consequences - once shim is loaded by UEFI firmware and started with NX enabled, all the UEFI binaries downstream of it *also* have to support NX as well. Patches for grub and linux are under discussion at the moment, but AFAIK not yet released; I need to check on the status of fwupd-efi too. What does this mean for us? * Older machines with older firmware will continue to work just fine. * New-enough machines with firmware that enables NX will fail to boot until we get full NX support through our boot chain. :-( There's a mitigating factor here: *such* new machines may already reject our older signed binaries anyway. We're stuck in a bad situation here I'm afraid; I think the only sensible way is forward, applying NX patches as soon as they're ready. Thoughts? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian" signature.asc Description: PGP signature
Re: need we support unshadowed passwords from the installer
On Sat, Jan 14, 2023 at 09:18:59AM -0500, nick black wrote: >Marc Haber left as an exercise for the reader: >> On Fri, 13 Jan 2023 21:11:40 -0500, nick black >> wrote: >> >i'm absolutely not suggesting we stop supporting NIS or other >> >programs which rely on unshadowed passwords. it's a big ol' >> >tent, and we have more than enough room for you to carry forth >> >the torch of Solaris 2. i just don't think this belongs in the >> >installer anymore. >> >> Amen. NIS-based systems usually have professional administrators who >> are well able to change the configuration. > >hahah, yes i thought you might support the idea based off >adduser changelogs circa 2005 =]. > >thanks to you and peter for voicing your support. i will head >off to #debian-boot and try to drum up a merge. I'll be honest, I've been horrified for years that we can still ask the shadow question. I hadn't realised it might be relevant for NIS. Even so, +1 from me. Let's get this done, I think... -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Bug#1026857: Installation media not bootable for architecture ppc64el on Tyan TN71-BP012
Hi Olivier, On Thu, Dec 22, 2022 at 06:14:14PM +0100, oliviosu_ppc6...@tutanota.com wrote: ... >Comments/Problems: >Installer fail to start, kernel crash. >Test on Tyan TN71-BP012 (IBM POWER8), the iso was wrote with dd to USB. >(Petitboot (dev.20150810) TN71-BP012 TCGQV04D0011) > >The same kernel work on this computer via upgraded (on SSD) Debian 10 to 11.6 >(Debian 10 insallation working fine) >boot entry: >Debian GNU/Linux, with Linux 5.10.0-20-powerpc64le >working fine. > >The computer have screen and keyboard. >Boot was done creating entry in petitboot with: >selecting sdb (usb device) >Kernel: /install/vmlinux >Initrd: /install/initrd.gz I don't *think* we've changed anything in terms of how the installer boots that might impact ppc64el, but clearly something's broken. :-( Considering this looks like a kernel problem, I'm surprised you're not seeing a similar issue if you upgrade and use this kernel on your existing system! Just to check: * Do you have any special setup on the installed system, e.g. a custom kernel command line? * You say you wrote the image to USB using dd; did you read back and verify the image after you wrote it? It's not uncommon to see faults here... -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Bug#1024720: d-i fails at grub when another installer is on disk
On Wed, Nov 23, 2022 at 07:31:39PM +, Peter Palfrader wrote: >Package: installation-reports >Severity: normal > >Boot method: USB >Image version: firmware-testing-amd64-netinst.iso >(https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-builds/amd64/iso-cd/; > 2022-11-21) >Date: Wed, 23 Nov 2022 20:27:28 +0100 > >Machine: Lenovo Thinkpad X13 Yoga Gen3 > >This machine came with an Ubuntu Installer on disk, in nvme0n1p2. > >This confused the grub on the installer image as it did not find the >correct root partition: > >} grub> search --file --set=root /.disk/info >} grub> echo $root >} hd0,gpt2 > >As opposed to (cd0). > >A workaround was to rename the .disk/info file on nvme0n1p2. > >A fix might be if each installer image used and searched for a unique >file. Exactly. I've just pushed that as a fix to the debian-cd build scripts which should fix this for future builds. Massive thanks for helping to debug this! -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: 11.6 planning
On Thu, Nov 17, 2022 at 09:33:33PM +, Adam Barratt wrote: >Hi, > >We've managed to slip behind on getting a bullseye point release >sorted, again. :-( I realise we're heading towards the holidays at a >surprising rate of knots, but hopefully we can find a generally >agreeable date. > >Please could you indicate your availability and preferences between: > >- December 3rd >- December 10th >- December 17th > >At this point, the 10th is probably my preference, as I'm likely to be >busy with work stuff at the tail end of November. I'm away on a work trip on the 1st and 2nd, due back home sometime on the 3rd. I could do a release, but I'd be starting later than normal. Maybe Andy could start it and I'd catch up with him when I'm back. I'm busy on the evening of the 10th, but we can work around that if needed. The 17th looks clear and hence would be easiest for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com 'There is some grim amusement in watching Pence try to run the typical "politician in the middle of a natural disaster" playbook, however incompetently, while Trump scribbles all over it in crayon and eats some of the pages.' -- Russ Allbery
Bug#1023769: efi-reader: Please add support for "riscv64" arch
Hey Manuel! On Wed, Nov 09, 2022 at 10:57:56PM +0100, Manuel A. Fernandez Montecelo wrote: >Source: efi-reader >Version: 0.16 >Severity: wishlist >Tags: ftbfs patch >User: debian-ri...@lists.debian.org >Usertags: riscv64 >X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org > >Hi, > >Please enable this architecture, with the patch attached or an equivalent. > >I built it locally on hardware, it built fine just by enabling the architecture >in debian/control, no other changes needed. Are you sure you need to build efi-reader here? It's mostly a no-op package on the existing arches already, and I'd be surprised if there is any use for it on on riscv64. Cheers, Steve -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Re: Issue with preseeded install - cannot skip apt media scanning
Hi Jerzy, You might be better off asking on the debian-boot mailing list (in CC). On Sat, Oct 22, 2022 at 04:50:20PM +0200, Jerzy Patraszewski wrote: >Hi debian-wizards, >I'm seeking your wisdom, since I'm almost banging my head against the wall... >Any ideas how to get rid of the described error and achieve fully unattended >Debian install? >Thanks in advance, any suggestion will be much appreciated! >Jerzy > >The issue: >While using preseed file, regardless of any setting, debian installer (dialog) >jumps off to interactive mode on error: "Apt configuration problem. An attempt >to configure apt to install additional packages from the media failed". This >happens just after installing the base system. After pressing continue - apt >scans mirror correctly and the rest of the process goes unattended till the >end. > > >Preseed file includes (whole file can be here: http://paste.debian.net/1257950/ >): ><...> >d-i apt-setup/cdrom/set-first boolean false >d-i apt-setup/cdrom/set-next boolean false >d-i apt-setup/cdrom/set-failed boolean false > >apt-cdrom-setup apt-setup/cdrom/set-first boolean false >apt-cdrom-setup apt-setup/cdrom/set-next boolean false >apt-cdrom-setup apt-setup/cdrom/set-double boolean false >apt-cdrom-setup apt-setup/cdrom/set-failed boolean false ><...> > >The boot command: >auto=true priority=critical preseed/url=http://[IP:port]/debian-preseed.txt > >ISO file used for installation: >debian-cd/current/amd64/iso-cd/debian-11.5.0-amd64-netinst.iso > >Additional info: >From https://preseed.einval.com/debian-preseed/bullseye/amd64-main-full.txt >it seems that only apt-setup/cdrom/set-failed should be sufficient: > >### Description: Scan extra installation media? ># An attempt to configure apt to install additional packages from the ># media failed. ># . ># Please check that the media has been inserted correctly. ># d-i apt-setup/cdrom/set-failed boolean true > >Unfortunately this does not work :/ -- 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 Das Mohapatra
Re: Firmware GR result - what happens next?
Hi Pascal, On Fri, Oct 14, 2022 at 09:57:37PM +0200, Pascal Hambourg wrote: >On 14/10/2022 at 21:49, Holger Wansing wrote: >> >> Pascal Hambourg wrote (Fri, 14 Oct 2022 21:31:31 >> +0200): >> > > > > As far as I understand it, they can be packaged once their >> > > > > redistributability is clarified? >> > > >> > > The only way for the installer to make use of such firmware is, if the >> > > user provides the firmware files on a removable device, like an USB >> > > stick. >> > >> > This is my point. If Debian does not provide all firmware for drivers >> > which are included into the installer, then support for extra firmware >> > medium is still useful and should not be removed. >> >> For this specific case (use of firmware files, which are not available in >> Debian) there is no need for a special installer medium. > >I did not mention the need for any special installer medium, only the need >for the installer to support extra firmware medium. > >> The usual installer also has the capability to make use of firmware >> provided via USB. > >It was suggested in this thread to remove this feature. ACK, that was our thought. Thanks for pointing out the issue here, it's appreciated! -- Steve McIntyre, Cambridge, UK.st...@einval.com "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." -- Bruce Schneier
Re: Firmware GR result - what happens next?
On Thu, Oct 13, 2022 at 05:08:57PM +0200, Julien Cristau wrote: >On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote: >> Maybe and idea would to do something like isa-support does for e.g >> sseX-support >> on CPUs that does not have that feature: It fails on installation with an >> debconf message, IIRC. >> So that would allow something like "new package" | >> "you-need-to-enable-nonfree-firmware-reminder-package" >> >Failing on installation is a terrible user experience, let's not, pretty >please. It's not great, no. Do you have a better suggestion for making sure people update sources.list? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters." -- Ignatios Souvatzis
Re: Firmware GR result - what happens next?
Hey Jonathan! On Sun, Oct 09, 2022 at 09:30:55AM +0200, Jonathan Carter (highvoltage) wrote: > >On 2022/10/08 18:37, Steve McIntyre wrote: >>* Is PXE over wifi a thing? Never seen it... > >I've been poking around firmware setups of new laptops, and I'm intrigued by >a new option that at least all the new Dell laptops have, called httpboot. It >seems that you can just provide a URL to an EFI stub and then it would boot >that (it's then up to whatever you do in that stub to boot something that can >set up further networking etc), but it seems like a great thing to support in >some future Debian release if possible, since you wouldn't even have to write >as much as a boot USB disk in order to install your system. > >I'm not at all sure about where all of it's limitations are, and the >documentation I could find on Dell's website are minimal, but if I have >access to such a machine again I'll poke around and experiment a bit and >write some notes for this list. Nod. As you ACKed in IRC later, I did mention this in my mail... :-P It's something that we should definitely be looking at, agreed. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Re: Firmware GR result - what happens next?
Hey again folks! On Sun, Oct 02, 2022 at 03:27:36PM +0100, Steve McIntyre wrote: ... >We have quite a few things to do now, ideally before the freeze for >Debian 12 (bookworm), due January 2023 [2]. This list of work items is >almost definitely not complete, and Cyril and I are aiming to get >together this week and do more detailed planning for the d-i >pieces. Off the top of my head I can think of the following: Cyril and I have just had that planning meeting, and here are the notes. We're *not* trying to solve every problem here, just working out the next steps needed for d-i and debian-cd in particular. Debian firmware changes for d-i and installer images - notes Steve and Cyril, 2022-10-08 Netboot and firmware - what do we have to do? - * PXE over wired ethernet should just work as-is? * Is PXE over wifi a thing? Never seen it... * If we need any more than simple wired, we're not going to worry about it for bookworm * This will likely be a problem for audio firmware * Is netboot a common use case for partially-sighted people? * Not going to focus on this here just *yet*, maybe we could work on it as a later option * Option to maybe load firmware via PXE/tftp process at early kernel startup? Would need to investigate... * HTTP(S) boot maybe? Updating the sources.list of existing systems on upgrade * **It's not a problem for d-i / debian-cd, we're not dealing with this here** * automation is not likely to happen, we don't do it already * **not** something we're trying to solve here * having packages in both n-f and n-f-f seems like not a good solution * worries about dak and others - we've never done this before * Maybe move things to n-f-f and leave a transitional package in n-f? * not sure about this either * Let's punt on this decision for now, we can look at it again later if we have to Detection of needed firmware * We already had a solution in bullseye which was good enough, let's keep with that? * We're trying to solve the 99% case, and we have that now AFAIK? * Worry about bonded network handling? * Maybe tweak interface handling to not take down one half of a virtual interface * Cyril plans to work on VLAN & bonding topics anyway; easy to hook it up/down. * We *think* things are working ok, but we're not 100% confident. We've not had complaints, but we don't know if that just means we don't have users! * Let's ask for testing to double-check that the new firmware-included images work OK - bookworm d-i alpha 2 should be ready with the nff changes? * Cyril will test with 2 “d-i laptops” (same as bullseye). What process should we follow for firmware during d-i? -- * Several processes where we may ask for firmware: audio, network, disks, etc. * Do we ask about loading fw at each stage? Or just at the end? * Three options via kernel command line? Cyril can take it. * Allow firmware by default, then just before finish-install we add a new screen listing firmware needed, details, write to disk on the installed system. Cyril can take this. * Maybe: if no firmware is needed then give a "congratulations!" message. Cyril will not take this. * Deny all firmware - don't attempt to load things at all, if the system is broken then so be it * Confirm - at each point display a prompt to the user before loading fw * We could **maybe** add support for changing the choice during the installation, but let's keep it simple for now. Probably add a question in expert mode? * What do we do with **free* firmware here? Should we **always** allow it? * What happens when we have both non-free and free implementations of firmware for given hardware? * At some point we'll have to make a choice of which to use by default, or allow for overriding on the kernel cmd line or something. * How do we handle sources.list changes (during the course of the installation process, not on installed systems)? We might need to enable/disable n-f-f at various times, for both the main archive and the security archive. Cyril takes it. * Even with fw available, we *might* get prompts where some modules are unclear, or where we may not have the exact suggested firmware available. * Don't panic about this too much; we might add blacklists for known-awkward modules later. Not a priority here (yet). We already have one case implemented: iwl-debug-yoyo.bin (iwlwifi). * Let's drop the question/support for an extra firmware medium - it's not useful any more. We're going to have firmware available
Re: Firmware GR result - what happens next?
On Wed, Oct 05, 2022 at 10:11:27PM +0200, Julien Cristau wrote: >On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote: >> On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote: >> >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote: >> >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote: >> >> > What's the plan for upgraded systems with an existing >> >> > /etc/apt/sources.list. >> >> > Will the new n-f-f section added on upgrades automatically(if non-free >> >> > was >> >> > enabled before)? >> >> >> >> So this is the one bit that I don't think we currently have a good >> >> answer for. We've never had a specific script to run on upgrades (like >> >> Ubuntu do), so this kind of potentially breaking change doesn't really >> >> have an obvious place to be fixed. >> > >> >Is there a reason to not continue to make the packages available in >> >non-free? >> >I don't see a reason to force any change on existing systems. >> >> Two things: >> >> 1. I'm worried what bugs we might expose by having packages be in two >> components at once. >> 2. I really don't like the idea of leaving two different >> configurations in the wild; it'll confuse people and is more >> likely to cause issues in the future IMHO. >> >> Plus, as Shengjing Zhu points out: we already expect people to manage >> the sources.list anyway on upgrades. >> >I think in the absence of a release upgrade script (which I very much >doubt will happen, and be tested, and we can rely will be used, for >bookworm), Michael's suggestion seems like a reasonable way forward. I >imagine we'll need to patch dak to allow that, but it seems like it >should be tractable? I'm also worried what effect this will have on other tools that have to grok the archive (mirror tools, debian-cd, etc.). I'm not going to try and veto having things in more than one component, but (ugh!) I really think it's ugly. Actually, I think I'd much prefer Santiago's idea: > Couldn't we handle this via transitional firware* non-free packages, > that depend on bookworm non-free-firmware packages? We'd need to add some transitional binary packages for the small number of n-f-f source packages. That way people would get errors from apt if they don't read our warnings and update. Maybe this is a way forward? -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Firmware GR result - what happens next?
On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote: >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote: >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote: >> > What's the plan for upgraded systems with an existing >> > /etc/apt/sources.list. >> > Will the new n-f-f section added on upgrades automatically(if non-free was >> > enabled before)? >> >> So this is the one bit that I don't think we currently have a good >> answer for. We've never had a specific script to run on upgrades (like >> Ubuntu do), so this kind of potentially breaking change doesn't really >> have an obvious place to be fixed. > >Is there a reason to not continue to make the packages available in non-free? >I don't see a reason to force any change on existing systems. Two things: 1. I'm worried what bugs we might expose by having packages be in two components at once. 2. I really don't like the idea of leaving two different configurations in the wild; it'll confuse people and is more likely to cause issues in the future IMHO. Plus, as Shengjing Zhu points out: we already expect people to manage the sources.list anyway on upgrades. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Re: Firmware GR result - what happens next?
On Sun, Oct 02, 2022 at 05:31:16PM +0200, Cyril Brulebois wrote: >Steve McIntyre (2022-10-02): >> * Extra d-i code to inform users about what firmware blobs have been >> loaded and the matching non-free-firmware packages. Plus information >> about the hardware involved. Maybe a new d-i module / udeb for this? >> Exact details here still TBD. Probably the biggest individual piece >> of work here. > >Not just blobs that were loaded, but also those which might get loaded >in the installed system (since we don't have all modules around), see >hw-detect.post-base-installer.d/50install-firmware in hw-detect (udevadm >vs. modalias stuff). ACK. >> * Tweaks to add the non-free-firmware section in the apt-setup module >> if desired/needed. >> >> * An extra boot option (a debconf variable) to disable loading extra >> firmware automatically, then exposed as an extra option through the >> isolinux and GRUB menus. d-i "expert mode" can also be used to tweak >> this behaviour later, except (obviously) for things like audio >> firmware that *must* be loaded early if they're going to be useful >> at all. > >The option/variable looks easy enough (once we decide what to call it)… >Not sure what would be best to expose it to users: bootloader menus >already have many options (text vs. graphical, normal vs. rescue, >accessibility settings, etc.), and don't get internationalization >support anyway. On the flip side, having to go through a full expert >installation is very nice. > >Maybe start by documenting the option (probably installation guide plus >release notes), and of course implementing it; then see if/how we expose >it? Yup. Very much in that order... :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Re: Firmware GR result - what happens next?
On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote: > >Hi Steve, > >thanks for the update! > >Am 02.10.22 um 16:27 schrieb Steve McIntyre: > >> * Tweaks to add the non-free-firmware section in the apt-setup module >>if desired/needed. > >... > >> If you think I've missed anything here, please let me and Cyril know - >> the best place would be the mailing list >> (debian-boot@lists.debian.org). > >What's the plan for upgraded systems with an existing /etc/apt/sources.list. >Will the new n-f-f section added on upgrades automatically(if non-free was >enabled before)? So this is the one bit that I don't think we currently have a good answer for. We've never had a specific script to run on upgrades (like Ubuntu do), so this kind of potentially breaking change doesn't really have an obvious place to be fixed. Obviously we'll need to mention this in the release notes for bookworm. Should we maybe talk about adding an upgrade helper tool? -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Firmware GR result - what happens next?
Hi all! [ I've also blogged about this - see https://blog.einval.com/2022/10/02#firmware-vote-result ] I'm assuming that there will be no surprises and Kurt will shortly confirm the result that devotee reported already [1]. :-) We have quite a few things to do now, ideally before the freeze for Debian 12 (bookworm), due January 2023 [2]. This list of work items is almost definitely not complete, and Cyril and I are aiming to get together this week and do more detailed planning for the d-i pieces. Off the top of my head I can think of the following: * Update the SC with the new text, update the website. * Check/add support for the non-free-firmware section in various places: + d-i build + debian-cd + debmirror (?) + ftpsync (?) + Any others? * Uploads of firmware packages targeting non-free-firmware. * Extra d-i code to inform users about what firmware blobs have been loaded and the matching non-free-firmware packages. Plus information about the hardware involved. Maybe a new d-i module / udeb for this? Exact details here still TBD. Probably the biggest individual piece of work here. * Tweaks to add the non-free-firmware section in the apt-setup module if desired/needed. * An extra boot option (a debconf variable) to disable loading extra firmware automatically, then exposed as an extra option through the isolinux and GRUB menus. d-i "expert mode" can also be used to tweak this behaviour later, except (obviously) for things like audio firmware that *must* be loaded early if they're going to be useful at all. * Update the image build scripts to include the n-f-f packages, only build one type of image. I'll do my best to keep config and support around too for images without n-f-f included, to make it easier to still build those for people who still want them. * Matching updates to docs, website, wiki etc. * ... If you think I've missed anything here, please let me and Cyril know - the best place would be the mailing list (debian-boot@lists.debian.org). If you'd like to help implement any of these changes, that would be lovely too! [1] https://lists.debian.org/debian-vote/2022/10/msg0.html [2] https://lists.debian.org/debian-devel/2022/03/msg00251.html -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: Analysis: mismatched shim* packages vs. debian-installer (opu/pu)
Thanks for the analysis and confirmation! :-) On Thu, Sep 08, 2022 at 04:16:16PM +0200, Cyril Brulebois wrote: >Hi, > >This is just a summary (TL;DR at the bottom) of my findings from the >past few days, while preparing d-i for the upcoming point releases. I >thought I would share in case anyone (e.g. future self) wonders what >might happen again in the future if we get unlucky again. I'll focus on >bullseye but buster is similar. > >I've said a few times to my fellow release team members that packages in >(old-)proposed-updates could be accepted without an explicit ACK from me >since we could side-step buggy packages by feeding our apt calls some >pinning, preferring udebs from (old-)stable over those in (old-)p-u if >we spotted some problems during pre-upload building and testing. > >That doesn't work for packages that we list in Build-Depends, and >buildds have (old-)p-u configured, so we end up pulling packages from >there as long as they're installable. > >For shim* packages, that means the following, mismatched packages when >building the debian-installer package: > >Get: 138 http://deb.debian.org/debian bullseye-proposed-updates/main amd64 > shim-unsigned amd64 15.6-1~deb11u1 [439 kB] >Get: 139 http://deb.debian.org/debian bullseye-proposed-updates/main amd64 > shim-helpers-amd64-signed amd64 1+15.6+1~deb11u1 [301 kB] >Get: 140 http://deb.debian.org/debian bullseye/main amd64 > shim-signed-common all 1.38+15.4-7 [13.6 kB] >Get: 141 http://deb.debian.org/debian bullseye/main amd64 shim-signed > amd64 1.38+15.4-7 [320 kB] > >It's likely affecting all architectures where the d-i build pulls shim >packages (but I didn't check further than amd64): > >shim-signed [amd64 i386 arm64] > >To be extra sure, I've tried putting version restrictions to stick >to bullseye packages, but sbuild/apt bail out with broken packages, >as expected: > >sbuild-build-depends-main-dummy : Depends: shim-unsigned (< > 15.6-1~deb11u1) but 15.6-1~deb11u1 is to be installed > Depends: shim-helpers-amd64-signed (< > 1+15.6+1~deb11u1) but 1+15.6+1~deb11u1 is to be installed > >I've verified two things: > - switching to the non-default aptitude resolver lets sbuild find a > solution, but that could have other side effects (that I didn't > investigate); > - introducing pinning in the chroot configuration lets us stick to > bullseye packages, affecting only shim* packages. > >Of course, both rely on having admins around to tweak the config for >that particular build, which is far from ideal. > > >Let's see what shim packages look like: > > 1. shim-unsigned /usr/lib/shim/BOOTX64.CSV >shim-unsigned /usr/lib/shim/fbx64.efi >shim-unsigned /usr/lib/shim/mmx64.efi >shim-unsigned /usr/lib/shim/shimx64.efi > 2. shim-helpers-amd64-signed /usr/lib/shim/fbx64.efi.signed >shim-helpers-amd64-signed /usr/lib/shim/mmx64.efi.signed > 3. shim-signed/usr/lib/shim/shimx64.efi.signed > 4. shim-signed-common /usr/sbin/update-secureboot-policy > >And the combination above is permitted due to lax version dependencies. >As far as I understand (and `sbverify --list` on each `*.signed` file >seems to agree), (1) gets uploaded, results in (2) getting signatures >from the Debian infrastructure; while (3) and (4) need manual MS >approval and signature. > >In the debian-installer tree, after a build, there are no traces of shim >anywhere, which was a bit surprising at first; but it turns out that >build/util/efi-image is the sole user of shim files, and it concentrates >on /usr/lib/shim/shim.efi.signed, from the shim-signed binary, but >copying it under a different name in the build tree: > > https://salsa.debian.org/installer-team/debian-installer/-/blob/20210731+deb11u5/build/util/efi-image#L147-148 > > https://salsa.debian.org/installer-team/debian-installer/-/blob/20210731+deb11u5/build/util/efi-image#L156-157 > >TL;DR: Everything matches what was already assessed by Steve McIntyre: >mismatched shim* packages shouldn't be an issue from a d-i perspective, >we're “just using the old shim” (sorry, buster…). > > >Cheers, >-- >Cyril Brulebois (k...@debian.org)<https://debamax.com/> >D-I release manager -- Release team member -- Freelance Consultant -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
On Thu, Sep 01, 2022 at 06:04:08PM +0200, Ansgar wrote: >Source: rescue >Version: 1.85 >Severity: important > >I've installed a system using btrfs for the root filesystem with d-i >(with disk encryption as well). As grub wasn't properly installed >(not registered with EFI), I tried to use the rescue mode to reinstall >grub. > >However, mounting the root filesystem failed: /target contained only a >"@rootfs" subdirectory. So running a shell in the target fs failed. >Manually mounting the filesystem with `-o subvol=@rootfs` worked. > >This was with Debian 11.4. Argh. btrfs is a total PITA with all the extra options like subvolumes. To support this everywhere in the installer, we need the help of people who care about btrfs, use it themselves and understand all the options. I don't count on any of those, and I'm not sure KiBi does either. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
