Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
Pascal Hambourg wrote: > > You can run grub-install with --no-nvram to install GRUB without writing > EFI boot variables. The Debian installer also has an option for this in > expert mode. Then you can create a custom boot entry with efibootmgr. Thanks, this is very nice => I am definitely going to test adding the following to my pressed: d-i grub2/update_nvram boolean false It could help me simplify my "preseed/late_command" script that currently deletes the default EFI entry and then creates my custom one. I guess my NVRAM will also be very grateful to you:). Jmkr
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
Pascal Hambourg wrote: > > You can set an alternative name and location by running grub-install > with --bootloader-id= or with GRUB_DISTRIBUTOR= in > /etc/default/grub. It also affects the directory name in the ESP. But > depending on the grub package version, monolithic GRUB images (signed > for secure boot) do not support being installed in another location than > /EFI/debian (I have been advocating to fix this but no luck so far). Thanks for this as well as the other info you provided - it is nice to know even if I may end up not using it (as I probably want to use "/EFI/debian" directory for GRUB with just custom EFI boot entry names). Jmkr
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
Pascal Hambourg wrote: > > You could just run grub-install to reinstall GRUB into the new ESP and > register it in EFI boot variables. I wanted to try the manual way to learn + to create my EFI boot entry with a customized name. I think GRUB installation can only create EFI boot entry with the name "debian", or is it possible to change that? > No, because in manual partitioning it is up to the user to decide which > ESP(s) is/are suitable for the installation, and set the others as "do > not use". So I must have forgotten to set the other ESP as "do not use", stupid me (I switched from MBR + BIOS to GPT + UEFI setup not so long ago and I guess it shows:). But is there a reason why DI partitioning does not set all (or previously existing) ESPs by default to "do not use" and let the user change that manually (perhaps with a reminder message if the user forgets to set the ESP in UEFI mode)? Maybe it would be more intuitive + it could avoid/minimize user errors? Or is a shared ESP so common that DI partitioning needs its current defaults? Anyway, thanks for such a quick reply. Jmkr
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
Sorry about the wrong order/formatting of last two messages. The webmail interface of Seznam.cz has totally idiotic and unconfigurable defaults and I keep forgetting to click their "Plain Text" button and keep forgetting to remove unnecessary "Quoted Reply Texts" that their idiotic interface forces on me. I will fix my Thunderbird profile to save myself from Seznam's idiotic webmail interface as soon as I have time for it. Jmkr
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
I had a similar problem with my customized Debian 10 installer. I have not customized PARTMAN related UDEB packages yet, so these are at Debian 10 versions. What I did was I installed my Debian in one of my test laptops that also had another SSD with some Windows 11 installation that I plan to nuke later:). All was working and booting, but when I added ESP capacity monitoring to my CONKY configurations, I noticed that this laptop had different ESP space occupied than my other laptops with the same hardware. After checking what is going on I found that: - The ESP created by me during manual disk partitioning on the SSD that is used for my Debian system was empty and not used at all (not mounted at "/ boot/efi" and not mentioned in "/etc/fstab"). - Instead the ESP from the other SSD with the Windows 11 installation was used. It was mounted at "/boot/efi", its UUID was in "/etc/fstab" and DI/ GRUB installed the "EFI/debian/grubx64.efi" file there right next to the "Microsoft" and "Boot" directories that contained the Windows garbage. Thankfully I did not boot that Windows 11 installation, so Windows were not able to mess around with the Debian files that rudely appeared on "their" disk. I was able to (hopefully) fix the situation when I noticed it: - I archived "/boot/efi/EFI/debian/grubx64.efi" from "/dev/sda1" to "/ Archive.tar". - Then, I unmounted "/dev/sda1" from "/boot/efi" and mounted "/dev/sdb1" to "/boot/efi" and extracted "/Archive.tar" in "/boot/efi" again. - Later I changed UUID of ESP in "/etc/fstab" file to that of ESP on "/dev/ sdb1". - Finally using EFIBOOTMGR I deleted the EFI boot entry my system used and created a new entry for ESP on "/dev/sdb1". - Then, I tested that the system boots as before using the new EFI and FSTAB entries and correct ESP. Did I forget something (that will cause problems in the future) by not reinstalling GRUB or some other stuff? Do the fixes mentioned above also address the manual partitioning case? If not perhaps you could check that case also. I will keep the Windows 11 installation (as this laptop is for testing anyway) = if you want I could test the fixed PARTMAN files, if these are provided so that my script for customizing the Debian Netinst ISO can include them (after I modify it to extract a new PARTMAN TAR or copy new PARTMAN files directly to the extracted Debian Netinst ISO). (In the future I plan to learn how to create DI ISO from scratch to be able to include modified UDEB packages etc. => if that is needed for testing and you can provide some starting instructions for me I could try that also.) Regards, Jmkr
Bug#1034812: Unbootable after install: UEFI installed to wrong ESP
By the way at "https://www.reddit.com/r/debian/comments/wfk4xt/debian_keeps_installing_bootloader_in_wrong_disk/; other people mention similar problems that are/could be related to this bug. Jmkr -- Původní e-mail -- Od: Jmkr Komu: 1034...@bugs.debian.org, pas...@plouf.fr.eu.org, k...@debian.org, deb...@jamesie.de, a...@hax0rbana.org Datum: 9. 5. 2024 10:42:41 Předmět: Re: Bug#1034812: Unbootable after install: UEFI installed to wrong ESP I had a similar problem with my customized Debian 10 installer. I have not customized PARTMAN related UDEB packages yet, so these are at Debian 10 versions. What I did was I installed my Debian in one of my test laptops that also had another SSD with some Windows 11 installation that I plan to nuke later:). All was working and booting, but when I added ESP capacity monitoring to my CONKY configurations, I noticed that this laptop had different ESP space occupied than my other laptops with the same hardware. After checking what is going on I found that: - The ESP created by me during manual disk partitioning on the SSD that is used for my Debian system was empty and not used at all (not mounted at "/boot/efi" and not mentioned in "/etc/fstab"). - Instead the ESP from the other SSD with the Windows 11 installation was used. It was mounted at "/boot/efi", its UUID was in "/etc/fstab" and DI/GRUB installed the "EFI/debian/grubx64.efi" file there right next to the "Microsoft" and "Boot" directories that contained the Windows garbage. Thankfully I did not boot that Windows 11 installation, so Windows were not able to mess around with the Debian files that rudely appeared on "their" disk. I was able to (hopefully) fix the situation when I noticed it: - I archived "/boot/efi/EFI/debian/grubx64.efi" from "/dev/sda1" to "/Archive.tar". - Then, I unmounted "/dev/sda1" from "/boot/efi" and mounted "/dev/sdb1" to "/boot/efi" and extracted "/Archive.tar" in "/boot/efi" again. - Later I changed UUID of ESP in "/etc/fstab" file to that of ESP on "/dev/sdb1". - Finally using EFIBOOTMGR I deleted the EFI boot entry my system used and created a new entry for ESP on "/dev/sdb1". - Then, I tested that the system boots as before using the new EFI and FSTAB entries and correct ESP. Did I forget something (that will cause problems in the future) by not reinstalling GRUB or some other stuff? Do the fixes mentioned above also address the manual partitioning case? If not perhaps you could check that case also. I will keep the Windows 11 installation (as this laptop is for testing anyway) = if you want I could test the fixed PARTMAN files, if these are provided so that my script for customizing the Debian Netinst ISO can include them (after I modify it to extract a new PARTMAN TAR or copy new PARTMAN files directly to the extracted Debian Netinst ISO). (In the future I plan to learn how to create DI ISO from scratch to be able to include modified UDEB packages etc. => if that is needed for testing and you can provide some starting instructions for me I could try that also.) Regards, Jmkr
Bug#867548: Playback to HDMI monitor stutters / pauses (HDMI on Haswell)
I can confirm that this bug still affects my Debian 10 systems that have kernel
from Debian 12 (currently 6.1.0-20-amd64) and use Haswell CPU (e.g. Intel Core
i74800MQ, i74810MQ, etc.). I have "VT-d" enabled in the BIOS of these laptops
and I tested that this bug occurs when I connect external monitor via:
- HDMI port on the laptop to HDMI port on the monitor
- DP or DVI port on the laptop docking station to DP or HDMI port on the monitor
and then I ensure PULSEAUDIO outputs sound to the monitor DP or HDMI port. I
also tested that passing "intel_iommu=on,igfx_off" to the kernel command line
(in GRUB config or command line) still works as a workaround.
Also on my systems I noticed that if I set PULSEAUDIO to output sound to the
monitor DP or HDMI and then start a YOUTUBE playback the audio/video starts for
a brief moment normally and then it starts to stutter and then it quickly fails
completely. Basically it looks like the playback speed starts as normal, but
then quickly increases until it is too fast for the system to handle. To test
this I switched PULSEAUDIO (using PAVUCONTROL) to "Analog Stereo Duplex" and
then back to the monitor DP or HDMI ("Digital Stereo (HDMI*)") after each
YOUTUBE playback attempt failed.
After reading this bug and the related kernel bug
(https://bugzilla.kernel.org/show_bug.cgi?id=60769) I thing that Bryan Cebuliak
and me experienced that kernel IOMMU bug that affects systems with Haswell
CPUs. However the initial reporter Daniel Pocock and Mike Fuller could had a
slightly different issue with HDMI audio. But it is hard to tell as they did
not describe the symptoms in much detail. So we may never know unless they
report back whether they still have problems with HDMI audio and whether the
"intel_iommu=on,igfx_off" kernel parameter works as a workaround for them too.
Anyway, I would like to thank Bryan Cebuliak as the information he provided
helped me find the workaround faster.
Regards,
Jmkr
Bug#1033592: Command "apt-get --target-release ..." may not work when "Pin-Priority" higher than 990 is used in "/etc/apt/preferences"
A workaround I use currently is: apt download $(sed --regexp-extended 's/^(.+)$/\1\/SUITE/' PACKAGES.txt) where "SUITE" is for example "sid" or "stable". Regards, Jmkr
Bug#922161: Grub null src bitmap error while trying to drop background image
I forgot to mention the exact GRUB versions: - My Debian 10.13 Netinst based installer had GRUB: 2.06-3~deb10u1 - My Debian 10 based installed system had GRUB: 2.06-3~deb10u4 - My Debian 11.9 Netinst based installer had GRUB: 2.06-3~deb11u6 - My Debian 11 based installed system had GRUB: 2.06-3~deb11u6 Now, I also tested with a Debian 12.5 Netinst based installer that had GRUB 2.06-13+deb12u1. My script printed some errors and warnings while generating that installer, but the installer worked good enough to confirm that this bug also affects the Debian 12 installer. I did not test the Debian 12 installed system (but I guess it could be unaffected like my Debian 10 and 11 installed systems).
Bug#922161: Grub null src bitmap error while trying to drop background image
I can confirm this bug occurs also on my customized installers. I unfortunately still generate my installers from Debian 10.13 and 11.9 Netinst images (not enough time to migrate to Debian 12). When I recently switched to UEFI booting with my GRUB theme without a background image I started to get the "error: null src bitmap in grub_video_bitmap_create_scaled." message. My GRUB menu does not have submenus, but the error message appears after I press ENTER to run any GRUB menu entry. Booting of the given entry continues after a delay or when one hits a key, but it still makes the user experience feel "buggy". My GRUB theme uses "desktop-color" instead of "desktop-image" which is probably the cause of the error message. I found a workaround here: https://github.com/grml/grml-live/commit/8a09c98f94a43bdccd8699e200b66ab81f9102bf But on my installed systems this same GRUB theme works without that error, which is odd as the GRUB versions are (nearly) the same for the installers and installed systems. Anyway, since I want to keep my GRUB theme nice and simple + same for installers as well as installed systems, I do not want images in the theme. I use the theme just to be able to change the font, menu positioning and texts (title, messages). Thus, it would be nice if this bug gets fixed or if someone suggests a better workaround. Regards, Jmkr
Bug#859458: Because of displays with very high dpi, not only the keyboard, but the font has to be configured early
Here you go. Both scripts are in the attached "SCRIPTS.txt". Note that on my systems I keep only the one PSF font that I actually use, so my hook script does not need to update cached fonts + my systems are without PLYMOUTH. Check Pedro's scripts if you need to handle those more complex usages. Regards, JmkrSCRIPT 1 "/etc/initramfs-tools/hooks/console-setup": #!/bin/sh case "$1" in prereqs) echo 'keymap' exit 0;; esac . /usr/share/initramfs-tools/hook-functions if [ -x /bin/plymouth ]; then echo 'W: Graphical boot splash prevents setting console fonts.' fi fontfile=$(ls -1 -t /etc/console-setup/cached_*.psf.gz 2>/dev/null | head -n 1) if [ -n "$fontfile" ] && [ -r "$fontfile" ]; then copy_exec /bin/setfont copy_file font "$fontfile" fi if [ ! -x "$DESTDIR"/bin/setfont ]; then echo 'E: Failed to copy the "/bin/setfont" executable.' exit 1 fi if [ ! -r "$DESTDIR$fontfile" ]; then echo "E: Failed to copy the \"$fontfile\" file." exit 1 fi -- SCRIPT 2 "/etc/initramfs-tools/scripts/init-top/console-setup": #!/bin/sh case "$1" in prereqs) echo 'udev keymap' exit 0;; esac fontfile=$(ls -1 -t /etc/console-setup/cached_*.psf.gz 2>/dev/null | head -n 1) if [ -x /bin/setfont ] && [ -n "$fontfile" ] && [ -r "$fontfile" ]; then setfont "$fontfile" fi
Bug#859458: Because of displays with very high dpi, not only the keyboard, but the font has to be configured early
I checked the INITRAMFS-TOOLS source code and the "PREREQ" variable + "prereqs" function seems redundant - details are in a new bug I submitted: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067804 I also found an alternative to Jörg's scripts that could be useful for Plymouth boot splash users: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857132#207 Although Plymouth is not installed on my systems I adapted some safety check bits from those scripts for my systems. So thanks again Jörg Sommer and Pedro Dias:). Regards, Jmkr
Bug#1067804: Possibly redundant "PREREQ" variable + "prereqs" function recommended by the INITRAMFS-TOOLS(7) manpage
Package: initramfs-tools
Version: 0.142
Dear maintainers,
while adapting a workaround for bug 859458 on my systems I noticed a
redundant-looking "PREREQ" variable + "prereqs" function recommended by the
INITRAMFS-TOOLS(7) manpage (that code is pasted in multiple places in that
manpage). See initial details in my message to that bug (the QUESTION part):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859458#51
Later I checked the INITRAMFS-TOOLS source code:
- The "get_prereq_pairs" function from the "hook-functions" file (that installs
to "/usr/share/initramfs-tools/hook-functions") calls INITRAMFS scripts with
the "prereqs" argument. So each script can output a space separated list of
prereqs names that is then used to order the scripts in the same directory (see
the "cache_run_scripts" function in that "hook-functions" file).
- I did not find any relevant places in the INITRAMFS-TOOLS source code where
the "PREREQ" variable or "prereqs" function is used externally (e.g. after
sourcing INITRAMFS scripts or for searching in the scripts).
So my initial assumption that the uppercase name of the "PREREQ" variable could
mean that it is used globally/externally somewhere else in the INITRAMFS-TOOLS
source code was not confirmed (unless I missed something). Same goes for the
"prereqs" function, so I really do not know why the INITRAMFS-TOOLS(7) manpage
recommends such redundant source code that most INITRAMFS scripts then follow.
Some INITRAMFS scripts I looked at however use "PREREQS" instead of "PREREQ"
variable and some skip the redundant-looking "PREREQ" variable + "prereqs"
function completely.
After my search + testing I now think that it is sufficient to just use the
"echo 'PREREQ1 ...'" directly in the case statement (see below). I tested on
multiple systems (3 laptops with GUI, 3 VMs with GUI 2 VMs without GUI) that my
INITRAMFS scripts without the redundant "PREREQ" variable + "prereqs" function
work and my systems boot fine. I also extracted my INITRAMFS with UNMKINITRAMFS
and checked the "/main/scripts/*/ORDER" files to confirm that all my INITRAMFS
scripts were correctly ordered.
Thus, I think the INITRAMFS-TOOLS(7) manpage should be updated, so that it
either explains the purpose of the redundant "PREREQ" variable + "prereqs"
function or avoids those redundant parts and uses for example just the case
statement:
case "$1" in
prereqs)
echo 'PREREQ1 PREREQ2 PREREQ3 ...'
exit 0;;
esac
Also if "PREREQ" variable + "prereqs" function really is redundant all affected
INITRAMFS scripts (= most of them) could be simplified a bit.
Regards,
Jmkr
Bug#859458: Because of displays with very high dpi, not only the keyboard, but the font has to be configured early
Hello,
I also hit this bug when switching from BIOS to UEFI boot process. Details for
context are in the next paragraph, but feel free to skip to the QUESTION part:).
After disabling the legacy BIOS support on my machines I noticed UEFI boot
process uses the native LCD resolution. This causes smaller looking console
fonts. It also makes GRUB use its GFXTERM font that in addition to being small
has completely different style compared to "Uni2-VGA16.psf.gz". I previously
used that ugly default looking font just to avoid even uglier noticeable font
switching (during both booting and installing Debian). Thanks to Jörg Sommer's
scripts I was finally able to set a much nicer and more adequately sized font
("Uni2-TerminusBold24x12.psf.gz") without noticeable font switching during
booting. I did not finish integrating this into my customized Debian installer
yet, but it is still a nice improvement for my machines.
QUESTION:
I have one question about INITRAMFS-TOOLS PREREQ mechanism. My other scripts
use this redundant-looking "PREREQ" variable + "prereqs" function:
...
PREREQ='...'
prereqs () {
echo "$PREREQ"
}
case "$1" in
prereqs)
prereqs
exit 0;;
esac
...
I tested that all my INITRAMFS-TOOLS scripts work with this code or without it
(= echo '...' directly in "case" statement like in Jörg's scripts) - at least
the system boots fine. But I noticed that the INITRAMFS-TOOLS(7) manpage also
recommends such code. So does anyone know if and why the "PREREQ" variable +
"prereqs" function is really necessary?
Regards,
Jmkr
Bug#1064073: Some obsolete Conky build flags found in the "debian/rules" file
Source: conky
Version: 1.19.6-1
Dear Maintainer,
while building Conky 1.19.6-1 from Debian Sid on my Debian 10 system. I noticed
that the following build flags no longer seem to exist in the Conky source code:
BUILD_EVE
BUILD_WEATHER_METAR
BUILD_WEATHER_XOAP
Here is a link to the commit that dropped the weather related source code:
https://github.com/brndnmtthws/conky/commit/25e6598c90113e9924510a253ba508975cd463cd
For the "BUILD_EVE" flag I did not find the commit that dropped it, but at
least "grep" was unable to find any "BUILD_EVE" strings in Conky source code
files.
Unfortunately I also found that Conky 1.19.6-1 is still affected by the bug
that causes it to crash on any config reload. This occurs when "use_xft = true"
is in my config and it is reported as upstream issue
"https://github.com/brndnmtthws/conky/issues/1538;. If you know about any
workaround I would be grateful (I described details of how I built and tested
Conky in a comment to that issue:
"https://github.com/brndnmtthws/conky/issues/1538#issuecomment-1948943144;.).
By the way bug 791355
("https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791355;) can probably be
closed as the upstream issue 106
("https://github.com/brndnmtthws/conky/issues/106;) was closed in 2018. Also
bug 684425 ("https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684425;) could
probably be closed (see my last comment to that bug for details).
Regards,
Jmkr
Bug#684425: conky-std: please implement an alternative way to distinguish among hwmon devices
This bug could probably be closed as it is now possible to use device names
instead of numbers for "${hwmon ...}". I tested that it works when I did my
build of Conky 1.19.6-1 from Debian Sid. It was implemented in the Conky
commit "https://github.com/brndnmtthws/conky/commit/14e3b80c45254743e962f88d
027a7ea37bf59ee6".
Regards,
Jmkr
Bug#1034486: Network manager applet VPN notification should use a standard icon name
Package: network-manager-gnome Version: 1.8.20-1.1 Dear Maintainers, the icon in the network manager applet VPN connection notification uses the name "gnome-lockscreen" (in the "src/applet.c" file). This name is not present in modern icon themes such as Adwaita and thus a recommends dependency on "gnome-icon-theme" was added to "network-manager-applet" source package in version 1.24.0-2 (to solve Debian bug 990252). Perhaps it would be better to use the standard icon name for this icon instead and avoid the recommends dependency on "gnome-icon-theme". According to Standard Icon Names in the Icon Naming Specification (https://specifications.freedesktop.org/icon-naming-spec/latest) the most suitable name is "system-lock-screen". Maybe an optional symbolic icon name "system-lock-screen-symbolic" could be also supported for users who prefer symbolic icons (to maybe stay compatible with their monochrome display or because they find it confusing to see colors, options in settings and so on:). Jokes aside, the icon name "gnome-lockscreen" is also used in the current stable, testing and unstable versions: Package: network-manager-gnome Version: 1.8.20-1.1 Version: 1.20.0-3 Version: 1.30.0-2 Regards, Jmkr
Bug#1033592: Command "apt-get --target-release ..." may not work when "Pin-Priority" higher than 990 is used in "/etc/apt/preferences"
I just forgot to add that, at least according to APT-GET(8), priority 990 is used also in the current stable, testing and unstable versions: Package: apt Version: 2.2.4 Version: 2.6.0 Regards, Jmkr
Bug#1033594: The diversion of "/usr/bin/firefox" by "firefox-esr" package does not respect a previously added local diversion
Package: firefox-esr Version: 102.9.0esr-1~deb10u1 Dear Maintainers, the diversion of "/usr/bin/firefox" to "/usr/bin/firefox.real" by "firefox-esr" package does not respect a local diversion previously added by local admin. If such a local diversion exists it prevents the "firefox-esr" package installation from completing successfully (and probably also prevents any "firefox-esr" package updates until this bug is fixed). This can be tested easily assuming the "firefox-esr" package is already installed: - Replace the "firefox-esr" package diversion by a local diversion: dpkg-divert --no-rename --remove /usr/bin/firefox dpkg-divert --divert /usr/bin/firefox.dpkg-dist --local --rename \ --add /usr/bin/firefox - Reinstall the "firefox-esr" package and an error should occur (line breaks added to avoid line wrapping by email software): dpkg-divert: error: 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr' clashes with 'local diversion of /usr/bin/firefox to /usr/bin/firefox.dpkg-dist' dpkg: error processing archive /var/cache/apt/archives/firefox-esr_102.9.0esr-1~deb10u1_amd64.deb (--unpack): new firefox-esr package pre-installation script subprocess returned error exit status 2 - To cleanup: - Remove the local diversion: dpkg-divert --rename --remove /usr/bin/firefox - Add back the "firefox-esr" package diversion: dpkg-divert --package firefox-esr --divert /usr/bin/firefox.real \ --rename /usr/bin/firefox The bug could be easily fixed by adding some check for a previously added diversion instead of just blindly trying to add the "firefox-esr" package diversion to the system. For example "dash" package in its "postinst" script checks for and respects any previously added local diversions before adding its own diversions. Thus, adapting that check for "firefox-esr" package "preinst" script could be as easy as replacing line 4 of the "preinst" script with this condition: if [ $(dpkg-divert --listpackage /usr/bin/firefox) != LOCAL ]; then dpkg-divert --package firefox-esr --divert /usr/bin/firefox.real \ --rename /usr/bin/firefox fi This should probably also help with (or even fix) Debian bug 861783. Regards, Jmkr
Bug#1033592: Command "apt-get --target-release ..." may not work when "Pin-Priority" higher than 990 is used in "/etc/apt/preferences"
Package: apt Version: 1.8.2.3 Severity: minor Dear Maintainers, on my system (Debian 10 with some backports) I have pinned most packages to Debian Buster with priority 1000 (in "/etc/apt/preferences"). This is my attempt to handle unattended upgrades upgrading a package that had the same version in stable and oldstable and then gets updated in stable only. I want any such package to be automatically downgraded to oldstable version even if it was accidentally updated to stable version (i.e. I want automatic unattended upgrades to stick with my target release as much as possible by default). However I noticed that it is no longer possible to use one time package download commands with different target release (e.g. to download selected packages just for inspecting or extracting templates) such as: apt-get --target-release stable download $(Perhaps the "-t, --target-release, --default-release" option could create a pin at some higher priority than 990. If priority 990 is required to avoid some unwanted side effects for that option maybe another option like "--force-target-release" with pin at higher priority could be useful in cases like this. Regards, Jmkr
Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file
Sorry for the delay, I had to do some work and then forgot that I
planned to reply to this bug.
> Philip Hands writes:
> ...
>
> Actually, given that we don't care what's in the first field at that
> point, and it's already matched the start of the country code, I think
> this ought to work as well:
>
> "/^${L%%_*}/"'{s/^[^;]*;\([0-9]\);.*/\1/p;q}'
Yes, it works perfectly when I tested the "sed" command both in a
terminal and also in my customized DI in the
"./usr/lib/post-base-installer.d/05localechooser" file.
Although, I did not test the generated ISO and whether the whole locale
chooser mechanism now works as intended with locales that have level 3+
(i.e. if DI actually creates the "/target/root/.profile" file for such
locales). Since I don't use such locales on my systems it would be
difficult for me to test this. I don't know the languages, so I probably
would not be able to finish the DI using one of these languages:).
Cheers, Jmkr
Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file
> Philip Hands writes:
> ...
>
> BTW I would suggest using:
>
> ${LOCALE%%_*} in place of the $(echo ... | cut ...)
Yes, I ended using that too in my version of the script, but I sent the
bug report earlier:).
Philip Hands writes:
...
This is what it should have been:
https://salsa.debian.org/philh/localechooser/-/commit/1e511957c05724bb417c07a84894bcb999a95b28
The subsequent commits in both versions of that branch did arrive at the
same destination, even if the middle bit was a bit tangled.
...
Cheers, Phil.
I tested Phil's "sed" command in terminal like this (all one line -
email splits it):
L=cs_CZ.UTF-8; sed -n
"/^${L%%_*}/"'{s/^[[:alpha:]]*;\([[:digit:]]\);.*/\1/p;q}' languagelist
and it seemed to work - with "cs_CZ.UTF-8" locale it returned 2. But
some locales still returned wrong level. After using a modified "sed"
command I think I got it working even for locales like "zh_TW.UTF-8" or
"nn_NO.UTF-8" etc.:
L=zh_TW.UTF-8; sed -n "/^${L%%_*}/"'{s/^[A-Za-z_]*;\([0-9]\);.*/\1/p;q}'
languagelist
returns 3 and with "nn_NO.UTF-8" it returns 1. I guess "[[:alpha:]]"
does not include "_".
Anyway it is a nice improvement doing all the work with one "sed"
process compared to that "wild pipelined bunch of cutting greps and
heads". So, thanks to what Phil "sed", I am now upgrading my version of
the script to the "sed" approach:).
Cheers, Jmkr
Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file
Package: localechooser Version: 2.94 Dear Maintainers, While working on my customized Debian installer (DI) I noticed that the "./usr/lib/post-base-installer.d/05localechooser" file from the "localechooser_2.93_*.udeb" package (at least for AMD64 and ARM64 architectures) contains probably buggy source code for calculating the value of the "LEVEL" variable (on lines 87-91). The problems are in "cut" commands (on lines 88 and 91) which should probably be: cut -f 1-3 -d \; cut -f 2 -d \; Currently the "LEVEL" variable seems to get the empty string value because the "grep" command (on line 89) cannot find the language code (because the first field is removed by the first "cut" command). Maybe the "LANGUAGECODE" variable on line 83 could be avoided and merged into the "LEVEL" variable if command substitution is done using "$(...)" resulting in this proposed source code: LEVEL=$(cat /usr/share/localechooser/languagelist | \ cut -f 1-3 -d \; | \ grep $(echo $LOCALE | cut -f 1 -d _) | \ head -n 1 | \ cut -f 2 -d \;) My customized DI (with various other removed and modified files) seems to work normally with the mentioned proposed source code. I also successfully tested the proposed source code for calculating the value of the "LEVEL" variable on the "./usr/share/localechooser/languagelist" file from the "localechooser_2.93_*.udeb" package. I checked the "localechooser" 2.94 package and the "05localechooser" file is the same (and "languagelist" file structure is also the same), but verify/test what I found if needed. Best Regards Jmkr
Bug#1011252: The UDEB package "mountmedia" contains probably some obsolete source code in "mountmedia" file
Package: mountmedia Version: 0.25 Dear Maintainers, While working on my customized Debian installer (DI) I noticed that the DI INITRD from the current "debian-11.3.0-*-netinst.iso" files (at least for AMD64 and ARM64 architectures) contains probably obsolete source code in the following file: - In the "./bin/mountmedia" file from the "mountmedia_0.25_all.udeb" at least the lines 31-35 could be obsolete, because according to "https://bugzilla.kernel.org/show_bug.cgi?id=7875; the mentioned bug was fixed ages ago. My customized DI seems to work normally without the mentioned source code. But I did not test mounting of any floppy media during installations and my DI also has various other removed and modified files, so verify/test what I found if needed. Best Regards Jmkr
Bug#1011250: The UDEB package "hw-detect" contains probably obsolete file "60install-mouseemu"
Package: hw-detect Version: 1.148 Dear Maintainers, While working on my customized Debian installer (DI) I noticed that the DI INITRD from the current "debian-11.3.0-*-netinst.iso" files (at least for AMD64 and ARM64 architectures) contains probably obsolete source code in the following file: - In the "./usr/lib/post-base-installer.d/60install-mouseemu" file from the "hw-detect_1.147_*.udeb" package (at least for AMD64 and ARM64 architectures) all source code seems to be obsolete, because the "mouseemu" package was removed from Debian approx. 2 years ago (see "https://tracker.debian.org/pkg/mouseemu;). I checked the "hw-detect" 1.148 package and the "60install-mouseemu" file is the same. My customized DI seems to work normally without the mentioned source code. But my DI also has various other removed and modified files, so verify/test what I found if you need. Best Regards Jmkr
