Debian on Paperwhite [video]

[hari_]

Sorry for my english

I have followed instructions on the thread, everything seams working i get the "I have no name" shell
i run:
/var/lib/dpkg/info/dash.preinst install
dpkg --configure -a

but whenever i try to run apt-get update or i try to install anything whit apt it will hangs "Reading package list" and shell and kindle stop responding.

dmesg shows:
...
EXT3-fs: mounted filesystem with writeback data mode.
INFO: task pdflush:243 blocked for more than 120 seconds.

Someone has same problem or knows how to fix this?

[knc1]

Yes -
You will have to do that step with the loop file mounted on a non-Kindle machine.
(or solder in more ram to your kindle )

[aditya3098]

Originally Posted by hari_

Sorry for my english

I have followed instructions on the thread, everything seams working i get the "I have no name" shell
i run:
/var/lib/dpkg/info/dash.preinst install
dpkg --configure -a

but whenever i try to run apt-get update or i try to install anything whit apt it will hangs "Reading package list" and shell and kindle stop responding.

dmesg shows:
...
EXT3-fs: mounted filesystem with writeback data mode.
INFO: task pdflush:243 blocked for more than 120 seconds.

Someone has same problem or knows how to fix this?

By any chance, did you mount the image ad /mnt/us/debian.ext3?
You should not use /mnt/us. It has some issues with permissions. You should use:

/mnt/base-us/debian.ext3

. base-us is the just usb drive with different permissions.

[twobob]

[root@kindle root]# /mnt/us/debian.sh
[*] Mounting Rootfs...
[*] Preparing Filesystem...
[*] Preparing Network Connections...
[*] Starting Shell...

FATAL: kernel too old
[*]Unmounting Rootfs...

Err... did debian bump the minimum kernel version?

Where do I go the check?

Thanks

[knc1]

They would not have bump'd the minimum kernel version in the very old archived release that we have been using.

So my guess is that the sources where pulled from a newer repository than the old archived one.

- - - - -

I could get smart-ass and ask if you are trying to run Debian/ARM or Debian/S390 - but it is still a little early for that one

[twobob]

Actually, what I am doing is for the kual-system thing mike.

Trying to put together a TINY seed debian to allow us to *background* chroot - thus enabling the newer libc and libm dependant apps to have access to "newer" versions of this things.

In the end I am hoping to dynamically run this from a squash or cram fs.
(Yup just re-using your ideas in a different context as usual)

Could be a fools errand. (thus I chose to walk the road alone until I was sure it wasn't)

I'm retrying with wheezy now. see if I can get something a bit more "stable" going. Also SID is a huge (250mb) pull lately. wheezy can be trimmed I am hoping to something a bit more sensible with love and sticky tape

I would dearly love to know where to track the version bumps though.

If I had to guess: the patches tracker for debian. probably the libc stuff (but as you know I am no expert)

: )

[knc1]

One of the things that needs to be done is that use of an additional CFLAGS option passed to the cross-compiler when building things:
--with-sysroot=/mnt/us/extensions/system

I haven't (yet) played with the various combinations of options for moving the location requirements out of the standard place, it may be more complex than just that.

But when you do a readelf on a binary built that way, it should report:
requesting /mnt/us/extensions/system/lib/ld-linux.so.xx interpreter

And of course, that loader (interpreter) should be searching /mnt/us/extension/system/lib and /mnt/us/extensions/system/usr/lib on its own, **without** any fooling around with 'LD_LIBRARY_PATH'

And since the loader is built as part of building the C library, **everything** has to be re-built, starting with the C library.

Hello, BuildRoot.

[twobob]

I was hoping to use debian crush (or similar) but they binned it.
so... I'll see if can trim down wheezy with: https://wiki.debian.org/ReduceDebian

Worst case scenario I will put together something with Debian Baked maybe.

[knc1]

Originally Posted by knc1

One of the things that needs to be done is that use of an additional CFLAGS option passed to the cross-compiler when building things:
--with-sysroot=/mnt/us/extensions/system

I haven't (yet) played with the various combinations of options for moving the location requirements out of the standard place, it may be more complex than just that.

But when you do a readelf on a binary built that way, it should report:
requesting /mnt/us/extensions/system/lib/ld-linux.so.xx interpreter

And of course, that loader (interpreter) should be searching /mnt/us/extension/system/lib and /mnt/us/extensions/system/usr/lib on its own, **without** any fooling around with 'LD_LIBRARY_PATH'

And since the loader is built as part of building the C library, **everything** has to be re-built, starting with the C library.

Hello, BuildRoot.

Which, catch-22 style, brings us back to your original question - -

"What is the most recent version of eglibc that can be built with the kernel version we have to run?"

PS: Keep in mind, the **AMAZON** kernel headers - not the mainstream kernel headers.

[twobob]

yup. spot on mate.

Would be nice to know where that kind of data is kept.

I googled the ass off of it and came up empty for SID.
I'm hoping wheezy is a bit more stable. Soon find out.

[NiLuJe]

@twobob: the kernel requirement is the libc's job (excluding fun stuff like an init system/udev/systemd for a "real" system). If you're building the libc yourself, you're the one choosing the min kernel version. No idea what Debian does, but for an nptl libc the default is still 2.6.16 IIRC.

[knc1]

Slaps 50 gallons of cold water on face . . . .

Where to find the information:
Look in the C library ./configuration file - there will be a test for the minimum kernel header version required.
It will be using an m4 macro, but should be easy to spot.

The minimum version was bumped to 2.6.20.x over time for some feature(s) - I don't recall what, or if we need those features.
(I will not swear to that, haven't had my head in the building of the C library for a long time.)

[knc1]

--enable-kernel=VERSION compile for compatibility with kernel not older than VERSION

if test "$minimum_kernel" = yes || test "$minimum_kernel" = no; then
  # Better nothing than this.
  minimum_kernel=""
else
  if test "$minimum_kernel" = current; then
    minimum_kernel=`uname -r 2>/dev/null` || minimum_kernel=
  fi
fi

And there we find a cross-compile bomb in the current eglibc configuration file.

[twobob]

Well. I tried wheezy and that still works fine.
So it's got to be a recent SID change.

Ho hum. Time to get out the hack and slash tools. see about minifying wheezy.

Thanks lads

[twobob]

Originally Posted by knc1

Is "fix horrible menus" a major or a minor thing to do?
OR
Just unknown at this time?

Fixable.

The new "fronter" system I'm fiddling with copes nicely with gtkatlantic.

probably shove that in as a demo.