Bug#991426: release-notes: Recommend user.max_user_namespaces over kernel.unprivileged_userns_clone?
On Fri, 2021-07-23 at 10:25 +0100, Simon McVittie wrote: > Package: release-notes > Severity: normal > Tags: patch moreinfo > X-Debbugs-Cc: debian-ker...@lists.debian.org > > If I understand correctly, user.max_user_namespaces is an upstream kernel > feature, but kernel.unprivileged_userns_clone comes from a Debian-specific > patch that might be removed in future releases. It seems better to recommend > the upstream version (also used in e.g. RHEL). > > A possible patch is attached, but I'd prefer to get confirmation from > a kernel maintainer before applying this, hence tagged +moreinfo. I agree that this may be more future-proof (though it's taken little effort to maintain that patch over the last 8 years). Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Re: release notes mentioning dropped support?
wOn Mon, 2021-06-14 at 06:25 +0100, Justin B Rye wrote: > Paul Gevers wrote: > > + > > + Hardware that's no longer supported > > The contraction "that's" seems out of place in a title - probably we > should just use: > > No longer supported hardware > That would correctly be spelt with hyphens: No-longer-supported hardware > > + > > + Due to hardware limitations, it's no longer viable for Debian > > + to build the Linux kernel supporting a > > + number of armel based devices that were supported in > > + buster. The unsupported devices are: > > This sounds as if it's talking about one kernel supporting multiple > armel-based devices; if it means one kernel per device, that's plural. We've used only a single kernel flavour (marvell) for these devices since before the stretch release. [...] > > + Users of those platforms that wish to upgrade to bullseye > > + nevertheless should keep the buster APT sources enabled and, > > + before upgrading, add an APT preferences file containing > > + something like: > > Users of these platforms who wish to upgrade to bullseye > nevertheless should keep the buster APT sources enabled, and > before upgrading should add an APT preferences file containing > something like: > > (Or maybe as two sentences, "Before upgrading they should...") Also we should not say "something like" since that suggests that some system-specific adjustment is needed. I originally included those words because I hadn't tested this configuration, but Paul said he will. > > > + > > +Package: linux-image-marvell > > +Pin: release a=buster > > +Pin-Priority: 900 > > + > > + Obviously, the security support for this configuration will > > + end with the End Of Life of buster. > > Obviously, the security support for this configuration will > only last until buster's End Of Life. We (generally) shouldn't say "obviously" in documentation - if we bothered to document it, it must not be that obvious. Ben. -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part
Re: release notes mentioning dropped support?
On Sat, 2021-06-12 at 03:01 +0900, Roger Shimizu wrote: > On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso > wrote: > > > > Hi, > > > > On Thu, Jun 10, 2021 at 11:32:23AM +0200, Paul Gevers wrote: > > > Hi Kernel team, > > > > > > I know everybody is busy, but friendly ping. > > > > > > On 24-05-2021 06:55, Paul Gevers wrote: > > > > I happen to own a QNAP (armel) and I spotted in the changelog that it's > > > > not going to be supported in bullseye. I was wondering, is that > > > > something that should be mentioned in the release notes? Obviously I > > > > don't mean because I own it, but I'm betting that support for particular > > > > hardware pieces has been dropped in the past too. I don't recall > > > > something like that in the buster release notes, but even if we didn't > > > > do it in the past, now could be a good moment to start if we think we > > > > should add it. > > for armel, the limitation is by: > https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/armel/defines#L35 > > And from the list in that file, below devices are not supported now. > # QNAP TS-119/TS-219: 2097152 - 64 = 2097088 > # D-Link DNS-323: 1572864 - 8 - 64 = 1572792 (too small, no longer supported) > # HP Media Vault mv2120: 2097152 - 8 - 64 = 2097080 > # QNAP TS-109/TS-209 & TS-409: 2097152 - 8 - 64 = 2097080 > > I guess support for D-Link DNS-323 was dropped since buster, or earlier. Yes, since stretch. > > > > > Either way, I was wondering what would happen if I try to upgrade such a > > > > device. I'm *assuming* that the linux package would detect that the > > > > image is too big, but what would that leave me? A fully upgraded system > > > > with an old kernel, or is there any detection before any upgrade > > > > happens? For owners of such devices, is their only option to stay at > > > > buster? E.g. is there any chance in building a smaller custom kernel > > > > with less options enabled or is that impossible because nearly > > > > everything is build as module? > > The upgrade of kernel may succeed if /boot still have enough space, > but reboot will fail because of the uboot configuration hard coded in > those hardware. [...] My understanding is that these devices load the kernel and initramfs from fixed partitions on the on-board flash, not from the filesystem. That's why the limits vary. flash-kernel is responsible for copying the kernel and initramfs to these partitions. When the kernel is too large, it will report an error, which should abort the package installation. To avoid this, users should keep the buster sources enabled and, before upgrading, add an APT preferences file containing something like: Package: linux-image-marvell Pin: release a=buster Pin-Priority: 900 (not tested). Obviously this will only work as long as buster is supported. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Bug#987777: Linux enabled user namespaces by default
On Thu, 2021-04-29 at 12:31 +0200, Paul Gevers wrote: > Package: release-notes > > Hi Ben, Simon, > > On Thu, 16 Apr 2020 03:09:25 +0100 Ben Hutchings > > wrote: > > So I think we should do something like this: > > > > * Document user.max_user_namespaces in procps's shipped > > /etc/sysctl.conf > > * Set kernel.unprivileged_userns_clone to 1 by default, and > > deprecate > > it (log a warning if it's changed) > > * Document the change in bullseye release notes > > I just stumbled over bug 898446 because of Simon's reply to bug > 985617. > I pretty sure the last point still needs to happen. I found this in > the > NEWS, that looks pretty good as a starting point. Does either of you > have anything to add? [...] I have nothing to add to this. Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
Bug#985470: Bug#985463: debian-installer: kernel complains about /boot partition in LVM install (ext2 filesystem being mounted at /boot supports timestamps until 2038)
On Thu, 2021-03-18 at 20:33 +0100, Paul Gevers wrote: > Control: tags -1 moreinfo > > Hi Ben, > > On Thu, 18 Mar 2021 19:51:47 +0100 Ben Hutchings > > wrote: [...] > > > The same problem exists in the Debian buster installer and will > > > show > > > up when buster systems are upgraded to a 5.10 kernel. > > > > Since we don't have a specific upgrade program, I think the best we > > can > > do about this is to document it in the release notes. > > I guess we can only warn about the warning and say that ... what > exactly? I don't think you're suggesting we should now go figure out > what to advise to update the used /boot partition? I was thinking that we could refer to documentation for how to upgrade it in-place. Now I realise that won't help: the inodes will still be 128 bytes in size, which is not large enough to support extended timestamps. The obvious alternative would be to move the contents of /boot onto the root filesystem and stop using the separate /boot partition altogether. But this is a relatively complex process where a mistake can easily leave the system unbootable. I'm also unsure whether LUKS support in GRUB is properly integrated in Debian. So you're probably right that the release notes shouldn't tell people to do that. Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part
Bug#925971: release-notes: should mention secure boot in d-i
On Fri, 2019-03-29 at 16:45 +0100, Paul Gevers wrote: > Package: release-notes > X-Debbugs-CC: debian-b...@lists.debian.org > > As now discussion on the RT sprint, the release notes should probably > say something about the work on secure boot. > > I wouldn't know what to put in, so proposals are welcome. Until that > time, I file this bug to not forget. I don't have a complete proposed text, but I think the key points to include are: * Secure Boot is a feature enabled on most PCs that prevents loading unsigned code, protecting against some kinds of bootkit and rootkit. * Debian can now be installed and run on most PCs with Secure Boot enabled. * It is possible to enable Secure Boot on a system that has an existing Debian installation, if it already boots using UEFI. Before doing this, it's necessary to install shim-signed, grub-efi-amd64-signed or grub-efi-ia32-signed, and a Linux kernel package from buster. * Some features of GRUB and Linux are restricted in Secure Boot mode, to prevent modifications to their code. * More information can be found on the Debian wiki at <https://wiki.debian.org/SecureBoot>. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
On Wed, 2019-03-27 at 22:52 +, vincent.mcint...@csiro.au wrote: [...] > I agree with everything you've said about this text but as regards > the patch I think some mention of tracking packages should be kept. > Something like: > > One class of dummy package that are not intended to be removed > are tracking packages, which are used to keep > track of the current available version of a program over time. > A common case is linux-image--. Why do you want to introduce the term "tracking package" when we already have the term "metapackage"? Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
Re: Documenting installer issues for jessie LTS
On Sat, 2018-11-10 at 22:55 +0100, Laura Arjona Reina wrote: > Hello all > > El 9/11/18 a las 2:50, Ben Hutchings escribió: > > I recently discovered a bug in the installer (#908711). During > > installation with network sources enabled, security update are normally > > installed. However, this didn't include updates that depend on a new > > binary package, due to a kernel or library ABI change. > > > > I fixed this bug in unstable and in a stable update that will be > > included in Debian 9.6. However, since there are no stable updates > > during the LTS period, this bug will remain unfixed in the installer > > for jessie. > > > > I have updated the wiki LTS/Installing page and added post-installation > > steps to install the missed upgrades. However, I wonder whether it > > would be helpful and possible to update the release notes or other > > official documentation at this stage? > > > > Ben. > > > > Thanks for reporting. > > For the website, I have created the merge request with a proposal: > > https://salsa.debian.org/webmaster-team/webwml/merge_requests/40 I assume this is going to appear at <https://www.debian.org/releases/jessie/debian-installer/>. That seems a fairly prominent place, though the errata are quite a way down the page so may be missed. > (I'm attaching the diff too). > > Comments and/or improvements very welcome (CC'ing debian-boot). If there > is no activity, I plan to merge this in a week or so. > > Respect to the release notes, I'm not sure if this documentation should > go there and in which section specifically (CC'ing debian-doc for help). Since the release notes are mostly concerned with upgrades, and this doesn't affect upgrades, I now think this may not be worth doing. Ben. > We have fixed our cron script for publishing the release notes against > git (thanks Baptiste Jammet, and sorry for the delay!) and this means > that if a patch is accepted in the jessie branch of the release notes > (https://salsa.debian.org/ddp-team/release-notes/ ), it will be > published in the website too (we will build jessie release notes for the > website at least until the LTS support finishes). > > Kind regards -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part
Bug#865120: release-notes: document i386/amd64 kernel changes for jessie->stretch
On Mon, 2017-06-19 at 23:37 +1000, Stuart Prescott wrote: > Package: release-notes > Severity: important > > With Stretch, amd64 flavour kernels are no longer supplied within the i386 > Debian architecture (i.e. for a 64 bit kernel with a 32 bit userspace). The > release notes should document that these kernel packages are no longer > offered so that users don't accidentally run unsupported kernels indefinitely > (hence severity:important). [...] You're quite right, this should have been documented. It might be worth mentioning linux-headers-amd64 as well. Also, module-assistant doesn't support foreign architectures but DKMS is fine. Ben. -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed. - Carolyn Scheppner signature.asc Description: This is a digitally signed message part
Bug#783012: 'Kernel flavour selection' for i386 does not apply to wheezy upgrade
Package: release-notes Severity: normal Tags: patch The removal of the '686' flavour happened in wheezy and should not be mentioned in the jessie release notes. (There is another flavour change in jessie: '486' was replaced by '586'. But it's probably not worth noting as the CPU features required have not changed, only the name has changed to reflect reality.) Ben. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Index: en/upgrading.dbk === --- en/upgrading.dbk (revision 10789) +++ en/upgrading.dbk (working copy) @@ -871,26 +871,6 @@ /para /section -section arch=i386 id=kernel-flavour-686 - titleKernel flavor selection/title - para -Debian's literal686/literal kernel configuration has been replaced by -the literal686-pae/literal configuration, which uses PAE -(quotePhysical Address Extension/quote). If your computer is currently -running the literal686/literal configuration but does not have -PAE, you will need to switch to the literal486/literal configuration -instead. You can check whether your computer has PAE by running: -screen -$ grep -q '^flags.*\bpae\b' /proc/cpuinfo amp;amp; echo yes || echo no/screen -If it does not (i.e. the above command outputs literalno/literal), you -should install systemitem role=packagelinux-image-486/systemitem and -then remove systemitem role=packagelinux-image-686/systemitem and/or -systemitem role=packagelinux-image-2.6-686/systemitem if they are -currently installed. - /para - -/section - section id=minimal-upgrade titleMinimal system upgrade/title para
Bug#782895: Incorrect indentation of some screen text
Package: release-notes
Severity: normal
Tags: patch
As the text inside the screen element is considered preformatted,
it should not be indented like the surrounding text.
Indenting the end-tag results in an extra blank line in the output.
Ben.
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Index: en/issues.dbk
===
--- en/issues.dbk (revision 10778)
+++ en/issues.dbk (working copy)
@@ -102,7 +102,7 @@
by using:
screen
$ echo 'openssh-server openssh-server/permit-root-login boolean true' | debconf-set-selections
-/screen
+/screen
/para
/section
@@ -332,7 +332,7 @@
Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1
- /screen
+/screen
caution
para
Be advised that some packages may have degraded behavior or
@@ -408,14 +408,14 @@
/para
screen
debsums -c -e | grep ^/etc/init.d
- /screen
+/screen
paraAlternatively, the following can be used in the absence of
debsums.
/para
screen
- dpkg-query --show -f'${Conffiles}' | sed 's, /,\n/,g' | \
-grep /etc/init.d | awk 'NF,OFS= {print $2, $1}' | \
-md5sum --quiet -c
+dpkg-query --show -f'${Conffiles}' | sed 's, /,\n/,g' | \
+ grep /etc/init.d | awk 'NF,OFS= {print $2, $1}' | \
+ md5sum --quiet -c
/screen
para
If either command flags any files and their corresponding packages
@@ -486,10 +486,10 @@
logind to ignore ACPI events by adding:
/para
screen
-HandlePowerKey=ignore
-HandleSuspendKey=ignore
-HandleHibernateKey=ignore
-HandleLidSwitch=ignore
+HandlePowerKey=ignore
+HandleSuspendKey=ignore
+HandleHibernateKey=ignore
+HandleLidSwitch=ignore
/screen
para
to filename/etc/systemd/logind.conf/filename. Note that this
@@ -533,7 +533,7 @@
PrivateDevices=yes
PrivateNetwork=yes
ProtectSystem=yes
- /screen
+/screen
para
If you do not use systemd, or can assert that none of the systemd
services will use the above directives, the config option might not
@@ -635,8 +635,8 @@
using the following command:
/para
screen
-# /sbin/cryptsetup luksDump replaceablelt;disk-devicegt;/replaceable | grep -i whirlpool
- /screen
+# /sbin/cryptsetup luksDump replaceablelt;disk-devicegt;/replaceable | grep -i whirlpool
+/screen
para
For more information on migrating, please see item 8.3 Gcrypt
1.6.x and later break Whirlpool of the ulink
@@ -774,8 +774,8 @@
you can preseed the questions by using the following:
/para
screen
-echo 'base-passwd base-passwd/system/replaceableusername/replaceable/shell/replaceablecurrent-shell-mangled/replaceable/_usr_sbin_nologin boolean false' | debconf-set-selections
- /screen
+echo 'base-passwd base-passwd/system/replaceableusername/replaceable/shell/replaceablecurrent-shell-mangled/replaceable/_usr_sbin_nologin boolean false' | debconf-set-selections
+/screen
para
Where replaceableusername/replaceable is the name of the user
in question and replaceablecurrent-shell-mangled/replaceable
Index: en/upgrading.dbk
===
--- en/upgrading.dbk (revision 10778)
+++ en/upgrading.dbk (working copy)
@@ -201,7 +201,7 @@
/para
screen
mount -o remount,rw /
- /screen
+/screen
para
More information on debugging a broken boot under systemd
can be found in the ulink
@@ -1195,7 +1195,7 @@
To see a list of available linux-image metapackages, run:
/para
screen
- # apt-cache search linux-image- | grep -i meta | grep -v transition
+# apt-cache search linux-image- | grep -i meta | grep -v transition
/screen
para
@@ -1333,8 +1333,8 @@
may have configuration files left on the system (if any):
/para
screen
-# dpkg -l | awk '/^rc/ { print $2 }'
- /screen
+# dpkg -l | awk '/^rc/ { print $2 }'
+/screen
para
The packages can be removed by using commandapt-get
purge/command. Assuming you want to purge all of them
@@ -1341,16 +1341,16 @@
in one go, you can use the following command:
/para
screen
-# apt-get purge $(dpkg -l | awk '/^rc/ { print $2 }')
- /screen
+# apt-get purge $(dpkg -l | awk '/^rc/ { print $2 }')
+/screen
para
If you use systemitem role=packageaptitude/systemitem, you
can also use the following alternative to the commands above:
/para
screen
-$ aptitude search '~c'
-$ aptitude purge '~c'
- /screen
+$ aptitude search '~c'
+$ aptitude purge '~c'
+/screen
/section
/section
Bug#782178: Changes to root and /usr filesystem mounting and checking
Control: retitle -1 Changes to root and /usr filesystem mounting and checking Control: tag -1 patch There are several other issues with the initramfs-tools changes that will require manual configuration changes on some systems. I'm expanding this bug to cover all of them, and attaching a patch with my text, closely based on what I already put in the package's NEWS file. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. Index: en/issues.dbk === --- en/issues.dbk (revision 10778) +++ en/issues.dbk (working copy) @@ -547,6 +547,63 @@ /para /section +section id=initramfs-tools-issues + !-- Wheezy to Jessie -- + titleChanges to root and filename/usr/filename filesystem mounting and checking/title + para +By default, systemitem +role=packageinitramfs-tools/systemitem is used to mount the +root filesystem during system boot. It will now also run +literalfsck/literal on the root filesystem before mounting it. +If the chosen init program is literalsystemd/literal and there +is a separate filename/usr/filename filesystem, it will also +fsck and mount filename/usr/filename. + /para + itemizedlist +listitem + para + If filename/usr/filename is a separate filesystem on a + RAID device and the literalINITRDSTART/literal setting in + filename/etc/default/mdadm/filename is not + 'literalall/literal', you will need to change it to + include that device. + /para +/listitem +listitem + para + If filename/usr/filename is a separate filesystem on an + LVM logical volume, and the line for filename/usr/filename + in filename/etc/fstab/filename specifies the device by + literalUUID/literal or literalLABEL/literal, you must + change this line to specify the device using the format + filename/dev/mapper/replaceableVG/replaceable-replaceableLV/replaceable/filename + or + filename/dev/replaceableVG/replaceable/replaceableLV/replaceable/filename. + /para +/listitem +listitem + para + It is no longer possible to bind-mount the + filename/usr/filename filesystem. + /para +/listitem +listitem + para + If the RTC (real time clock) is set to local time and the + local time is ahead of UTC, literale2fsck/literal will + print a warning during boot about the time changing backward + (ulink url=https://bugs.debian.org/767040;bug + #767040/ulink). You can disable this by putting the + following lines in filename/etc/e2fsck.conf/filename: + /para + screen +[options] +broken_system_clock=1 +/screen +/listitem + /itemizedlist +/section + section id=lxc-upgrade-issues !-- Wheezy to Jessie -- titleUpgrade considerations for LXC hosts and containers/title signature.asc Description: This is a digitally signed message part
Bug#782898: The 'Boot timing issues (waiting for root device)' section is obsolete
Package: release-notes Severity: normal Tags: patch I believe the issues with root device discovery that could be worked around with 'rootdelay' have been fixed in jessie. It may still be useful to use this parameter if some devices take more than 30 seconds to appear, but this won't be a new issue on upgrade. Ben. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Index: en/upgrading.dbk === --- en/upgrading.dbk (revision 10778) +++ en/upgrading.dbk (working copy) @@ -1237,40 +1237,8 @@ /para /section -section id=boot-timing arch=linux -titleBoot timing issues (waiting for root device)/title -para -If an initrd created with systemitem -role=packageinitramfs-tools/systemitem is used to boot the system, in some -cases the creation of device files by systemitem -role=packageudev/systemitem can happen too late for the boot scripts to -act on. -/para -para -The usual symptoms are that the boot will fail because the root file system -cannot be mounted and you are dropped into a debug shell: -screen -Gave up waiting for root device. Common problems: - - Boot args (cat /proc/cmdline) - - Check rootdelay= (did the system wait long enough?) - - Check root= (did the system wait for the right device?) - - Missing modules (cat /proc/modules; ls /dev) -ALERT! replaceable/dev/something/replaceable does not exist. Dropping to a shell! -(initramfs) -/screen -But if you check afterwards, all devices that are needed are present in -filename/dev/filename. This has been observed in cases where the root file -system is on a acronymUSB/acronym disk or on acronymRAID/acronym, especially if acronymLILO/acronymindextermprimaryLILO/primary/indexterm is used. -/para -para -A workaround for this issue is to use the boot parameter -literalrootdelay=replaceable9/replaceable/literal. The value for the -timeout (in seconds) may need to be adjusted. -/para /section -/section - !-- Review for Stretch -- section id=nownownow titleThings to do before rebooting/title
Bug#782178: Changes to root and /usr filesystem mounting and checking
On Sun, 19 Apr 2015 15:52:34 +0100 Ben Hutchings b...@decadent.org.uk wrote: Control: retitle -1 Changes to root and /usr filesystem mounting and checking Control: tag -1 patch There are several other issues with the initramfs-tools changes that will require manual configuration changes on some systems. I'm expanding this bug to cover all of them, and attaching a patch with my text, closely based on what I already put in the package's NEWS file. Actually this text belongs in the 'Upgrading your kernel and related packages' section. Here's a new patch that puts it there. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. Index: en/upgrading.dbk === --- en/upgrading.dbk (revision 10778) +++ en/upgrading.dbk (working copy) @@ -1237,6 +1237,62 @@ /para /section +section id=initramfs-tools-issues + !-- Wheezy to Jessie -- + titleChanges to root and filename/usr/filename filesystem mounting and checking/title + para +systemitem +role=packageinitramfs-tools/systemitem will now also run +literalfsck/literal on the root filesystem before mounting it. +If the chosen init program is literalsystemd/literal and there +is a separate filename/usr/filename filesystem, it will also +fsck and mount filename/usr/filename. + /para + itemizedlist +listitem + para + If filename/usr/filename is a separate filesystem on a + RAID device and the literalINITRDSTART/literal setting in + filename/etc/default/mdadm/filename is not + 'literalall/literal', you will need to change it to + include that device. + /para +/listitem +listitem + para + If filename/usr/filename is a separate filesystem on an + LVM logical volume, and the line for filename/usr/filename + in filename/etc/fstab/filename specifies the device by + literalUUID/literal or literalLABEL/literal, you must + change this line to specify the device using the format + filename/dev/mapper/replaceableVG/replaceable-replaceableLV/replaceable/filename + or + filename/dev/replaceableVG/replaceable/replaceableLV/replaceable/filename. + /para +/listitem +listitem + para + It is no longer possible to bind-mount the + filename/usr/filename filesystem. + /para +/listitem +listitem + para + If the RTC (real time clock) is set to local time and the + local time is ahead of UTC, literale2fsck/literal will + print a warning during boot about the time changing backward + (ulink url=https://bugs.debian.org/767040;bug + #767040/ulink). You can disable this by putting the + following lines in filename/etc/e2fsck.conf/filename: + /para + screen +[options] +broken_system_clock=1 +/screen +/listitem + /itemizedlist +/section + section id=boot-timing arch=linux titleBoot timing issues (waiting for root device)/title para signature.asc Description: This is a digitally signed message part
Bug#782178: Superblock time check causes problems for fsck in initramfs
On Thu, 2015-04-09 at 08:25 +0200, Niels Thykier wrote: Control: tags -1 moreinfo On Mon, 27 Oct 2014 22:51:53 + Ben Hutchings b...@decadent.org.uk wrote: Package: e2fsprogs Version: 1.42.12-1 Severity: important Tags: upstream [...] e2fsck complains if the superblock write time is in the future, and because the RTC is set to local time on some systems, we are doing the necessary correction of system time in the initramfs. This is undesirable because changing the time zone may now require an initramfs rebuild. You said that this check could be disabled in a configuration file, e2fsck.conf, and we can create that in the initramfs. This works in so far as it suppresses warnings while the initramfs code is running. Unfortunately, every init system currently still checks the root file-system again. If the RTC is set to local time and that is east of UTC, the first fsck sets the write time in the future, and the second fsck warns. Please disable this warning by default. Ben. [...] Hi Ben, You have reassigned this to the release-notes, but it is not entirely clear to me what exactly the solution is. I had a look at [MAN 5 E2FSCK.CONF] and my best guess was you wanted us to recommend people to set accept_time_fudge. Though it defaults to being true. Sorry, I probably should have opened a new bug report for this. The configuration needed to avoid the warning is: [options] broken_system_clock=1 Ben. ~Niels [MAN 5 E2FSCK.CONF]: http://linux.die.net/man/5/e2fsck.conf -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett signature.asc Description: This is a digitally signed message part
Bug#780571: release-notes: Review from the kernel team
On Mon, 2015-03-16 at 08:35 +0100, Niels Thykier wrote: Package: release-notes Severity: normal Dear kernel team, I am contacting you to do a final review of the release-notes for the kernel related topics (as listed on [1]) The only items I am currently aware of is: * https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#required-kernel-config-options Which mentions (executive summary): # Required for udev CONFIG_DEVTMPFS=y # Required for *some* systemd services CONFIG_DEVPTS_MULTIPLE_INSTANCES=y If you have any additional items or would like to provide more information to the existing ones, please let me know. Please include or link to systemd kernel requirements at http://sources.debian.net/src/systemd/215-12/README/#L39. CONFIG_BT is required by bluez and hence for gnome, although I don't know whether that's new. CONFIG_PPDEV is apparently required by cups under systemd, if only to avoid error messages. Ben. -- Ben Hutchings All extremists should be taken out and shot. signature.asc Description: This is a digitally signed message part
Bug#705814: Incorrect firmware prompt for Intel Wireless 6005/6205
Package: release-notes Severity: normal Bug #705655 will not be fixed in time for r0. The release notes should say that: If you have an Intel Wireless 6005 or 6205 card then the installer will prompt for the firmware file iwlwifi-6000g2a-6.ucode. This file is not included in the firmware-iwlwifi package and is not actually needed. You must answer 'no' to continue with installation. Ben. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420140016.23555.89086.report...@deadeye.wl.decadent.org.uk
Bug#612317: No RN info about Btrfs
On Sat, 2013-03-30 at 14:48 -0400, David Prévot wrote: Control: tags -1 moreinfo Hi, On Tue, Feb 08, 2011 at 01:26:01AM +0800, Aron Xu wrote: On Tue, Feb 8, 2011 at 01:09, Matteo Cortese matteo_cort...@fastwebnet.it wrote: It is still not clear to me whether the installer recognizes and creates Btrfs partitions. If it does, it should be added to the release notes and installation manual; I am sure the installation process is okay with btrfs, the only thing need to note is when you choose btrfs as /, then you have to have a separated /boot (with filesystem format like ext3) because grub2 does not support btrfs still. The installer will refuse to continue if you don't make a separated /boot with acceptable format. There is currently nothing about Btrfs in the release notes, and I wonder if there it any need to add something about it. If someone disagrees, please, do provide at least a rough patch to move things forward. Otherwise, I would suspect this issue isn’t relevant for Wheezy and advise the RN wizard to close it (I may do so myself next time I come across this bug report unless more information is provided). The release notes should say that btrfs is still a tech preview. It is not ready for production in Linux 3.2 and this will not be fixed in time for release. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Re: Bug#697029: [ilk] using GNOME 3 makes computer sluggish after a few minutes
On Sat, 2013-02-23 at 12:05 -0800, Jonathan Nieder wrote:
found 697029 linux/3.7.3-1~experimental.1
tags 697029 - wontfix
affects 697029 + release-notes
quit
Hi,
Chris Wilson wrote:
The performance issue on 3.7 is not due to the missed irq, but a
combination of using UXA and VT-d. In order to workaround an erratum
on Ironlake, every time we touch the GPU's page tables, we have to
idle the GPU before doing so. This causes extremely noticeable display
lag.
For reference, the workaround seems to be implemented by:
commit 6fbcfb3e467adb414e235eeefaeaf51ad12f2461
Author: David Woodhouse dw...@infradead.org
Date: Sun Sep 25 19:11:14 2011 -0700
intel-iommu: Workaround IOTLB hang on Ironlake GPU
commit 5c0422878fcdc279ae9a8e8b66972a15b5efb67f
Author: Ben Widawsky b...@bwidawsk.net
Date: Mon Oct 17 15:51:55 2011 -0700
drm/i915: ILK + VT-d workaround
However the latter is applied only to Ironlake M (mobile). So either
there are two different bugs or there is some confusion about which
chips have the bug.
Pierre AUSSAGUEL wrote:
Appending intel_iommu=off seems to fix the problem (I tested a few
days befor posting).
Daniel Vetter wrote:
Since we can't fix the hw, closing this as wontfix. Thanks for
reporting this issue anyway.
That makes this a distro issue, I suppose.
Ben and X team, any ideas? Would it makes sense to disable
intel_iommu by default on this hardware and require intel_iommu=on to
reenable it?
Use of an IOMMU is in part a performance vs security trade-off. I tend
to think that security settings should have consistent defaults, as
otherwise users may assume that a security feature is enabled when it is
not.
Aside from that, the Intel IOMMU can be enabled separately per device
(except behind PCI bridges). Since IGPs aren't real PCI(e) devices and
Intel has not always validated their interaction with the IOMMU, they
often don't work with it. There is already a kernel parameter to
disable it for the IGP ('intel_iommu=igfx_off') and a quirk to do so
automatically for the G4x and GM45. Maybe the thing to do is to log a
message about this parameter when enabling the workaround for Ironlake.
Should GNOME somehow detect that it should use classic
mode by default when the iommu is enabled?
I think this would be a very poor heuristic.
If we can't come up with a workaround, this should be mentioned in the
release notes to prevent a regression on upgrade. Please feel free to
remind me in that case so I can come up with some wording (though I
also wouldn't mind if someone else does).
Graphics rendering may be very slow on Intel 'Ironlake M' GPUs (PCI ID
8086:0046) when an IOMMU (VT-d) is enabled. The IOMMU functionality can
be disabled for the GPU by adding the kernel parameter
'intel_iommu=igfx_off'.
(The identification of which devices are affected may need to be
revised.)
Ben.
--
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
signature.asc
Description: This is a digitally signed message part
Bug#666186: i386 Linux kernel flavour change in wheezy
Package: release-notes Tags: wheezy There should be a note for people upgrading an i386 squeeze system to wheezy about the change of kernel flavours. Suggested text: Debian's '686' kernel configuration has been replaced by the '686-pae' configuration, which uses PAE (Physical Address Extension). If your computer is currently running the '686' configuration but does not have PAE, you will need to switch to the '486' configuration instead. You can check whether your computer has PAE by running: grep -q '^flags.*\bpae\b' /proc/cpuinfo echo yes || echo no If it does not, you should install linux-image-486 and then remove linux-image-686 and/or linux-image-2.6-686 if they are currently installed. This is not relevant for installation since the flavour selection is done automatically based on processor flags. This should be done after configuring the wheezy sources and before upgrading anything else. Upgrading linux-image-686 or linux-image-2.6-686 on a non-PAE system will fail with an explanation similar to the above (only unconditional). Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#609330: release-notes: update-grub seems not to be called by the kernel upon upgrade
On Sat, 2011-01-08 at 22:23 +0100, Bastian Blank wrote: On Sat, Jan 08, 2011 at 06:05:02PM +, Ben Hutchings wrote: On Sat, 2011-01-08 at 18:38 +0100, Julien Cristau wrote: waldi says the kernel should break pre-policy versions of bootloader packages, and apparently grub was missed. It wasn't. update-grub has never been called explicitly from the linux-image maintainer scripts. Instead, debian-installer used to set postinst_hook and postrm_hook in /etc/kernel-img.conf if the user chose to install GRUB. It is broken. Someone have to fix it up. Please show how. Backport grub2 r2157 and grub-legacy r811 (and subsequent fixups) to lenny. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#599208: release-notes: drop kernel-package info?
On Tue, 2010-10-05 at 18:29 +0200, Julien Cristau wrote: Package: release-notes Severity: minor Tags: squeeze The kernel-metapackage section of the release notes includes this text: para For the more adventurous there is an easy way to compile your own custom kernel on debian;. Install the systemitem role=packagekernel-package/systemitem tool and read the documentation in filename/usr/share/doc/kernel-package/filename. /para AFAIK kernel-package is mostly deprecated these days in favour of the upstream 'make deb-pkg' target. Maybe this should be dropped or updated? (cc:ed to debian-kernel) Yes, I would suggest something like: para For the more adventurous there is an easy way to compile your own custom kernel on debian;. The kernel source is included in the systemitem role=packagelinux-source-2.6/systemitem package and the kernel makefile provides the target 'deb-pkg' for building a binary package. /para Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#568126: lm-sensors: Resource conflicts policy in kernel has changed
On Thu, 2010-08-05 at 17:30 +0200, Didier 'OdyX' Raboud wrote: Le lundi 2 août 2010 00:27:10, vous avez écrit : On Fri, Feb 05, 2010 at 11:58:36AM -0500, Dave Witbrodt wrote: [...] I recently resolved a very similar issue myself by adding acpi_enforce_resources=lax to my kernel boot line in GRUB. Didier, does this fix the issue for you? Cheers, Moritz Hi Moritz, yes it does. But if this option is to stay, it really should get either i) set automagically by insert smart package name here No, that's dangerous, which is why it's not the default. ii) documented visibly in release notes maybe ? [...] I don't think this is a very common problem, but if you think so then reassign this to release-notes. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#575761: x86 architecture names are confusing
On Mon, Apr 19, 2010 at 06:34:22PM +0200, Goswin von Brederlow wrote: Ben Hutchings b...@decadent.org.uk writes: Package: release-notes Severity: normal Tags: squeeze lenny The release notes use the long architecture names 'AMD64' and 'Intel x86' for our architectures 'amd64' and 'i386'. The name 'AMD64' sometimes confuses users with Intel x86-64 chips, who instead download the installer or CD images for ia64. This is a waste of time and bandwidth for all concerned. The name 'Intel x86' is also inaccurate in that the i386 architecture runs on 32-bit x86 processors from many vendors. The long names should be changed in coordination with www.debian.org (#575760). Changed to what? In #575760 I suggested '32-bit PC' and '64-bit PC'. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100419172632.gi16...@decadent.org.uk
Bug#575761: Bug#575760: x86 architecture names are confusing
On Mon, 2010-03-29 at 21:27 +0200, Simon Paillard wrote: Hi, [CC the other Bug# against release-notes] On Mon, Mar 29, 2010 at 02:52:55AM +0100, Ben Hutchings wrote: Package: www.debian.org Severity: normal Various pages use the long architecture names 'AMD64' and 'Intel x86' for our architectures 'amd64' and 'i386'. The name 'AMD64' sometimes confuses users with Intel x86-64 chips, who instead download the installer or CD images for ia64. This is a waste of time and bandwidth for all concerned. The name 'Intel x86' is also inaccurate in that the i386 architecture runs on 32-bit x86 processors from many vendors. I recommend the names '32-bit PC' and '64-bit PC' - they are not pedantically correct, but people should understand what they mean. Or: 32-bit PC (i386) | 64-bit PC (amd64) (in order to keep in mind the official name in the archive). I fully agree. We received many reports/doubts of users on debian-www. For the record, the subject has been discussed in November: http://lists.debian.org/debian-www/2009/11/threads.html#5 FJP position: http://lists.debian.org/debian-boot/2009/11/msg00515.html The point of FJP is however to keep consistency between displayed names and architecture name. His major point seems to be that the current layout sucks, which I fully agree with. I would suggest using lists or tables with one line per architecture, sorted in reverse order of popularity (according to popcon). It may be relevant to change amd64 to something else, but may need much larger changes in Debian.. [...] The official short names really cannot be changed. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#575761: x86 architecture names are confusing
Package: release-notes Severity: normal Tags: squeeze lenny The release notes use the long architecture names 'AMD64' and 'Intel x86' for our architectures 'amd64' and 'i386'. The name 'AMD64' sometimes confuses users with Intel x86-64 chips, who instead download the installer or CD images for ia64. This is a waste of time and bandwidth for all concerned. The name 'Intel x86' is also inaccurate in that the i386 architecture runs on 32-bit x86 processors from many vendors. The long names should be changed in coordination with www.debian.org (#575760). Ben. -- System Information: Debian Release: squeeze/sid APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-doc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329015930.26162.36686.report...@localhost
