Luke Kenneth Casson Leighton <lkcl@lkcl.net> writes: > On 12/12/16, Diego Roversi <diegor@tiscali.it> wrote: >> On Mon, 12 Dec 2016 05:35:01 +0000 >> Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote: >> >>> add console=ttyS2 to the kernel parameters, also earlyprintk is really >>> helpful (but you have to have the right options compiled in the kernel >>> to use it). >>> >> >> Ok, I retried with this, and now the serial console works (thanks): > > great! ok so now you have a feedback loop to monitor issues until success. > >> Except the ethernet doesn't works. There are errors in dmesg: > > ok. right. so the next questions are: how flexible are you prepared > to be to get this working, and do you *absolutely* need to use > debian-installer to get this up-and-running? i,e, do you have some > hard requirement that *forces* you to use debian-installer or did you > choose it because you'd heard it was the "normal" way to install > debian? > > the reason i ask is because the last time i actually used > debian-installer on arm hardware was way back in 2010, when frans pop > very kindly built a custom (armel) d-i for the gpl-violating CT-PC89e > which had an S3C6410. i loved the fact that it could be loaded into > memory such that you could install whatever you wanted on whatever > hardware was available, and loved the minimalism... *but*... it's so > complex to set up that i've never been able to successfully build one > for any of the hardware i've been working with. I guess that the problem is getting the right kernel installed into d-i, and then persuading d-i to install that kernel onto the machine? I think you just need to make the kernel udebs and drop them into build/localudes, although if the modules don't make it onto the image you make, that can break things when it tries to find them in the archive, and you then have the issue of getting the same kernel again to instll it on the target -- so you might need to set up a repository for it, or to build an image that's big enough to include the kernel packages. > instead, i've resorted - reluctantly - to using either debootstrap or > qemu-arm to carry out the root filesystem preparation... then copied > that over. > > in doing so, i've *always* dealt exclusively with initrd-less > *custom* kernels, dedicated specifically for the target hardware > (including modules which again are copied over manually). Well, d-i does need the initrd support normally, so that might be an issue. > what i'm hoping to do in the future now that the rk3288 is actually a > decent system is try native compiles, so there stands a chance of > actually compiling up debian-installer native... but that's a looong > way off for me, yet. > > anyway, so we have two possible hints above of paths that you could > choose, here (a third being to download some random rootfs off the > internet that someone else has arbitrarily made decisions on, during > the install.. which is why i really really prefer > debian-installer....) > > ... OR .... > > you could look for a debian-testing "weekly build" version of > debian-installer (which should have a more recent kernel) daily here: https://d-i.debian.org/daily-images/ You may find that there are days when it chokes at the point where it tries to get the modules it needs -- when new kernels get released and the image gets version skew relative to the archive the mini.iso images break. It's only normally a day or two before it gets sorted out. > ... OR.... > > you could try unpacking the debian-installer initrd, compiling your > own kernel, putting in the replacement modules by hand and repacking > it, but FOR GOD's SAKE watch out for the fact that when using cpio you > ABSOLUTELY MUST specify the target directory properly. cpio by > default will unpack with ABSOLUTE paths.... and that means that you > will end up fucking your x86 root filesystem by overwriting critical > system files with the contents of the initrd. done it once... won't > do it again, ever... managed to recover it but it was a bit > hair-raising... As I said, I'm pretty sure you just need to produce kernel udebs, and dump them in the build/localudebs directory -- the thing that normally trips me up is forgetting to bump the version so that the local udeb is a higher version than that available from the archive, with the result that it cheefully uses the ones you didn't want and fools you into another wasted test run. Here are some (slighted rotted) docs: https://wiki.debian.org/DebianInstaller/Modify/CustomKernel wow! perhaps very rotted ... building floppy images as the example? really? do we even support floppies any more? Erm, no I've fixed that. Cheers, Phil. > ... OR.... > > you could ask around to see if someone else has a working (older or > newer) debian-installer from debian/testing or sid that is known to > work and they can provide a copy online for you. > > lots of options, if you're prepared to be flexible. > > l. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature