Re: Offer to make a native 32-bit system avaiable
Thank you for the offer, but no need. It is not needed in Debian infrastructure. On Sat, 13 Jan 2024, 19:18 rhys, wrote: > > > >> I know the difference between a 32-bit processor and a 64-bit processor. > > > > Obviously you don't. Or at least are not aware about consequences. > > > > > > Since you still offer 32bit machines of which Debian has enough of. (64 > bit kernel probably but it doesn't matter) where it does not matter at all. > > Then let me be clearer. > > I should have changed the subject line, because I was not attempting to > address the build problems brought up in the original topic. I have done > so now. > > Let me say that again another way: I was changing the subject of the > conversation away from the build issues mentioned previously. > > I did not mean that offering additional resources would solve known build > problems. > > What I mean was, "Here is a resource that appears to be scarce from my > perspective. You may use it if you wish." > > > You ignore the stated fact in this thread that on a 32bit processor one > process can't get more than 3GB or even less of RAM (regardless of what > memory extension stuff exists). > > Correct. Because that's not relevant to the point I was trying to make. > Please see above. > > > Putting more "32bit machines" on it do not change anything of that > except that there were more machines which cannot build big stuff. > > Correct. > > I have and use 32-bit systems. I would like to keep using Debian on those > systems. My intention was to offer a resource that could, potentially, > help ensure that 32-bit systems continue to be supported. In this way, I > am offering to contribute something back to the project that has served me > well for years. > > If that is not useful, that's fine. It's certainly less work for me. It > was just an offer. > > That is all. > > --J >
Re: Ability to further support 32bit architectures
Heya, On Fri, 12 Jan 2024, 22:36 Bastian Blank, wrote: > On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote: > > Disabling debug symbols, enabling debug symbol zstd compression, using > > split debug symbols (disabled BTF usage) should help here. > > Disabling debug symbols does not help. > This now smells a lot more like an actual bug in either kernel source code, or compiler, or both. Rather than natural growth and actually needing that much memory. Probably worth escalating. > Bastian > > > Sent from Ubuntu Pro > > https://ubuntu.com/pro > > Just curious why you send ads? > Felt cute, might remove later. > -- > Immortality consists largely of boredom. > -- Zefrem Cochrane, "Metamorphosis", stardate 3219.8 > >
Re: Ability to further support 32bit architectures
Hi, On Thu, 11 Jan 2024 at 09:42, Bastian Blank wrote: > > Hi > > Linux 6.7 fails to build on at least i386 and armhf. Even it now > manages to make the compiler fail to allocate memory: > | cc1: out of memory allocating 135266296 bytes after a total of 235675648 > bytes > > Right now both fail on the same driver, so a short team workaround would > be to disable it. But we need a long term fix, and quickly. > > As it is now, we will not be able to provide a kernel for maybe all > 32bit architectures for Trixie. > > Bastian > Disabling debug symbols, enabling debug symbol zstd compression, using split debug symbols (disabled BTF usage) should help here. Separately, I wish we had cross-builders available, and cross-build i386/armhf kernels from amd64/arm64 and thus having access to 64-bit compiler. I am experiencing the same issue with the armhf kernels on my infrastructure. -- Dimitri Sent from Ubuntu Pro https://ubuntu.com/pro
Re: Future for armel? (was: Re: What to do with d-i on armel?)
On Wed, 10 Jan 2024 at 09:46, Martin wrote: > > Quoting Bastian Blank : > > But why? What is provided by an armel userland that armhf can't? > > My employer runs Debian on this armv5(?) hardware: > > https://www.taskit.de/produkte/embedded-produkte/computer-on-module/132/stamp9g20-512f/128r > > Sure, the kernel is not the Debian one, but something around 4.19. Such deployment only needs Debian archive, without a need for a debian kernel nor debian d-i build for said arch. A sort of partial / rootfs chroot-only arch. -- Dimitri Sent from Ubuntu Pro https://ubuntu.com/pro
Re: How to revoke Debian kernels for secure boot
At the moment the best options are: - rotate online signing key - build new shim with old signing key in vendorx (revoked ESL) - build new kernels with old signing key built-in revoked keyring This is to ensure that old shim & old kernel can boot or kexec new kernels. To ensure new shim cannot boot old kernels. To ensure that new kernels cannot kexec old kernels. This is revocation strategy used by Canonical Kernel Team for Ubuntu Kernels. There is no sbat for kernels yet (and/or nobody has yet started to use sbat for kernels). On Wed, 13 Dec 2023, 22:04 Bastian Blank, wrote: > Hi > > I don't think we currently have a documented way to revoke old kernels > for secure boot. Are there known plans by other distributions? Or > should we just force the inclusion of SBAT and use it as intended? > > Regards, > Bastian > > -- > ... The prejudices people feel about each other disappear when they get > to know each other. > -- Kirk, "Elaan of Troyius", stardate 4372.5 > >
Re: consolidate linux-libc-dev headers
On Thu, 16 Nov 2023 at 19:30, Bastian Blank wrote: > > Hi Dimitri > > On Thu, Nov 16, 2023 at 06:28:13PM +0000, Dimitri John Ledkov wrote: > > I have implemented example packaging of that as a standalone source package > > https://ppa.launchpadcontent.net/xnox/nonvirt/ubuntu/pool/main/l/linux-uapi/ > > I actually just implemented something similar, but as part of the Debian > linux packaging. It looks a bit different, sure. Actually I cannot find this anywhere yet - is this something you only have locally so far, or has it been pushed anywhere in a git repo, pull request or anything? > > > Is this something that the debian kernel team could consider supporting / > > building as either standalone source package, or out of src:linux directly? > > My first thought was actually to make bootstrapping of new architectures > easier. > > > The obvious things missing from the packaging is to create all the > > breaks/replaces/provides, and update cross-toolchain-base packages to > > match. Also probably using symlinks rather than hard links, with > > linux-libc-dev-cross likely depending on the native one. > > What do you want to do with linux-libc-dev-cross? /usr/$triplet is no > allowed location in Debian anyway. > > > Separately for Ubuntu, due to the number of kernel built, I would likely > > want to upload source package that produces linux-libc-dev as a separate > > source package such that linux-libc-dev is actually only updated when > > needed, rather than on every kernel upload. As there is no need to rev > > linux-libc-dev as often as kernel uploads are done. > > The question here is: does it provide an advantage to have it as > separate source? Less updates IMHO do not count, as they don't come > with a penalty attached. But I see the downside of fixing the user > space API to a different version then the kernel you actually ship in > the end. > > Regards, > Bastian > > -- > Knowledge, sir, should be free to all! > -- Harry Mudd, "I, Mudd", stardate 4513.3 > -- okurrr, Dimitri
Re: consolidate linux-libc-dev headers
On Thu, 16 Nov 2023 at 19:30, Bastian Blank wrote: > > Hi Dimitri > > On Thu, Nov 16, 2023 at 06:28:13PM +0000, Dimitri John Ledkov wrote: > > I have implemented example packaging of that as a standalone source package > > https://ppa.launchpadcontent.net/xnox/nonvirt/ubuntu/pool/main/l/linux-uapi/ > > I actually just implemented something similar, but as part of the Debian > linux packaging. It looks a bit different, sure. > Will check it out, thanks! And yes, indeed there are dozens of ways to implement this idea. > > Is this something that the debian kernel team could consider supporting / > > building as either standalone source package, or out of src:linux directly? > > My first thought was actually to make bootstrapping of new architectures > easier. > Indeed that too. But I was told "arm64" would the last one, and then "riscv64" is really the last one. Not sure if c-sky or riscv128 or arm64be will be next. > > The obvious things missing from the packaging is to create all the > > breaks/replaces/provides, and update cross-toolchain-base packages to > > match. Also probably using symlinks rather than hard links, with > > linux-libc-dev-cross likely depending on the native one. > > What do you want to do with linux-libc-dev-cross? /usr/$triplet is no > allowed location in Debian anyway. I'm not sure about if it is allowed or not, but it is the only possible way to ship cross toolchains like in all releases since 2015 - https://tracker.debian.org/news/685686/accepted-cross-toolchain-base-2-source-all-into-unstable-unstable/ I think we (all the toolchainy people in debian & ubuntu, which is like doko xnox helmut and whoever else) agreed to do it this way back in Debconf in Swiss alps by the lake?! or like cambridge mini-debconf?! It's ok if you don't want to integrate `linux-libc-dev-cross` into src:linux I can upload that into debian as a standalone src:linux-libc-dev-cross under the toolchain-base maintainers hat that will build-depend on linux-source and build it for all possible triplets under the sun. And i think we override the lintian warnings there. Because it will be easier to have that once, rather than in all three cross-toolchain-base packages. And it can be updated, without rebuilding the cross-toolchains themselves. Because it is wasteful to acutally do cross toolchains bootstraps just to bump a stable point release of linux headers that like changes nothing. Or just integrate it into src:linux build too, given all of those cross headers are established packages since 2015. (and yes using GNU tripplet as a top level dir) > > > Separately for Ubuntu, due to the number of kernel built, I would likely > > want to upload source package that produces linux-libc-dev as a separate > > source package such that linux-libc-dev is actually only updated when > > needed, rather than on every kernel upload. As there is no need to rev > > linux-libc-dev as often as kernel uploads are done. > > The question here is: does it provide an advantage to have it as > separate source? Less updates IMHO do not count, as they don't come > with a penalty attached. But I see the downside of fixing the user > space API to a different version then the kernel you actually ship in > the end. > Fixing to a different (or sooner) API before kernels actually are ready is one angle that helps Ubuntu. Separately in Ubuntu we have like 16+ custom/customer kernels (i.e. src:linux-acme) and they all keep trying to filter ubuntu repos and build what they need and get confused when they need to build generic kernel and their custom kernel, and constantly try to build linux-libc-dev & linux-source out of their custom kernel and that has conflicts and API level missmatched (in cases when custom kernel is ahead or behind the given Ubuntu's release "baseline" API). Hence for me it will be easier in Ubuntu-only to maintain src:linux that only build generic kernel flavour; and src:linux-uapi builds "stable API" headers and toolchainy things. And it will simplify filtered archives / installs too, of having src:linux-$customer + src:linux-uapi to cover their needs. Speed & frequency of updates matters too, as linux-libc-dev forms part of the toolchain / buildinfo, and for cases were reproducible builds matter, having less churn of linux-libc-dev helps a lot with having stable toolchain version numbers. Also headers change a lot slower, than underlying kernel. But that's a very niche thing (matters for minimising reproducible rebuilds, buildd chroot refreshes, containers that are used as buildds and the like). -- okurrr, Dimitri
consolidate linux-libc-dev headers
Currently in both Debian and Ubuntu we ship like close to 40 .deb packages that have linux-libc-dev (for native/multiarch, cross, ports, mipses). Each one of them is like 1.5MB, however they actually all have the same and repeated content. the bulk of headers are the same on all arches (and enforced via multi-arch:same), asm-generic is also the same for all of them, and then kernel-arch asm headers are unique - but only for given kernel arches (not all of the debian arch names). Currently there are only 13 kernel archs for unique asm-arch headers, but in Debian we have multiple reuses of the same kernel archs with different userspace abi properties (arm = armel armhf, mips = 12 mips archs, powerpc = 4, x86 = 3, and so on). It seems wasteful on disk, build-time, and derivative build time to package all of these separately. Especially since there is a chain of src:linux building native ones + linux-source as a .deb; which is then used by cross-toolchain-base{,-ports,-mips} to unpack and rebuild linux headers again, and publish. When in practice src:linux itself could build an efficient libc-dev packages for all arches as an arch:all package and Multi-Arch:foreign. I have implemented example packaging of that as a standalone source package https://ppa.launchpadcontent.net/xnox/nonvirt/ubuntu/pool/main/l/linux-uapi/ The linux-libc-dev is native & multiarch uapi headers for all arches. The linux-libc-dev-alpha-cross is all debian arch crosses. It is implemented using hardlinks to maintain all the same paths that are currently being used by all the arch:any linux-libc-dev packages, and the linux-libc-dev-*-cross packages. In total they provide equivalent functionality as 40+ linux-libc-dev* current debs in either Debian or Ubuntu. Is this something that the debian kernel team could consider supporting / building as either standalone source package, or out of src:linux directly? as this would reduce 40+ .deb duplication in the mirror pools of the same content; and will eliminate build-depends on linux-source (and thus built-using) from src:cross-toolchain-base* and will actually ensure that all kernel headers for native / multiarch / cross arches are updated simultaneously, without need to wait for all arch:any builds to catch up first. It also gives ability to trivially create freestanding toolchains to any of the arches without actually building a full debian port for or having a working kernel for a given port. The obvious things missing from the packaging is to create all the breaks/replaces/provides, and update cross-toolchain-base packages to match. Also probably using symlinks rather than hard links, with linux-libc-dev-cross likely depending on the native one. Separately for Ubuntu, due to the number of kernel built, I would likely want to upload source package that produces linux-libc-dev as a separate source package such that linux-libc-dev is actually only updated when needed, rather than on every kernel upload. As there is no need to rev linux-libc-dev as often as kernel uploads are done. But I do hope to see if this approach for linux-libc-dev can be coordinated to ensure compatible cross-toolchain-base changes. -- okurrr, Dimitri
Bug#930366: initramfs-tools: unmkinitramfs fails to unpack lz4 compressed initrd
Package: initramfs-tools Version: 0.133 Severity: normal Tags: patch Dear Maintainer, unmkinitramfs fails to unpack lz4 compressed initrd, ie.: $ sudo apt install initramfs-tools lz4 file $ mkinitramfs -c lz4 -o foo.img $ unmkinitramfs foo.img bar cpio: premature end of archive $ echo $? 2 I think this is because lz4cat is strict with file extensions: $ file foo.img foo.img: LZ4 compressed data (v0.1-v0.9) $ lz4cat -t foo.img File extension doesn't match expected LZ4_EXTENSION (.lz4); will not process file: foo.img I propose the attached patch to change 'lz4cat -t $archive' invocations to become 'lz4cat -t <$archive' instead. As lz4cat does not / cannot enforce extension checking on streams. Regards, Dimitri. diff -Nru initramfs-tools-0.133ubuntu6/unmkinitramfs initramfs-tools-0.133ubuntu8/unmkinitramfs --- initramfs-tools-0.133ubuntu6/unmkinitramfs 2019-06-07 19:22:58.0 + +++ initramfs-tools-0.133ubuntu8/unmkinitramfs 2019-06-09 23:21:17.0 + @@ -33,8 +33,8 @@ gzip -c -d "$archive" elif xzcat -t "$archive" >/dev/null 2>&1 ; then xzcat "$archive" - elif lz4cat -t "$archive" >/dev/null 2>&1 ; then - lz4cat "$archive" + elif lz4cat -t <"$archive" >/dev/null 2>&1 ; then + lz4cat <"$archive" elif bzip2 -t "$archive" >/dev/null 2>&1 ; then bzip2 -c -d "$archive" elif lzop -t "$archive" >/dev/null 2>&1 ; then
Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4
On 6 April 2016 at 00:32, Ben Hutchings wrote: > On Wed, 2016-04-06 at 00:22 +0100, Ben Hutchings wrote: > [...] >> But I also found this commit in 3.17: >> >> commit f79a901331a823ae370584b15cd39dd110b95a0a >> Author: Hans de Goede >> Date: Fri Jul 18 12:21:47 2014 +0200 >> >> ideapad-laptop: Disable touchpad interface on Yoga models >> >> Although it says 'disable touchpad interface', what it means is the >> ideapad-laptop driver will ignore firmware events sayigng the touchpad >> should be turned on or off (maybe based on rotation sensors in other >> Ideapad models?). It started handling those events in 3.6, which fits >> the earlier report. >> >> Have either of you tried a kernel version newer than 3.16? > > Sorry, that won't help - this commit was reverted as the feature was > previously working properly for some Yoga models. > > Dmitri, can you test whether that cherry-picking that commit fixes this > for you? I can try that yes. So yoga 13 non-pro, has a few things - normal touchpad which with up to date kernels doesn't come up on boot, until psmouse is reloaded - touchscreen which appears as a tablet input interface or some such - and magic key-codes Magic key-codes, send a key code every 2s or some such to indicate laptop unfold angle, such that when it's beyond 180 open the keycodes spam stops and thus OS should turn off keyboard and touchpad because it's now in "tablet" mode. It folds all the way out. Stuff has changed in yoga 13 pro models, cause things did stop working on non-pro after pro-specific model/quick/modules things were merged. But i believe pro revision did things differently. -- Regards, Dimitri.
Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4
On 5 April 2016 at 22:49, Ben Hutchings wrote: > Control: reassign -1 src:linux 3.16.7-ckt25-1 > Control: tag -1 moreinfo > > On Mon, 2016-04-04 at 22:11 +0300, Juho wrote: >> Package: general >> Severity: important >> >> After running "apt-get update && apt-get dist-upgrade" on 2016-04-03 >> touchpad of IdeaPad Yoga 13 stopped working. Both touch plate and >> buttons are not working. >> This laptop also has a touch screen and it is still working without >> problems. >> I'm not sure which package included this 8.4 update might be the faulty >> one. > [...] > > Most likely the kernel. However, I can't see any obviously relevant > changes. What does this command show: > > ls -l /sys/class/input/mouse*/device/device/driver I have such a Yoga, for me it's the older yoga-13, pre-highdpi pro version. $ sudo modprobe -r psmouse $ sudo modprobe psmouse Makes it "work" again. I have no idea what happens during the boot, or how come post-boot psmouse module loading results in working behaviour. Possibly something is racy in the kernel and initializes differently "post-boot". It broke around 3.13 following upstream kernels for me or some such. And bisecting this using master/vanilla/.0 kernels ended up being fruitless, at least for me. So i'm reloading psmouse on my IdeaPad -- Regards, Dimitri.
Bug#804446: initramfs-tools: Do not include fsck tools for non-fscable filesystems
Package: initramfs-tools Version: 0.120 Severity: normal Tags: +patch Dear Maintainer, Currently partman-xfs|btrfs sets passnum to 1/2 for xfs/btrfs filesystems, then initramfs-tools includes fsck tools for these, which then xfs/btrfs utility packages ship, which are no-op shell scripts that do nothing and are executed on each boot. Imho, this is a bit silly. I would like to drop the dummy wrapper script from btrfs package to achieve that I am proposing the following: * fix partman-xfs|btrfs to set passnum to 0 unconditionally (done) * fix initramfs-tools fsck hook to ignore passno 0 fstab entries when calculation which fsck tools to include in the initramfs. (this bug) * make sure repair/recovery tools are included in the initramfs via filesystem specific initramfs-tools hooks (ie. xfs_repair / btrfs check) * and finally migrate people to 0 pass number in the /etc/fstab for said filesystems. Please consider applying and uploading this patch into Debian unstable. Regards, Dimitri. From 811c1005d2caf8e395e22a16ea202cb230999a3d Mon Sep 17 00:00:00 2001 From: Dimitri John Ledkov Date: Sun, 8 Nov 2015 16:01:01 + Subject: [PATCH] Do no include fsck, for filesystems that are non-fsckable (passno 0) Organization: Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ btrfs and xfs are examples of filesystems that do not have an fsck. Or well, they do have repair/restore utilities, but they are not fsck(8) compatible nor required to be run periodically on boot. Both packages currently ship fsck(8) compatible scripts, which do nothing. That's not useful at all. partman-xfs & partman-btrfs have been just fixed to set passno in fstab to 0 on new installations, as indeed it makes no sense to run no-op scripts for those filesystems. This patch makes fsck hook to be passno aware, and if it is set to zero, to decide not to include an fsck script for requested filesystem. It is expected that repair/recovery utilities for passno == 0 filesystems are included in the initramfs, via filesystem in question specific initramfs-hooks (e.g. xfs_repair and `btrfs check') Signed-off-by: Dimitri John Ledkov --- hooks/fsck | 7 +++ 1 file changed, 7 insertions(+) diff --git a/hooks/fsck b/hooks/fsck index 6c90996..44292b9 100755 --- a/hooks/fsck +++ b/hooks/fsck @@ -23,6 +23,7 @@ _read_fstab_entry () { echo "MNT_FSNAME=" echo "MNT_DIR=" echo "MNT_TYPE=" + echo "MNT_PASS=" fstab_files | while read file; do if [ -f "$file" ]; then @@ -39,6 +40,7 @@ _read_fstab_entry () { echo "MNT_FSNAME=$MNT_FSNAME" echo "MNT_DIR=$MNT_DIR" echo "MNT_TYPE=$MNT_TYPE" + echo "MNT_PASS=$MNT_PASS" break 2 fi MNT_DIR="" @@ -52,6 +54,11 @@ _read_fstab_entry () { get_fstype_fstab () { eval "$(_read_fstab_entry "$1")" + # Do not include fsck for non-fsckable filesystems + if [ "$MNT_PASS" = "0" ]; then + return + fi + # Not found by default. if [ "$1" = "$MNT_DIR" ]; then case "$MNT_TYPE" in -- 2.5.0
Bug#797361: initramfs-tools: hooks/fsck includes too many tools
Package: initramfs-tools Severity: normal Version: 0.120 Tags: patch Hello, Initramfs tools hooks/fsck includes fsck utils for / and /usr, but it doesn't take `pass' field into account, specifically when it's not set or set to 0 (as per fstab(5) fsck should not be run against those filesystems. Specifically one would set that to zero for filesystems that don't require fsck to be run, like btrfs and xfs. See attached proposed patch. >From 3ebe2c4c3c7df2fddb2e15b438363e8f95d80962 Mon Sep 17 00:00:00 2001 From: Dimitri John Ledkov Date: Sat, 29 Aug 2015 23:59:07 +0100 Subject: [PATCH] Do not include fsck tools for fstab entries with empty or 0 pass field. Those fstab entries request not to have fsck run against them, e.g. btrfs & xfs. --- hooks/fsck | 5 + 1 file changed, 5 insertions(+) diff --git a/hooks/fsck b/hooks/fsck index 6c90996..4483e3b 100755 --- a/hooks/fsck +++ b/hooks/fsck @@ -27,6 +27,11 @@ _read_fstab_entry () { fstab_files | while read file; do if [ -f "$file" ]; then while read MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK; do +case "$MNT_PASS" in + ""|"0") + continue; + ;; +esac case "$MNT_FSNAME" in ""|\#*) continue; -- 2.5.0 Regards, Dimitri.
Bug#784234: initramfs-tools: searches for fsck.btrfs in the wrong directory
On 4 May 2015 at 19:25, Ben Hutchings wrote: > On Mon, 2015-05-04 at 18:20 +0100, Dimitri John Ledkov wrote: >> Thanks for this. >> >> >> I will check the previous /sbin/ binaries and move them back to sbin >> location. >> >> >> There was a change of build system upstream as well, and I thought i >> got the splits right. >> >> >> Thanks for pointing this out. > > If fsck can find fsck.$fstype anywhere in $PATH then mkinitramfs should > do so too. But it would be helpful for you to move it back until we fix > mkinitramfs. Thanks. Step 1 is to at least copy any in the first place the hooks were copying /sbin/, whilst binaries moved to /bin/ =) I should be testing root on btrfs before uploading... -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUiX=1ct_18-wfjaf_cqoq+lwgx4hvdg3y8ftgrj7vw...@mail.gmail.com
Bug#784234: initramfs-tools: searches for fsck.btrfs in the wrong directory
Thanks for this. I will check the previous /sbin/ binaries and move them back to sbin location. There was a change of build system upstream as well, and I thought i got the splits right. Thanks for pointing this out. On 4 May 2015 at 11:42, Norbert Preining wrote: > Package: initramfs-tools > Version: 0.120 > Severity: important > > With the update of btrfs-tools to 4.0-1 I get this: > update-initramfs: Generating /boot/initrd.img-4.1.0-rc2 > Warning: /sbin/fsck.btrfs doesn't exist, can't install to initramfs, > ignoring. > and indeed, the changelog states > > btrfs-tools (4.0-1) unstable; urgency=medium > > * Move all binaries to /bin (Closes: #770806) > > and there it is > -rwxr-xr-x 1 root root 1177 May 4 07:28 /bin/fsck.btrfs > > I don't know who should fix that, though. > > All the best > > Norbert > > -- Package-specific info: > -- initramfs sizes > -rw-r--r-- 1 root root 4.7M Apr 14 14:22 /boot/initrd.img-3.17.0 > -rw-r--r-- 1 root root 4.7M Apr 14 14:22 /boot/initrd.img-3.18.0 > -rw-r--r-- 1 root root 4.9M Apr 14 14:22 /boot/initrd.img-3.19.0 > -rw-r--r-- 1 root root 4.9M Apr 14 14:22 /boot/initrd.img-4.0.0 > -rw-r--r-- 1 root root 4.9M Apr 14 14:22 /boot/initrd.img-4.0.0-rc6+ > -rw-r--r-- 1 root root 4.9M Apr 14 14:22 /boot/initrd.img-4.0.0-rc7 > -rw-r--r-- 1 root root 4.9M Apr 18 11:36 /boot/initrd.img-4.0.0-rc7+ > -rw-r--r-- 1 root root 3.8M May 4 19:28 /boot/initrd.img-4.1.0-rc2 > -- /proc/cmdline > BOOT_IMAGE=/boot/vmlinuz-4.1.0-rc2 root=/dev/sda7 ro libata.force=noncq > > -- /proc/filesystems > ext3 > ext2 > vfat > iso9660 > ntfs > fuseblk > btrfs > > -- lsmod > Module Size Used by > ctr 3503 2 > ccm 6946 2 > acpi_call 4055 0 > binfmt_misc 6006 1 > nfsd 199194 2 > auth_rpcgss36500 1 nfsd > oid_registry2099 1 auth_rpcgss > nfs_acl 2063 1 nfsd > nfs 105211 0 > lockd 53114 2 nfs,nfsd > grace 1506 2 nfsd,lockd > sunrpc152397 6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl > x86_pkg_temp_thermal 4315 0 > intel_powerclamp8146 0 > kvm_intel 127847 0 > kvm 250993 1 kvm_intel > crc32c_intel 12785 0 > aesni_intel 158005 4 > aes_x86_64 7295 1 aesni_intel > iwlmvm202743 0 > mac80211 331322 1 iwlmvm > lrw 3255 1 aesni_intel > gf128mul5479 1 lrw > glue_helper 3782 1 aesni_intel > ablk_helper 1612 1 aesni_intel > joydev 8259 0 > cryptd 7151 2 aesni_intel,ablk_helper > iwlwifi80313 1 iwlmvm > cfg80211 179797 3 iwlwifi,mac80211,iwlmvm > sony_laptop36270 0 > ipv6 264130 61 > autofs421176 2 > > -- /etc/initramfs-tools/modules > > -- /etc/kernel-img.conf > # Kernel image management overrides > # See kernel-img.conf(5) for details > do_symlinks = yes > do_bootloader = no > do_initrd = yes > link_in_boot = no > > -- /etc/initramfs-tools/initramfs.conf > MODULES=most > BUSYBOX=y > KEYMAP=n > COMPRESS=gzip > DEVICE= > NFSROOT=auto > > -- /etc/initramfs-tools/update-initramfs.conf > update_initramfs=yes > backup_initramfs=no > > -- mkinitramfs hooks > /etc/initramfs-tools/hooks/: > > /usr/share/initramfs-tools/hooks: > btrfs > busybox > dmsetup > fsck > fuse > intel_microcode > keymap > klibc > kmod > ntfs_3g > resume > thermal > udev > zz-busybox > > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable'), (200, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.1.0-rc2 (SMP w/4 CPU cores; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages initramfs-tools depends on: > ii busybox 1:1.22.0-15 > ii cpio 2.11+dfsg-4.1 > ii klibc-utils 2.0.4-2 > ii kmod 20-1 > ii udev 215-17 > > Versions of packages initramfs-tools recommends: > ii busybox 1:1.22.0-15 > > Versions of packages initramfs-tools suggests: > pn bash-completion > > -- no debconf information > -- Regards, Dimitri.
Bug#652459: Move awk implementations from /usr/bin to /bin
On 31 December 2013 08:11, Vincent Bernat wrote: > ❦ 31 décembre 2013 01:30 CET, m...@linux.it (Marco d'Itri) : > >>> Any thoughts? >> The correct solution is completing #652459, which mounts /usr in the >> initramfs. > > It is quite unclear why this bug is stalled. I believe there were reservations about /etc portions of the patch series, which were asked to be "unbundled" and to be considered separately. I don't know if this was done, if not I guess I should come up with such patch on top of the proposed patch series, as one of the interested parties to get this resolved. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluj1kpjmlat1dgqteojwvdfpeyxhbqmu7ybkyvahju8...@mail.gmail.com