Busbox missing fdisk and fsck: How to add?

[Gilles]

Hello,

On an ARM appliance, as a way to run fsck on a USB keydrive that holds
/boot and /, I was thinking of running a small Linux image from RAM
after downloading it through TFTP.

Problem is, the Busybox it contains is missing fdisk and fsck:

========
BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # help
Built-in commands:
------------------
        . : [ bg break cd chdir command continue echo eval exec exit
        export false fg getopts hash help history jobs kill let local
        printf pwd read readonly return set shift test times trap true
        type ulimit umask unset wait

~ # fdisk -l
/bin/sh: fdisk: not found

~ # fsck /dev/sda1
/bin/sh: fsck: not found
========

It does contain wget, however: Is there a way to download a compatible
fsck binary from somewhere?

Thank you.

[Paul Wise]

On an ARM appliance, as a way to run fsck on a USB keydrive that holds /boot
and /, I was thinking of running a small Linux image from RAM after
downloading it through TFTP.

Another option would be to use debirf to build an initramfs-based live
system that looks like your normal system (minus logs/data/config),
runs entirely from RAM and contains fsck and any other tools needed
for rescuing the system. I'm not sure if it can do cross-arch builds
but failing that you could build it on the ARM system you have.

http://cmrg.fifthhorseman.net/wiki/debirf
It should be feasible to download the source package, tweak the build
config, rebuild the binary packages, extract the relevant binaries and
include them in your small Linux image.

apt build-dep busybox
apt source busybox
cd busybox-*/
$EDITOR <busybox-build-configs>
dpkg-buildpackage
cd ..
dpkg-deb -x busybox-static*.deb busybox-static
cp busybox-static/bin/busybox /srv/tftp/

Is there a way to download a compatible fsck binary from somewhere?

You would have to either build it or get someone else to do that for you.

You could use the one from the normal fsck packages instead of busybox.

I don't know how big the busybox fdisk/fsck support is, but it might
be worth reporting a bug on busybox asking for them to be enabled.
Alternatively, a bug report asking for a busybox-static-full package
containing support for every busybox applet might be a good idea.

[Gilles]

Thanks very much for the infos.

It looks like the easiest solution to the problem would be
cross-compiling fsck on a i386 Linux host, and copying the binary onto
the the appliance.

I only have shallow experience with cross-compiling, though: Is this
newbie-doable or am I in for days of head-scratching ?

Post by Paul Wise

On an ARM appliance, as a way to run fsck on a USB keydrive that holds /boot
and /, I was thinking of running a small Linux image from RAM after
downloading it through TFTP.

Another option would be to use debirf to build an initramfs-based live
system that looks like your normal system (minus logs/data/config),
runs entirely from RAM and contains fsck and any other tools needed
for rescuing the system. I'm not sure if it can do cross-arch builds
but failing that you could build it on the ARM system you have.
http://cmrg.fifthhorseman.net/wiki/debirf
It should be feasible to download the source package, tweak the build
config, rebuild the binary packages, extract the relevant binaries and
include them in your small Linux image.
apt build-dep busybox
apt source busybox
cd busybox-*/
$EDITOR <busybox-build-configs>
dpkg-buildpackage
cd ..
dpkg-deb -x busybox-static*.deb busybox-static
cp busybox-static/bin/busybox /srv/tftp/

Is there a way to download a compatible fsck binary from somewhere?

You would have to either build it or get someone else to do that for you.
You could use the one from the normal fsck packages instead of busybox.
I don't know how big the busybox fdisk/fsck support is, but it might
be worth reporting a bug on busybox asking for them to be enabled.
Alternatively, a bug report asking for a busybox-static-full package
containing support for every busybox applet might be a good idea.

[Paul Wise]

It looks like the easiest solution to the problem would be cross-compiling
fsck on a i386 Linux host, and copying the binary onto the the appliance.

It is getting better but usually compiling natively is much easier.

I only have shallow experience with cross-compiling, though: Is this
newbie-doable or am I in for days of head-scratching ?

If the source package is cross-compilable, then it isn't much
different from compiling natively.

https://wiki.debian.org/CrossCompiling

IIRC Helmut (one of the few people working on it) says only about 10%
of Debian is cross-compilable though. If anyone wants to help improve
that, please introduce yourself on the debian-cross mailing list.

https://lists.debian.org/debian-cross/

[Gilles]

Post by Paul Wise

It looks like the easiest solution to the problem would be cross-compiling
fsck on a i386 Linux host, and copying the binary onto the the appliance.

It is getting better but usually compiling natively is much easier.

I only have shallow experience with cross-compiling, though: Is this
newbie-doable or am I in for days of head-scratching ?

If the source package is cross-compilable, then it isn't much
different from compiling natively.
https://wiki.debian.org/CrossCompiling
IIRC Helmut (one of the few people working on it) says only about 10%
of Debian is cross-compilable though. If anyone wants to help improve
that, please introduce yourself on the debian-cross mailing list.
https://lists.debian.org/debian-cross/

Thanks for the infos. I'll try this if I need to cross-compile an app
one day.

[Gilles]

Edit: Elsewhere, someone mentioned a much easier solution : Just unplug
the USB keydrive from the ARM appliance, and perform the fsck onto a PC
running Linux.

Why didn't I think of this (face-palm) ?

Thank you.

===
Thanks very much for the infos.

It looks like the easiest solution to the problem would be
cross-compiling fsck on a i386 Linux host, and copying the binary onto
the the appliance.

I only have shallow experience with cross-compiling, though: Is this
newbie-doable or am I in for days of head-scratching ?

Post by Paul Wise

On an ARM appliance, as a way to run fsck on a USB keydrive that holds /boot
and /, I was thinking of running a small Linux image from RAM after
downloading it through TFTP.

Another option would be to use debirf to build an initramfs-based live
system that looks like your normal system (minus logs/data/config),
runs entirely from RAM and contains fsck and any other tools needed
for rescuing the system. I'm not sure if it can do cross-arch builds
but failing that you could build it on the ARM system you have.
http://cmrg.fifthhorseman.net/wiki/debirf
It should be feasible to download the source package, tweak the build
config, rebuild the binary packages, extract the relevant binaries and
include them in your small Linux image.
apt build-dep busybox
apt source busybox
cd busybox-*/
$EDITOR <busybox-build-configs>
dpkg-buildpackage
cd ..
dpkg-deb -x busybox-static*.deb busybox-static
cp busybox-static/bin/busybox /srv/tftp/

Is there a way to download a compatible fsck binary from somewhere?

You would have to either build it or get someone else to do that for you.
You could use the one from the normal fsck packages instead of busybox.
I don't know how big the busybox fdisk/fsck support is, but it might
be worth reporting a bug on busybox asking for them to be enabled.
Alternatively, a bug report asking for a busybox-static-full package
containing support for every busybox applet might be a good idea.

[Gilles]

Please excuse a comment from a lurker, but I'd suggest that it would
be worth having at least  fdisk -l  capability enabled by default
since one of the first things one wants to do when in any sort of
development or recovery situation is to work out what media is
attached and whether it's partitioned or a single fiefsystem.

I agree. It's too bad the image I found had Busybox compiled without
fdisk and fsck.