Bug#572215: debian-insaller: Cannot partition an already file system containing HDD
Package: debian-installer Severity: moderate Hi, Take a harddisk and create a file system (say ext3) on the whole disk. # mke2fs -j /dev/sdd # /dev/sdd is entire device, not just one partition! # Proceed anyway? (y,n) y Now use this disk to install debian. Under the partitioning menu, you do not get an option to parition or to intiialize the harddisk. How do I install debian on this HDD ? Bhasker C V Registered linux user #306349 Fedora Ambassador: Bhaslinux -- 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/alpine.deb.1.10.1003021246520.3...@server.uk.unixindia.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
Bug#572241: debian-installer: device nodes for partitions gone away during install
Package: debian-installer Version: squeeze 20100211 Severity: important * installing squeeze via netboot CD mini.iso (ISO file timestamp 2010.02.11), expert mode * after menu item 'detect disk' kernel detects disks and I see /dev/sda, /dev/sda1 etc in shell * after pressing 'partition disks' I only see device nodes for /dev/sda and no partitions (/dev/sda1) (even though fdisk says partitions exist) * after syncing partitions in fdisk by re-writing partition table, the device nodes for this disk reappear This would all be problem with simple workaround (rewriting partitions) but the problem is that after installation and restart, the partitions are gone again (so this might be problem in initrd / kernel?) and system can't boot Disks: ST31000528AS Controller: SATA, Intel 82801IR/IO/IH (ICH9R/DO/DH), AHCI -- System Information: Architecture: amd64 (x86_64) -- 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/20100302153355.29561.87001.report...@q.xf.ee
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
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, 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
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 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: lkdi / etch
On Thu, Feb 25, 2010 at 03:50:18AM +0100, Frans Pop wrote: > On Thursday 25 February 2010, dann frazier wrote: > > fyi, I'm planning to upload a new set of linux-kernel-di packages for > > the upcoming etch point release, mainly to fix a regression on s390 > > (#562525). > > Ack. Let me/us know when there are images that could use testing. All updated d-i builds have now been uploaded by the respective buildds. -- dann frazier -- 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/20100303031003.ga10...@lackof.org
