Re: Yet another [cross] installer
On Tue, Mar 2, 2010 at 11:48, JLB wrote: > Namely, if there was ALWAYS a way (which could not be turned off) to extract > a kernel's configuration (in a format which could be plunked into > /usr/src/linux and used to build new modules) from the running kernel, > things would be much simpler. > > Why this has not already been done is beyond me. > > Yes, it is nice that there is a kernel OPTION that makes the current kernel > config show up as /proc/config or whatnot. But there is certainly room for a > 'middle path', perhaps spitting out some fugly binary which can be > interpreted by an external program/script and thus -converted- into a > properly formatted config file. Try extract-ikconfig: http://howflow.com/tricks/extract_the_configuration_from_a_linux_kernel_image The problem with making this option non-disableable is there are reasons to make the kernel as small as possible: embedded devices, for example, where every kilobyte counts. Will -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/27b05b491003020926s704b12edra04a7e8eef896...@mail.gmail.com
Re: Yet another [cross] installer
On Tue, Mar 02, 2010 at 11:48:55AM -0500, JLB wrote:
> I have a suggestion. The best solution to the 'devices shipped with
> hard/impossible-to-change binary kernels' problem, as far as I can tell,
> would have to come not from the Debian team, but from the upstream kernel
> team.
>
> Namely, if there was ALWAYS a way (which could not be turned off) to
> extract a kernel's configuration (in a format which could be plunked into
> /usr/src/linux and used to build new modules) from the running kernel,
> things would be much simpler.
>
> Why this has not already been done is beyond me.
>
> Yes, it is nice that there is a kernel OPTION that makes the current
> kernel config show up as /proc/config or whatnot. But there is certainly
> room for a 'middle path', perhaps spitting out some fugly binary which
> can be interpreted by an external program/script and thus -converted-
> into a properly formatted config file.
>
> I have one of the CT-PC89E machines. It has a binary kernel. This kernel
> is burned into a partition of the internal 2GB SSD which, as far as I can
> tell, is not any known type of filesystem ('file', run on a dd dump of
> this partition, just says 'data'; the only way to get any useful info out
> of this partition's contents is to pass it through 'strings'). As has
> been pointed out on this thread, the problem of devices shipped with
> binary-only kernels is only going to get worse.
>
> It would be EXCELLENT if I could just run some external program and have
> it dump a config file... Then I could go in and compile as many new
> modules as I want. For example, ext3... which this machine's kernel lacks
> support for!
>
> If every kernel in the future had a non-disableable ability to dump a
> 'fingerprint' of its config data (even in some fugly format that required
> an external program to interpret), then the Chinese manufacturers could
> not pull this crap (not without explicitly editing the kernel source to
> remove this feature, which I HIGHLY doubt most would bother with).
Of course embedded people hate wasted space, so they would insist on
being able to remove it.
And of course anyone that wants to remove it can, since they have
the source.
Not that a config is really all that helpful, given often you lack the
necesary drivers or kernel patches that were used in the first place.
--
Len Sorensen
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20100302171307.gg4...@caffeine.csclub.uwaterloo.ca
Re: Yet another [cross] installer
On Mon, 1 Mar 2010, Hector Oron wrote:
Hello,
Nowadays, the number of devices (non x86) is growing and growing.
Lots of these devices have not upstream linux kernel support, which
makes it a bit harder to maintain in the context of debian-installer.
Also, afaict, debian-installer team does not like to add complexity to
d-i, which I understand, so it has better maintainability in the
future.
Also live-installer could be the path to track for such kind of
devices, but again, live-installer was not meant for such purposes and
I believe maintainer won't be happy to add such extra features.
Ubuntu people has been working on a nice tool (evolution from
build_arm_rootfs) named 'rootstock' which basically prepares a
filesystem for ARM targets.
I have N armel devices, some mipsel ones and powerpc, most of them
are not mainlined supported, but a third party supports it. I would
like to work on a tool which can handle all my devices and it is
scalable to support other people devices, either using native or
cross; with MTD, SD, USB support; with and without using qemu magic;
with official debian repositories and non-official ones (SH, avr32,
uClibc targets, ...)
I have started a couple wiki pages for porting PS3 and EfikaMX
(still WIP) boards to Debian in a "hackish" way. I would also like to
add balloonboard support among others.
I would like to have some feedback from the community to see which
it is best way forward *in a Debian way of doing things* or
suggestions and thoughts. So the question would be:
Which is best way forward, in your opinion, for supporting non-x86
arches installations (even installation done from a x86 platform)?
(debian-installer, live-installer, rootstock or start from scratch)
Kind regards,
--
Héctor Orón
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/dd0a3d701003011102k3478ac26g87f060088b6be...@mail.gmail.com
I have a suggestion. The best solution to the 'devices shipped with
hard/impossible-to-change binary kernels' problem, as far as I can tell,
would have to come not from the Debian team, but from the upstream kernel
team.
Namely, if there was ALWAYS a way (which could not be turned off) to
extract a kernel's configuration (in a format which could be plunked into
/usr/src/linux and used to build new modules) from the running kernel,
things would be much simpler.
Why this has not already been done is beyond me.
Yes, it is nice that there is a kernel OPTION that makes the current
kernel config show up as /proc/config or whatnot. But there is certainly
room for a 'middle path', perhaps spitting out some fugly binary which can
be interpreted by an external program/script and thus -converted- into a
properly formatted config file.
I have one of the CT-PC89E machines. It has a binary kernel. This kernel
is burned into a partition of the internal 2GB SSD which, as far as I can
tell, is not any known type of filesystem ('file', run on a dd dump of
this partition, just says 'data'; the only way to get any useful info out
of this partition's contents is to pass it through 'strings'). As has been
pointed out on this thread, the problem of devices shipped with
binary-only kernels is only going to get worse.
It would be EXCELLENT if I could just run some external program and have
it dump a config file... Then I could go in and compile as many new
modules as I want. For example, ext3... which this machine's kernel lacks
support for!
If every kernel in the future had a non-disableable ability to dump a
'fingerprint' of its config data (even in some fugly format that required
an external program to interpret), then the Chinese manufacturers could
not pull this crap (not without explicitly editing the kernel source to
remove this feature, which I HIGHLY doubt most would bother with).
--Jessica
CT-PC89E ARM netbook (was: Yet another [cross] installer)
On Tue, Mar 2, 2010 at 3:59 PM, Benjamin Henrion wrote: > Do you know where I can buy such device? cc'd to adam gill, he's the person with direct contact with the factory. [ the rest of this message is informational, for your benefit, ben, and also for anyone else who'd like one, too, so you know what to expect ] there are about 25 samples available in the configuration that the factory put together, and adam's asked them yesterday to reserve 20. the price we got on the last batch of 20, including something for adam for going to china, picking them up, taking them out their 1.2kg paper/box packaging and replacing it with 0.2kg bubble-wrap/jiffy-bag, was $USD 162.80 ($148+10%). adam _will_ need to re-confirm that price with them. add shipping (approx $30) and then pray for a customs-related miracle (be ready to sacrifice goat just in case) in the country of your choice hurrah! if you're going to help get debian on it, then you definitely qualify as "engineering", so you'd be perfectly within your rights to legitimately request that adam put "engineering sample" on the customs declaration, and thus would not need to pay customs import duty. VAT and handling charges (ParcelFarce charge £13.50) are a different matter, however. alain williams is evaluating one of these for business purposes, so has been able to claim the VAT back. so, from experience, that's what you can expect, ok? in the mean-time i'm talking to numerous UK retail stores, recommending to them that they consider stocking this item. before that happens, it would be _really_ good to get debian on it, and a GUI, all working in a similar way to http://mid-linux.org "MOS" which is bloody good, btw, i'm dead impressed with MOS, so there's quite a high bar set, there. > I am ready to help trying to get Debian running on it. great! well, i kiiinda have it going as a "starter": http://elinux.org/CT-PC89E_Debian with links there to the debian/lenny tarball on my web site and to the factory installer zImage etc. which you have to replace the datang-epc.tar.gz with your own ready-rolled rootfs _under_ 450mb in size. but that's nowhere like an "installer" per se, it's more of a hacked-together lenny install, which originally came from a qemu boot-up off of a debian-armel XFCE ISO (without the XFCE, it just doesn't fit into 450mb). following up from wookey's laughing at me (nicely, mind :) for manually replicating hack-style what emdebian (grip) does to get down to under 450mb anyway, it might be nice to have another go at doing a rootfs tarball, but with emdebian (grip) and then another with emdebian (squeeze) too. l. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ced5f0f61003020847p734fade3p200b42bee5065...@mail.gmail.com
Re: Yet another [cross] installer
On Mon, Mar 1, 2010 at 9:55 PM, Luke Kenneth Casson Leighton wrote: > On Mon, Mar 1, 2010 at 7:02 PM, Hector Oron wrote: >> Hello, > > hi hector, this is a timely message / issue to raise: it's very > relevant for the (newly discovered) CT-PC89E arm netbook which a > friend of mine found. > >> Nowadays, the number of devices (non x86) is growing and growing. >> Lots of these devices have not upstream linux kernel support, which >> makes it a bit harder to maintain in the context of debian-installer. > > in the case of the CT-PC89E, we haven't yet taken on the burdensome > and patient task of explaining the implications of the GPL to the > factory, yet, and of the need and obligation for them to provide the > GPL source code of both the linux kernel _and_ of the u-boot startup. > > i'm not mentioning this in order for people to go, "well, you're a > fool, and you can expect every problem you get, can't you, and don't > expect anyone on any debian mailing to ever provide you with any > assistance whatsoever". > > i'm mentioning it because with the increased uptake in guhoogul > anderoyd, the complete lack of understanding of the hardware > manufacturers - chinese - for the implications and obligations of the > GPL is going to be much more commonplace. > > thus, _realistically_, it makes sense to take into consideration that > some devices aren't going to _immediately_ get the linux source code, > and thus the fact that there may be binary-only linux kernels to work > from - initially - would also need to be taken into consideration. Do you know where I can buy such device? I am ready to help trying to get Debian running on it. -- Benjamin Henrion FFII Brussels - +32-484-566109 - +32-2-4148403 "In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators." -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/560c7c9a1003020759i4645e8ddm7e0149a313ace...@mail.gmail.com
Re: Yet another [cross] installer
(Dropped private CCs) On Monday 01 March 2010, Luke Kenneth Casson Leighton wrote: > * the binary-only kernel we're working with, they haven't even > bothered to put in ext2,3 or 4 ext4 is enabled. From dmesg: EXT4-fs warning: checktime reached, running e2fsck is recommended EXT4 FS on mmcblk0p3, internal journal EXT4-fs: recovery complete. EXT4-fs: mounted filesystem with ordered data mode. EXT4-fs: file extents enabled And: # grep ext4 /proc/filesystems ext4dev But yes, it's only msdox, vfat and ext4dev. /me wonders if ext4 really was stable enough for this kind of usage back in 2.6.24... Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003021643.56590.elen...@planet.nl
Re: Yet another [cross] installer
On Mon, Mar 1, 2010 at 7:02 PM, Hector Oron wrote: > Hello, hi hector, this is a timely message / issue to raise: it's very relevant for the (newly discovered) CT-PC89E arm netbook which a friend of mine found. > Nowadays, the number of devices (non x86) is growing and growing. > Lots of these devices have not upstream linux kernel support, which > makes it a bit harder to maintain in the context of debian-installer. in the case of the CT-PC89E, we haven't yet taken on the burdensome and patient task of explaining the implications of the GPL to the factory, yet, and of the need and obligation for them to provide the GPL source code of both the linux kernel _and_ of the u-boot startup. i'm not mentioning this in order for people to go, "well, you're a fool, and you can expect every problem you get, can't you, and don't expect anyone on any debian mailing to ever provide you with any assistance whatsoever". i'm mentioning it because with the increased uptake in guhoogul anderoyd, the complete lack of understanding of the hardware manufacturers - chinese - for the implications and obligations of the GPL is going to be much more commonplace. thus, _realistically_, it makes sense to take into consideration that some devices aren't going to _immediately_ get the linux source code, and thus the fact that there may be binary-only linux kernels to work from - initially - would also need to be taken into consideration. > Also, afaict, debian-installer team does not like to add complexity to > d-i, which I understand, so it has better maintainability in the > future. > > Also live-installer could be the path to track for such kind of > devices, but again, live-installer was not meant for such purposes and > I believe maintainer won't be happy to add such extra features. > > Ubuntu people has been working on a nice tool (evolution from > build_arm_rootfs) named 'rootstock' which basically prepares a > filesystem for ARM targets. yes - i heard about this. i did the hack-job approach before i'd heard of it: qemu for ARM, installed rsync, then rsync'd the root filesystem out. not ideal, but it did the job. > Which is best way forward, in your opinion, for supporting non-x86 > arches installations (even installation done from a x86 platform)? > (debian-installer, live-installer, rootstock or start from scratch) there are two different main categories of systems. the first is one where you have access to the storage device: it can be removed (SD card), the system can somehow be booted from SD card, USB, etc. whatever it is, it's possible to just "blop" a root filesystem onto it, and go. for these, i think the absolute ideal case would be to have a netboot installer which can replace itself. for example, by creating a ramdisk, pivot-rooting onto it and then umounting the root filesystem. exactly the _opposite_ of initrd :) then the root filesystem is free to be wiped out, and the "real" OS installed. variations on this theme include the CD / ISO "searcher" - the usbstick stuff. having pivot-rooted into a ramdisk, it would be handy to have an option of going hunting on usb and other storage for iso filesystems or iso images. [i imagine that this is pretty much what, or is near-as-damnit similar to what debian-live does, but that's another story] the second case is where you have absolutely no chance of gaining access to the root filesystem in any kind of "normal" sense. this is the example of the CT-PC89E: what we've got, that's it, we're hosed (for now), and we have to work within the structure that the factory has imposed, which is this: http://www.denx.de/wiki/view/DULG/RootFileSystemInAReadOnlyFile this is our "way in", because they've followed that procedure, and it turns out that yes, we can press-and-hold power and both mouse buttons, activating the factory's "upgrade" procedure, and thus "drop" the contents of a .tgz archived root filesystem directly onto the NAND flash, by creating our own "datang-epc.tar.gz". this was how i managed to get debian/lenny onto the CT-PC89E: http://elinux.org/CT-PC89E_Debian now, what would have been _really nice to have_ would have been a debian-installer tarball (as described in case 1, with the preparation to get itself into a ramdisk that's then pivot_root'd) which could be unpacked onto the NAND flash by the hardware manufacturer's "upgrade" procedures, and then, after a reboot, it would go directly into the debian installer etc. etc. just as in case 1). and no, right now, we don't even have access to the serial console on which u-boot is displaying its startup messages: there's an unpopulated header on the CPU+RAM+NAND SO-DIMM. other important caveats: * the binary-only kernel we're working with, they haven't even bothered to put in ext2,3 or 4 and so despite the u-boot-loaded initrd being able to gain access to the ext2 root filesystem, we can't mount any partitions other than FAT, once debian is actually running. the implications of th
Yet another [cross] installer
Hello, Nowadays, the number of devices (non x86) is growing and growing. Lots of these devices have not upstream linux kernel support, which makes it a bit harder to maintain in the context of debian-installer. Also, afaict, debian-installer team does not like to add complexity to d-i, which I understand, so it has better maintainability in the future. Also live-installer could be the path to track for such kind of devices, but again, live-installer was not meant for such purposes and I believe maintainer won't be happy to add such extra features. Ubuntu people has been working on a nice tool (evolution from build_arm_rootfs) named 'rootstock' which basically prepares a filesystem for ARM targets. I have N armel devices, some mipsel ones and powerpc, most of them are not mainlined supported, but a third party supports it. I would like to work on a tool which can handle all my devices and it is scalable to support other people devices, either using native or cross; with MTD, SD, USB support; with and without using qemu magic; with official debian repositories and non-official ones (SH, avr32, uClibc targets, ...) I have started a couple wiki pages for porting PS3 and EfikaMX (still WIP) boards to Debian in a "hackish" way. I would also like to add balloonboard support among others. I would like to have some feedback from the community to see which it is best way forward *in a Debian way of doing things* or suggestions and thoughts. So the question would be: Which is best way forward, in your opinion, for supporting non-x86 arches installations (even installation done from a x86 platform)? (debian-installer, live-installer, rootstock or start from scratch) Kind regards, -- Héctor Orón -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/dd0a3d701003011102k3478ac26g87f060088b6be...@mail.gmail.com
Re: cross-installer
On Tue, Jun 20, 2006 at 01:29:38PM +0200, Geert Stappers wrote: > On Tue, Jun 20, 2006 at 11:45:00AM +0200, Andreas Jochens wrote: > > Hello, > > > > Holger Levsen wrote: > > > which solution do you think is better? the cross-installer (isnt there > > > one for amd64 already?) or the native installer? > > > > There is currently no cross-installer for amd64 as far as I know. > > > > There is not even a 64-bit kernel flavor in the i386 repository. > > There was one some time ago but it has been discontinued. > > > > I do not think that there is a 'better' solution. Both solutions > > have their place. The amd64 native 64-bit installer should not be > > dropped just because the i386 32-bit installer can be used to > > cross-install amd64. The same is true for the ppc64 case in my opinion. > > > > Anyway, at the moment the native 64-bit installer is the only one > > that works for the ppc64 installation. But it would certainly be > > helpful to get the cross-installation option also implemented. > > Another question regarding cross-installation: > > Would the cross-installer allow installation across architectures? > > Examples Given: > * On a recent Macintosh (powerpc) doing the install > and take the SCSI-disk to an old Mac (m68k) > * On an AMD64 computer doing the install > and serve the network-disk to a ARM system. Yes and no. IT would allow to do such install in the same way that cross-debootstrap works, but hardware detection and kernel/ramdisk installation are issues which need to be worked on. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cross-installer
[EMAIL PROTECTED] (Geert Stappers) writes:
> On Tue, Jun 20, 2006 at 11:45:00AM +0200, Andreas Jochens wrote:
>> Hello,
>>
>> Holger Levsen wrote:
>> > which solution do you think is better? the cross-installer (isnt there
>> > one for amd64 already?) or the native installer?
>>
>> There is currently no cross-installer for amd64 as far as I know.
>>
>> There is not even a 64-bit kernel flavor in the i386 repository.
>> There was one some time ago but it has been discontinued.
>>
>> I do not think that there is a 'better' solution. Both solutions
>> have their place. The amd64 native 64-bit installer should not be
>> dropped just because the i386 32-bit installer can be used to
>> cross-install amd64. The same is true for the ppc64 case in my opinion.
>>
>> Anyway, at the moment the native 64-bit installer is the only one
>> that works for the ppc64 installation. But it would certainly be
>> helpful to get the cross-installation option also implemented.
>
> Another question regarding cross-installation:
>
> Would the cross-installer allow installation across architectures?
>
> Examples Given:
> * On a recent Macintosh (powerpc) doing the install
> and take the SCSI-disk to an old Mac (m68k)
> * On an AMD64 computer doing the install
> and serve the network-disk to a ARM system.
You can always run "(c)debootstrap -a" untill it fails when it
chroots into the target. Then go to the actual target system and boot
with init=/bin/sh and then
- dpkg --force-depends -i /var/cache/apt/archives/{libc6,dpkg}*.deb
- maybe force some more packages to get dpkg/libc6 depends satisfied
- dpkg -iGROEB /var/cache/apt/archives/
- repeat till there are no more errors
- fix fstab, create user, setup sources.list, ...
- reboot
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cross-installer
On Tue, Jun 20, 2006 at 11:45:00AM +0200, Andreas Jochens wrote: > Hello, > > Holger Levsen wrote: > > which solution do you think is better? the cross-installer (isnt there > > one for amd64 already?) or the native installer? > > There is currently no cross-installer for amd64 as far as I know. > > There is not even a 64-bit kernel flavor in the i386 repository. > There was one some time ago but it has been discontinued. > > I do not think that there is a 'better' solution. Both solutions > have their place. The amd64 native 64-bit installer should not be > dropped just because the i386 32-bit installer can be used to > cross-install amd64. The same is true for the ppc64 case in my opinion. > > Anyway, at the moment the native 64-bit installer is the only one > that works for the ppc64 installation. But it would certainly be > helpful to get the cross-installation option also implemented. Another question regarding cross-installation: Would the cross-installer allow installation across architectures? Examples Given: * On a recent Macintosh (powerpc) doing the install and take the SCSI-disk to an old Mac (m68k) * On an AMD64 computer doing the install and serve the network-disk to a ARM system. Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
