Bug#773991: flash-kernel: Fails when mtdblock kernel module isn't loaded

[Ian Campbell]

On Fri, 2015-01-02 at 11:09 +0100, Uwe Kleine-König wrote:
> Hello Ian,
> 
> > Uwe, any chance you could try this please:
> >
> > diff --git a/functions b/functions
> > index d45a4e6..a7ff6de 100644
> > --- a/functions
> > +++ b/functions
> > @@ -41,7 +41,11 @@ error() {
> >   mtdblock() {
> > local mtdname="$1"
> >
> > -   sed -rn "s,^mtd([^:]*).*\"$mtdname\"\$,/dev/mtdblock\\1,p" "$PROC_MTD"
> > +   local dev=`sed -rn "s,^mtd([^:]*).*\"$mtdname\"\$,/dev/mtdblock\\1,p" 
> > "$PROC_MTD"`
> > +
> > +   modprobe -q mtdblock && udevadm settle --exit-if-exists=$dev || :
> > +
> > +   echo $dev
> I would have added the modprobe call only if the device doesn't exist, 
> but I guess that's only cosmetic.

modprobe will silently do nothing if the module is already loaded or is
builtin so not checking is fine plus is simpler. There's also a benign
TOCTOU race with checking for the device first (from something else
modprobing in parallel).

> I just installed flash-kernel 3.30 and as expected this one works fine.

Thanks.

> Sorry I didn't come around to test this earlier, I was AFK most of the 
> time around Christmas/new year. Thanks for your work on this bug.

No problem.

Ian.


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1420193666.2030.44.ca...@debian.org

Bug#773991: flash-kernel: Fails when mtdblock kernel module isn't loaded

[Uwe Kleine-König]

Hello Ian,


Uwe, any chance you could try this please:

diff --git a/functions b/functions
index d45a4e6..a7ff6de 100644
--- a/functions
+++ b/functions
@@ -41,7 +41,11 @@ error() {
  mtdblock() {
local mtdname="$1"

-   sed -rn "s,^mtd([^:]*).*\"$mtdname\"\$,/dev/mtdblock\\1,p" "$PROC_MTD"
+   local dev=`sed -rn "s,^mtd([^:]*).*\"$mtdname\"\$,/dev/mtdblock\\1,p" 
"$PROC_MTD"`
+
+   modprobe -q mtdblock && udevadm settle --exit-if-exists=$dev || :
+
+   echo $dev
I would have added the modprobe call only if the device doesn't exist, 
but I guess that's only cosmetic.


I just installed flash-kernel 3.30 and as expected this one works fine.

Sorry I didn't come around to test this earlier, I was AFK most of the 
time around Christmas/new year. Thanks for your work on this bug.


Best regards
Uwe


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54a66e57.8000...@kleine-koenig.org

Re: Providing (armhf) u-boot images together with d-i images?

[Ian Campbell]

On Tue, 2014-12-30 at 13:42 -0800, Vagrant Cascadian wrote:
> On 2014-12-30, Ian Campbell wrote:

> 
> > 0004-Add-SD-card-image-build-support-for-hd-media-builds-.patch
> ...
> > It seems to be creating a copy of dtbs again, please lets try
> > and keep it to one set of these files in the top level
> > component.
> 
> Well, all the dtb files need to be on the concatenateable images so that
> simply dd'ing the right u-boot files onto the card will be able to
> boot. If the image was only made for a specific system, then it would be
> possible to only include the relevent dtb files.

I thought these were being copied into the output dir, rather than (or
as well as) being encapsulated into the image, doing the latter is fine.
Sounds like I misread the patch and it is infact only doing the latter.
>  
> 
> > 0005-Add-SD-card-image-and-tftpboot-tarball-build-support.patch
> >
> > What is this providing? Is it a mini.iso like netboot sd image?
> 
> I think it is basically like the mini.iso on i386/amd64, yes.
> 
> 
> > I'm not sure how this is different from what the previous
> > patches introduced.
> 
> 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?


> > 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?
> 
> Boot scripts allow the use of ${fdtfile}. As far as I understand, the
> pxelinux.cfg syntax unfortunately lacks the ability to use u-boot
> variables, and thus requires a different pxelinux.cfg for each system
> that uses a different .dtb. Which doesn't seem particularly useful for
> a single config for network booting...

pxelinux.cfg stanzas can include an "fdtdir" directory which is a path
which u-boot will search for ${fdtfile} under.

This isn't terribly well documented, but
http://patchwork.ozlabs.org/patch/423507/ improves things a lot.

Speaking of which, does the extlinux.conf stuff (which also supports
fdtdir) help with the multiple images problem at all?

extlinux.conf (and pxelinux.conf) also has the advantage over boot.scr
that it can offer multiple options (graphical vs text etc etc).

> I also think more systems support booting boot scripts than u-boot's
> "PXE" emulation at this point.

That's true.

Going forward we should try and make it our default option though I
think -- it was basically put together this way by the Fedora guys to
support exactly this sort of scenario.

> 
> > I suppose my main overall concern is that this seems to be providing the
> > same thing 3 or 4 times and I'm not sure what the difference between
> > each of those things is (or perhaps as likely I've misunderstood what is
> > going on somewhere along the line). I was already concerned about the
> > proliferation of images which taking this approach was implying in
> > general and adding a multiplier to that just makes me more
> > uncomfortable.
> 
> If I'm reading it correctly(perhaps partly based on earlier descriptions
> of the goal), there are several images produced:
> 
> 1 u-boot only for each supported platform
> 
> 2 hd-media full with u-boot + kernel + initrd + dtbs + bootscript for
>   each platform
> 
> 3 hd-media concatenateable with kernel + initrd + dtbs + bootscript
> 
> 4 netboot full with u-boot + kernel + initrd + dtbs + bootscript for
>   each platform (like mini.iso)
> 
> 5 netboot concatenateable with kernel + initrd + dtbs + bootscript
> 
> 6 netboot boot script for use with TFTP

(I've switched your bullets to numbers for ease of reference).

Are 2+4 and 3+5 not essentially the same things with different names (on
x86 the distinction is iso image vs a f/s image, but on ARM both are
sd-card images).

> 
> The netboot/hd-media without u-boot are meant to be concatenated
> together with the appropriate u-boot only images... so yes, there is
> significant overlap between the image types.
> 
> The full images are obviously easier for the users to use, as it
> requires writing a single image, but obviously proliferate the number of
> images for each new supported platform.
> 
> The concatenateable images obviously save a lot of space, at the expense
> of the user having to do additional steps and more complicated
> documentation (and might be difficult on non-unix-like platforms?).
> 
> It probably doesn't make sense to ship both the concatenateable and full
> images.  I think Karsten wanted to enable both so that they could be
> tested in the daily images, and then later pick which would ship with
> Jessie?

I'm not so much worried about concatenatable vs non as netboot vs
hd-media, but perhaps I just haven't grokked the difference.

Ian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubsc

Re: Providing (armhf) u-boot images together with d-i images?

[Ian Campbell]

On Wed, 2014-12-31 at 01:59 +0100, Karsten Merker wrote:
> > 0001-Add-boot-arm-u-boot-image-config.patch
> > 
> > Seems fine.
> > 
> > 0002-Provide-u-boot-binaries-for-armhf-systems-without-u-.patch
> 
> > I think this isn't actually publishing the u-boot binaries, but
> > rather sd-card images with the u-boot inlined, is that right? Is
> > there any use in shipping the raw binaries too?
> 
> It provides both

Sorry, I must have misread.

> > 0003-Add-utils-gen-hd-image.patch
> > 
> > I didn't review in detail, but perhaps the functionality of
> > patch 0002 could be folded in? TBH I'm not sure what the
> > distinction is between what 0002 does and what this script would
> > produce (except I can see the script clearly has more
> > functionality)
> 
> It depends :-).
> 
> gen-hd-image can provide different types of images - full images
> (SD card image including partition table, u-boot, kernel, initrd
> and dtbs) and concatenateable images, which is effectively a
> full image split up into a device-specific part (containing the
> partition table and u-boot) and a device-independent part
> (containing kernel, initrd and dtbs).
> 
> If one decides to build concatenateable images, the
> device-specific part is mostly the same as the ready-to-copy SD
> card image generated by patch 2, with the difference that it
> contains a filled partition table with a predefined geometry and
> medium size.
> 
> My original idea was to build u-boot-only images from patch 2 for
> people who want to install by TFTP or from USB-Stick using the
> existing hd-media tarball.  This was the first thing I
> implemented.  Vagrant proposed also building full images (u-boot,
> kernel, initrd and dtbs) similar to the images we build for
> i386/amd64, so I implemented that.  As full images need a bit of
> space, the idea of providing concatenateable images instead of
> full images came up, but doing that is dependent on solving the
> "one boot script for all platforms" issue, for which we do not
> yet have a proper solution, therefore I implemented that as an
> option for testing this approach.

Does using the extlinux.conf stuff (mentioned in my reply to Vagrant)
help here?

> > 0004-Add-SD-card-image-build-support-for-hd-media-builds-.patch
> > 
> > I don't think we need all of (.gz|.bz2|.xz) (like the README
> > suggests, although it's not clear these are all actually
> > present). Just one would do IMHO.
> 
> Only the gzipped variant is actually built, the README just
> covers the possible options (when calling gen-hd-image with
> -z/-j/-J).

This README is installed in the output directory, I think? IMHO it
should document only the compression type actually used in that
directory and we should provide at most one version of each file (either
compressed or not) using a single consistent compression algorithm for
all such files.

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.

>  
> > It seems to be creating a copy of dtbs again, please lets try
> > and keep it to one set of these files in the top level
> > component.
> 
> The dtbs are only inside the generated images, they are not
> copied elsewhere as files.

My mistake, I thought they were ending up unpacked in the output too.

>   Having all of them inside the image
> is a necessity if we want to have the option of using
> concatenateable builds as in this case they are in the
> device-independent part. The size of the dtbs inside the
> image is less than 900kB, so I do not think that is much of
> an issue size-wise.

Agreed.

> 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.

> > 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 thin

Bug#418519: Reason for having raw disk as physical volume

[Vincas Dargis]

Hello,

I can tell example where having raw disk as PV is handy: using hardware
RAID controllers, such as Areca ones.

Raid controllers allows you to add new disks to existing raid array. For
example, if you have Raid 10 using four 1TB disks, you can add two more
disks and increase capacity from 2TB to 3TB.

After raid *online* reinitialization, one can increase volume size inside
that raid array, and system now can see that /dev/sda is incresed to 3TB,
also without downtime (simply after rescanning SCSI).

Now, if you have LVM PV inside partition, you first have to resize
partition first, which will mean downtime and possibly disaster on human
error while fiddling with partitioning tools.

Meanwhile, if PV would be a physical disk, one could simply use pvresize...

Re: Bug#774358: libxml2: CVE-2014-3660 patch makes installation-guide FTBFS

[Cyril Brulebois]

Samuel Thibault  (2015-01-01):
> Source: libxml2
> Version: 2.8.0+dfsg1-7+wheezy2
> Severity: serious
> Justification: makes other package FTBFS
> 
> Hello,
> 
> The cve-2014-3660.patch patch makes installation-guide FTBFS: 
> 
> Entity: line 2: parser error : Detected an entity reference loop
>  url="&downloadable-file;images/orion5x/network-console/buffalo/kuroboxpro
>^
> /tmp/manual/en/install-methods/download/arm.xml:40: parser error : Detected 
> an entity reference loop
>   ^
> 
> while there is actually no reference loop there.
> 
> 
> It seems cve-2014-3660.patch is assuming that git commit cff2546 is
> applied: notably it copies this code as it is:
> 
> +   ent->checked = (ctxt->nbentities - oldnbent + 1) * 2;
> 
> but in libxml2 2.8.0, it was still
> 
>ent->checked = ctxt->nbentities - oldnbent + 1;
> 
> and other parts of the code assume that too.  The attached patch fixes
> this confusion.

Many thanks for the investigation and the bug report…

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Providing (armhf) u-boot images together with d-i images?

[Cyril Brulebois]

Karsten Merker  (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.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Providing (armhf) u-boot images together with d-i images?

[Vagrant Cascadian]

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.


> pxelinux.cfg stanzas can include an "fdtdir" directory which is a path
> which u-boot will search for ${fdtfile} under.
>
> This isn't terribly well documented, but
> http://patchwork.ozlabs.org/patch/423507/ improves things a lot.

Thats really helpful, thanks!


> Speaking of which, does the extlinux.conf stuff (which also supports
> fdtdir) help with the multiple images problem at all?
...
> extlinux.conf (and pxelinux.conf) also has the advantage over boot.scr
> that it can offer multiple options (graphical vs text etc etc).

I don't think so, as netboot/hd-media are different images entirely. I
guess you could conceptually make one image with both initrds, and you
could use the menu support to select between the initrds... not sure if
that's worth doing at the moment.


>> I also think more systems support booting boot scripts than u-boot's
>> "PXE" emulation at this point.
>
> That's true.
>
> Going forward we should try and make it our default option though I
> think -- it was basically put together this way by the Fedora guys to
> support exactly this sort of scenario.

Seems reasonable. I'll add it to the increasing list of features I want
to get into u-boot for Jessie+1...


>> 1 u-boot only for each supported platform
>> 
>> 2 hd-media full with u-boot + kernel + initrd + dtbs + bootscript for
>>   each platform
>> 
>> 3 hd-media concatenateable with kernel + initrd + dtbs + bootscript
>> 
>> 4 netboot full with u-boot + kernel + initrd + dtbs + bootscript for
>>   each platform (like mini.iso)
>> 
>> 5 netboot concatenateable with kernel + initrd + dtbs + bootscript
>> 
>> 6 netboot boot script for use with TFTP
>
> (I've switched your bullets to numbers for ease of reference).
>
> Are 2+4 and 3+5 not essentially the same things with different names (on
> x86 the distinction is iso image vs a f/s image, but on ARM both are
> sd-card images).

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? :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#418519: Reason for having raw disk as physical volume

[Geert Stappers]

When the only disk is "completely LVM",
then boot loaders should also have support for it.

When the computer is "Only LVM" also.


"workaround": use an additional  dedicated boot disk[1]



Groeten
Geert Stappers

Note
[1] something that bootROM ( "BIOS" ) supports


signature.asc
Description: Digital signature

Bug#774466: choose-mirror: references cdn.debian.net, which is deprecated

[Paul Wise]

Source: choose-mirror
Severity: important

cdn.debian.net is in the process of being deprecated, orphaned and
transitioned to http.debian.net, please remove it from the mirrors list.
This should be fixed in both wheezy and jessie d-i.

https://lists.debian.org/cag2rkxmdbll-vsfw6deu4p0nwt7qqor3pxvqdu-mwrm1j-6...@mail.gmail.com

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



signature.asc
Description: This is a digitally signed message part

Bug#418519: Reason for having raw disk as physical volume

[Vincas Dargis]

2015.01.02 22:13, Geert Stappers wrote:

"workaround": use an additional  dedicated boot disk[1]


With HW Raid, it's exactly what we intended to do: create very small volume (for Linux point of view it's just /dev/sda) 
to be as "boot disk", containing only boot loader (and maybe /boot), which should not be ever resized or snapshoted or 
whatever, no need for LVM.


Second volume (/dev/sdb) would be raw PV containing "/" and other LVM volumes. But I can't implement it simply by using 
partman.



--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54a79ebe.2050...@gmail.com