Re: New UEFI ISO built with old xorriso
Hi, I'll update before the next one, I promise! :-) I wonder why no firmware ever complains about the bug. Let's hope that none of them depends on GPT CRC being wrong. :)) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/18017537396330728...@scdbackup.webframe.org
jessie uefi netinst build 2 test.
Hi, This was a quick initial test which went up to partitioning the disk. Asus eeepc, i386 no problem Acer E1 531 notebook secure boot on. i386, no problem. amd64, kernel/modules mismatch. Initial boot OK. A usb stick was used in all cases. Will do a full round of installations when amd64 is fixed. Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 027 663 4453 phil...@copyleft.co.nz - personal.i...@copyleft.co.nz - business -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1420703131.11179.13.ca...@copyleft.co.nz
Re: Please dak copy-installer 20150107 hint it into testing
Ansgar Burchardt ans...@debian.org (2015-01-07): Cyril Brulebois k...@debian.org writes: dak copy-installer 20150107 Done. Thanks, Ansgar. Release team, I've gone ahead and hinted debian-installer myself, so that Steve (cc'd through debian-cd@) can trigger a build after the 1000 britney and 1352 dinstall runs (and associated mirror pulse). Steve, please use jessie_di_rc1, which seems to be the kind of URL we've been using for release candidates (if I'm reading cvs's output properly). FWIW the announce text is nowhere ready and I'm travelling this thursday; so I doubt the release will be built + ready to announce before somewhen on friday. Mraw, KiBi. signature.asc Description: Digital signature
UEFI 32 bit on Proliant X2
Hi, I'm currently triing to install Jessie on a Proliant X2 (10-k010nz) with Atom Z3736F. Steve's image is able to boot on uefi 32 but I get stuck by the fact that I have only 1 USB port, no ethernet and wifi only network. Would be very kind if the installer either would be a full CD (or a wireless comaptible, but in that case also the realteck rtl8723bs could make some problems). Regards Giorgio P.S: I'll also try with a port multiplier and an USB-Ethernet adapter -- Giorgio Pioda - Sysadmin SPSE-Tenero Cell +41 79 629 20 63 Tel +41 58 468 62 48 Fax +41 58 468 61 98 -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150107113641.ga19...@macchianera.pioderia.lan
Re: Providing (armhf) u-boot images together with d-i images?
On Fri, 2015-01-02 at 14:51 +0100, Karsten Merker wrote: On Fri, Jan 02, 2015 at 10:46:37AM +, Ian Campbell wrote: On Wed, 2014-12-31 at 01:59 +0100, Karsten Merker wrote: Talking about other compression schemes or providing multiple versions of the same file will just confuse users. It looks like someone has commented on the duplicated concat examples in v3 too. Ok, I'll change the wording for V4. My intention was to provide a generic README that works regardless of which compression options one chooses in the makefile, so that switching from .gz to .xz would be simple without having to think of updating documentation elsewhere. If I now change the README to explicitly mention only one compression type, on which one shall we settle for all installer images on armhf? Everything compressed by gzip or by xz? As usual, this is a trade-off between compression ratio, CPU cycles and memory requirements on the build hosts. I'd say go for gzip for maximum compatibility, e.g. for people making images from Windows. The previous patch produces hd-media builds for use with CD/DVD iso images (equivalent to the i386/amd64 hd-media boot.img.gz). This patch produces a netboot SD card (equivalent to the i386/amd64 netboot mini.iso), plus a netboot.tar.gz which contains everything needed to be put onto a tftp server for tftp-booting the installer (equivalent to the i386/amd64 PXE netboot.tar.gz). netboot.tar.gz sounds fine. What I don't get (see my reply to Vagrant) is what the practical difference to the user is between the hd-media builds and the netboot mini.iso ones, given that for ARM each is just an sd-card image. The netboot and hd-media versions contain different installer builds - the list of udebs in them and the order of the udebs being executed is different between the two (see http://d-i.alioth.debian.org/doc/internals/ch02.html). The netboot image has to have network access to work, it loads all additional udebs it needs and all regular packages from the network. The hd-media one is for installing from local media and can work completely offline. This distinction is made on all platforms supported by d-i and unifying those two does not seem to work (sorry, I do not remember the details; IIRC it had something to do with different and conflicting anna implementations for the two variants). Got it, thanks (I had a question in my reply to Vagrant, I won't repeat it here). For the tftpboot part, u-boot supports standard pxelinux.cfg syntax configuration files -- would it be better to just generate a suitable one of those? I have not in detail checked the pxelinux.cfg support in u-boot yet, but as we unfortunately have to build special-casing into the boot script for several platform (such as the i.MX6 console baudrate issue), I do not see how to implement that with the pxelinux.cfg syntax. Pointers welcome :). IMHO we should be moving towards using this way of doing things, which might mean fixing things like the i.MX6 issue at source. Too late for Jessie of course. BTW our kernel now supports the /chosen/stdout-path property in fdt and will automatically put a console on it. Just to make sure that I understand that correctly: with the u-boot and kernel versions currently in Jessie, there is no need to ever pass a console parameter to the kernel on any platform? Or is this something that was introduced after the u-boot v2014-10 release in Jessie? /chosen/stdout-path is more a function of the kernel and the dtb, I don't think u-boot is involved much at all, at it need not be. I suppose on platforms where there is a choice of consoles it might auto update the stdout-path to reflect where u-boot is outputting it's stuff, but you'll get some sort of sane default for the platform either way (assuming the dtb is sane). If the former, using pxelinux.cfg should indeed work everywhere; if the latter, we would have to keep using boot.scr for Jessie. I think it's the former. Inside the existing hd-media and netboot directories, a subdirectory SD-card-images gets created, which then contains the created images. These have the following sizes: option netboot full image: 18568 A10-OLinuXino-Lime.img.gz 18572 A20-OLinuXino-Lime.img.gz 18572 BananaPi.img.gz 18640 BeagleBoneBlack.img.gz 18572 Cubieboard2.img.gz 18568 Cubieboard.img.gz 18572 Cubietruck.img.gz 18564 MX53LOCO.img.gz 18568 MX6_Cubox-i.img.gz 18560 PandaBoard.img.gz 18552 Wandboard_Quad.img.gz So around 200M in total? I haven't checked but I would imagine that was an order of magnitude more than d-i produces for any other arch in the d-i builds. As I wrote in my previous mail, we could squash that down to 18M once + ~200kB per platform if we manage to unify the boot process (be it with an
Re: Providing (armhf) u-boot images together with d-i images?
On Fri, 2015-01-02 at 22:13 +0100, Karsten Merker wrote:
On Fri, Jan 02, 2015 at 02:51:18PM +0100, Karsten Merker wrote:
On Fri, Jan 02, 2015 at 10:46:37AM +, Ian Campbell wrote:
BTW our kernel now supports the /chosen/stdout-path property in fdt and
will automatically put a console on it.
Just to make sure that I understand that correctly: with the
u-boot and kernel versions currently in Jessie, there is no need
to ever pass a console parameter to the kernel on any platform?
Or is this something that was introduced after the u-boot v2014-10
release in Jessie?
Hello,
I have in the meantime run some tests and this functionality does
not seem to be available with the current versions in Jessie. If
I do not explicitly set bootargs to include a console parameter,
I get no console output, although u-boot has a valid ${console}.
The support is in linux 3.16.7-ckt2-1, which is in Jessie right now but
I don't know if it is in the kernel used by the current d-i, probably
not since that is in the process of being updated.
Even if we cannot use that functionality at the moment, I am
interested in how it works: does u-boot just copy the content of
${console} into the /chosen/stdout-path property, or is there
some additional mechanism to hand over a baudrate for serial
connections to the kernel?
I think it comes from the fdt, u-boot needn't be involved at all,
although it could be if the platform demanded it.
The stdout-path property is a device-tree path to the device to use, so
it is e.g. /smb/motherboard/iofpga@3,/uart@09 (or an
equivalent alias), it's not e.g. ttyS0 or ttyAMA0 etc.
Ian.
--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1420654688.11796.24.ca...@debian.org
Re: Providing (armhf) u-boot images together with d-i images?
On 2015-01-07, Ian Campbell wrote: On Fri, 2015-01-02 at 08:59 -0800, Vagrant Cascadian wrote: On 2015-01-02, Ian Campbell wrote: On Tue, 2014-12-30 at 13:42 -0800, Vagrant Cascadian wrote: On 2014-12-30, Ian Campbell wrote: But I still have a question about the hd-media sd-card images -- aren't they only useful in concert with something which adds the .iso etc to the image too? Yes, the hd-media images still need an .iso file on some other media, such as USB, SATA or an additional SD card. And therefore aren't they more usefully built along with that iso? Otherwise how do you know how big to make the partition to contain the iso at d-i build time given the varied sizes of .iso and sd-card you can buy? It would also be nice to have media with the .iso file built-in, but I don't think a requirement for it to be useful without that. I definitely see the case for moving some of the code into debian-cd, or another utility. I've considered making such a utility and shipping it in u-boot-tools, but didn't get around to it for jessie. The sd-card offsets in this patchset duplicate information in the various u-boot* README.Debian files, and it would make sense to move that into a script. This script could also generate SD images with a vmlinuz, initrd, bootscript, dtb, .iso, etc. and would be useful outside the context of debian-installer. Then, if debian-installer, debian-cd, or some other utility wanted to use it, then they could depend on u-boot-tools... live well, vagrant signature.asc Description: PGP signature
Re: Providing (armhf) u-boot images together with d-i images?
On Fri, 2015-01-02 at 16:40 +0100, Cyril Brulebois wrote: Karsten Merker mer...@debian.org (2015-01-02): (Do your patches end up adding the correct Built-Using on u-boot?) No, they don't, but d-i does not do that for similar components on other platforms (syslinux/isolinux/grub) as well. Probably we should do that, but then it would have to be done for all platforms. Kibi? ISTR having proposed a patch to #700026 / #696418, but that wasn't commented upon. FWIW the patch in #700026 looks good to me as a starting point... Ian. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1420655029.11796.25.ca...@debian.org
Re: Providing (armhf) u-boot images together with d-i images?
On 2015-01-05, Cyril Brulebois wrote: Karsten Merker mer...@debian.org (2015-01-02): Ok, I'll change the wording for V4. My intention was to provide a generic README that works regardless of which compression options one chooses in the makefile, so that switching from .gz to .xz would be simple without having to think of updating documentation elsewhere. Given discussions on this patchset are still going on, I've decided to stop waiting on it, and to upload d-i without it. Not to delay a new d-i version, but I'm wondering if it makes sense to decouple some of the parts of the patchset into a smaller patchset at this point, such as the netboot/tftpboot support with u-boot only sd images? Maybe concatenateable images? Some of these features seem only somewhat related, and it would be nice to get the uncontested bits out of the way. live well, vagrant signature.asc Description: PGP signature
Re: Providing (armhf) u-boot images together with d-i images?
On Wed, 2015-01-07 at 10:41 -0800, Vagrant Cascadian wrote: On 2015-01-07, Ian Campbell wrote: And therefore aren't they more usefully built along with that iso? Otherwise how do you know how big to make the partition to contain the iso at d-i build time given the varied sizes of .iso and sd-card you can buy? It would also be nice to have media with the .iso file built-in, but I don't think a requirement for it to be useful without that. Having a second external media isn't very common on the sorts of device we are talking about, is it? I definitely see the case for moving some of the code into debian-cd, or another utility. I've considered making such a utility and shipping it in u-boot-tools, but didn't get around to it for jessie. The sd-card offsets in this patchset duplicate information in the various u-boot* README.Debian files, and it would make sense to move that into a script. This script could also generate SD images with a vmlinuz, initrd, bootscript, dtb, .iso, etc. and would be useful outside the context of debian-installer. Then, if debian-installer, debian-cd, or some other utility wanted to use it, then they could depend on u-boot-tools... That sounds pretty sensible. Ian. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1420656404.11796.33.ca...@debian.org
Re: Providing (armhf) u-boot images together with d-i images?
On Fri, 2015-01-02 at 08:59 -0800, Vagrant Cascadian wrote: On 2015-01-02, Ian Campbell wrote: On Tue, 2014-12-30 at 13:42 -0800, Vagrant Cascadian wrote: On 2014-12-30, Ian Campbell wrote: I think the difference is one is a set of netboot images, and the other is a set of hd-media images. But what is the difference between these two things in this context? Aren't they functionally identical from the users perspective? Differnt initrd with different modules, and defaults to loading a different set of udebs. The hd-media scans for .iso files, the netboot initrd requires to download remaining udebs using network... Technically, both images could be made to do either based on bootprompt options or something, but that probably would require rewriting a bit more of d-i. [...] They're both typically used with sd-card, yes. But they differ in how they load the remaining portions of the installer, and have different modules and udebs in the initrds appropriate to the install media. Hopefully that's clear now? :) Much, thanks. But I still have a question about the hd-media sd-card images -- aren't they only useful in concert with something which adds the .iso etc to the image too? And therefore aren't they more usefully built along with that iso? Otherwise how do you know how big to make the partition to contain the iso at d-i build time given the varied sizes of .iso and sd-card you can buy? I think I'm probably just being dense here... Ian. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1420653663.11796.15.ca...@debian.org
