Re: Offer to make a native 32-bit system avaiable

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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?)

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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 <dimitri.j.led...@intel.com>
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 <dimitri.j.led...@intel.com>
---
 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

[Dimitri John Ledkov]

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 dimitri.j.led...@intel.com
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

[Dimitri John Ledkov]

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 prein...@logic.at 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  none

 -- no debconf information




-- 
Regards,

Dimitri.

Bug#784234: initramfs-tools: searches for fsck.btrfs in the wrong directory

[Dimitri John Ledkov]

On 4 May 2015 at 19:25, Ben Hutchings b...@decadent.org.uk 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#652459: Move awk implementations from /usr/bin to /bin

[Dimitri John Ledkov]

On 31 December 2013 08:11, Vincent Bernat ber...@debian.org 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