On 23/05/2018 11:57, Paul Wise wrote:
On Wed, May 23, 2018 at 4:55 PM, Gilles wrote:
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
On Wed, May 23, 2018 at 4:55 PM, Gilles wrote:
> 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
On 23/05/2018 11:09, Mark Morgan Lloyd wrote:
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
On 23/05/18 02:15, Paul Wise wrote:
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
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
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
6 matches
Mail list logo
