Bug#799480: grub-xen-host: XEN domU crash when PV grub chainloads 32-bit domU grub
On Sun, 2015-09-20 at 20:15 +0200, Andreas Sundstrom wrote: > On 2015-09-20 18:51, Ian Campbell wrote: > > On Sat, 2015-09-19 at 18:49 +0200, Andreas Sundstrom wrote: > > > Package: grub-xen-host > > > Version: 2.02~beta2-22 > > > Severity: important > > > > > > Dear Maintainer, > > > > > > Using 64-bit dom0 and 32-bit domU PV (para-virtualized) grub > > > sometimes > > > fail when chainloading the domU's grub. 64-bit domU seem to work 100% > > > of the time. > > Which grub are you starting with from dom0? > > > > If you want to boot a 32-bit guest (which includes chainloading a 32 > > -bit grub) then you must start with the 32-bit grub-i386-xen.bin grub > > binary to create a 32-bit guest. > > > > kexecing from 64-bit to 32-bit is not possible in the general case. In > > fact I thought it was _impossible_ in all cases and would have ruled it > > out as something you might be doing, except some of these registers > > look like 64-bit values: > > As you say it has not been possible at any time to use 64-bit grub from > dom0 and then load either 32-bit grub or linux kernel from domU. > > I am using /usr/lib/grub-xen/grub-i386-xen.bin when I start my i386 > domU's OK good (well, bad, because now I have no idea what is going wrong...) > Thanks for your great blog entry about this by the way: > https://blog.xenproject.org/2015/01/07/using-grub-2-as-a-bootloader-for-x > en-pv-guests/ > I have used it to get a better understanding of the whole process. > > > (XEN) rax: rbx: rcx: > > > > > (XEN) rdx: rsi: 00499000 rdi: > > > 0080 > > > (XEN) rbp: 000a rsp: 005a5ff0 r8: > > > > > > (XEN) r9: r10: 83023e9b9000 r11: > > > 83023e9b9000 > > > (XEN) r12: 033f3d335bfb r13: 82d080300800 r14: > > > 82d0802ea940 > > > (XEN) r15: 83005e819000 cr0: 8005003b cr4: > > > 000506f0 > > > (XEN) cr3: 000200b7a000 cr2: > Well I don't know but I guess the XEN hypervisor is always running in > 64-bit mode yes? > I suppose that maybe even if the domU is 32-bit any errors showing up in > "xl dmesg" > reflects the mode that the hypervisor is run in? I think it's supposed to reflect the mode which the processor is in at the time. I trimmed the quotes but there was a line in the dump which said: (XEN) RFLAGS: 0246 EM: 1 CONTEXT: pv guest Suggesting that this was guest context (this string doesn't distinguish 32- from 64-bit). Actually, I just spotted: (XEN) domain_crash_sync called from entry.S: fault at 82d08021feb0 compat_create_bounce_frame+0xc6/0xde where compat == 32-bit, so that bit is correct. So I think the large register values are a red-herring. I think it would be worth reporting this to upstream (both Xen and Grub), would you mind doing so? Ian.
Bug#799480: grub-xen-host: XEN domU crash when PV grub chainloads 32-bit domU grub
On Sat, 2015-09-19 at 18:49 +0200, Andreas Sundstrom wrote: > Package: grub-xen-host > Version: 2.02~beta2-22 > Severity: important > > Dear Maintainer, > > Using 64-bit dom0 and 32-bit domU PV (para-virtualized) grub sometimes > fail when chainloading the domU's grub. 64-bit domU seem to work 100% > of the time. Which grub are you starting with from dom0? If you want to boot a 32-bit guest (which includes chainloading a 32 -bit grub) then you must start with the 32-bit grub-i386-xen.bin grub binary to create a 32-bit guest. kexecing from 64-bit to 32-bit is not possible in the general case. In fact I thought it was _impossible_ in all cases and would have ruled it out as something you might be doing, except some of these registers look like 64-bit values: > (XEN) rax: rbx: rcx: > (XEN) rdx: rsi: 00499000 rdi: 0080 > (XEN) rbp: 000a rsp: 005a5ff0 r8: > (XEN) r9: r10: 83023e9b9000 r11: 83023e9b9000 > (XEN) r12: 033f3d335bfb r13: 82d080300800 r14: 82d0802ea940 > (XEN) r15: 83005e819000 cr0: 8005003b cr4: 000506f0 > (XEN) cr3: 000200b7a000 cr2: Ian.
Bug#771465: Please add UEFI boot files to i386 and amd64 netboot images
Control: tags -1 -patch On Sun, 2015-09-13 at 11:45 +0200, Teemu Ikonen wrote: > I recently had to reinstall jessie to my MacBook2,1 and found that the > Debian 8.2 i386 netinst image now works out of the box even with the > strange EFI implementation in this box. Many thanks to Steve McIntyre > for making this work, yay! > > In general I like to do my installations with the netboot images, Do you mean mini.iso as in: http://ftp.uk.debian.org/debian/dists/jessie/main/installer-amd64/current/images/netboot/mini.iso or something else? > since the 28 M image is sure to fit any USB stick which happens to be > at hand. It would be super-duper if the 32-bit and 64-bit EFI boot > files could also be added to these images, so that they too would > start to work like magic. For old intel MacBooks the EFI boot file > needs to be in the removable path, i.e. efi/boot/bootia32.efi > > [I added the patch tag because the fix to this bug is known and > trivial, no patch attached though] No patch, so removed, whether the fix is known or trivial in principal an actual patch which actually does the required thing is what needs to be produced. I'm not actually 100% clear what you are asking for. Given the above mini.iso I have in the ESP: $ isoinfo -x /boot/grub/efi.img -RJ -i mini.iso-sid > efi.img $ mdir -i efi.img -/ -b ::/efi/ ::/efi/boot/ ::/efi/boot/bootx64.efi and $ isoinfo -f -RJ -i mini.iso-sid shows lots of stuff in /boot/grub/x86_64-efi of the main image, all of which I believe is sufficient to boot on a 64-bit EFI system. The i386 version of mini.iso instead has bootia32.efi in the ESP and /boot/grub/i386-efi on the main ISO. So either this isn't working for you or the request you are making is for something else in addition. Ian.
Bug#771465: Please add UEFI boot files to i386 and amd64 netboot images
On Sun, 2015-09-13 at 12:36 +0200, Teemu Ikonen wrote: > On Sun, Sep 13, 2015 at 12:11 PM, Ian Campbell <i...@debian.org> > wrote: > > Do you mean mini.iso as in: > > http://ftp.uk.debian.org/debian/dists/jessie/main/installer-amd64/c > urrent/images/netboot/mini.iso > > or something else? > > Hi Ian, > > Yes, that's the one, although I've tested with the i386 image. > > > I'm not actually 100% clear what you are asking for. Given the > above > > mini.iso I have in the ESP: > > > > $ isoinfo -x /boot/grub/efi.img -RJ -i mini.iso-sid > efi.img > > $ mdir -i efi.img -/ -b > > ::/efi/ > > ::/efi/boot/ > > ::/efi/boot/bootx64.efi > > > > and > > > > $ isoinfo -f -RJ -i mini.iso-sid > > > > shows lots of stuff in /boot/grub/x86_64-efi of the main image, all > of > > which I believe is sufficient to boot on a 64-bit EFI system. > > > > The i386 version of mini.iso instead has bootia32.efi in the ESP > and > > /boot/grub/i386-efi on the main ISO. > > > > So either this isn't working for you or the request you are making > is > > for something else in addition. > > The latest mini.iso netboot image is not booting on my Macbook2,1 but > the official Debian 8.2 netinst image (315 MB) does. > > The USB-sticks I've managed to boot in this machine all have had the > file efi/boot/bootia32.efi on the single partition they've had, > either > a vfat partition prepared by grub-install or a is9660 filesystem > copied from the installer image. That's also the case with the 8.2 > netinst image: > > $ 7z l debian-8.2.0-i386-netinst.iso | grep bootia > 2015-09-06 12:00:44 . 272384 272384 > efi/boot/bootia32.efi > > This file is not present in the netboot mini.iso. It is present in the ESP (efi.img within the iso image), which is pointed to be (AIUI) the El Torito headers in the ISO. Perhaps there are some systems for which this is not sufficient? > The EFI implementation on old intel Macbooks is probably broken in > several ways, but to me it looks like the fix is easy, known, and > takes all of 272384 bytes in the installation image. But you are > right, the patch is not there yet. The fact that it is easy to describe in prose what needs to happen does not mean that it is actually easy to implement I'm afraid. Ian.
Bug#782054: mbsync: New version cannot open Maildir boxes
On Sat, 2015-09-05 at 13:53 +0200, Guillem Jover wrote:
> Hi Ian!
>
> On Fri, 2015-09-04 at 10:38:09 +0100, Ian Campbell wrote:
> > On Tue, 2015-07-28 at 09:21 +0100, Ian Campbell wrote:
> > > I'm suffering from a similar issue to Guillem,
>
> > I had a realisation which might be useful to you as well: The
> trailing "/"
> > on a store:mailbox is (or can be) significant, e.g. the following
> diff
> > against my previous redacted mbsyncrc appears (on first glance) to
> work and
> > to do what I desire:
>
> > The change to Master being the primary thing. This results in the:
> >
> > [Account]
> > |-INBOX
> > |- PATCHES
> > | |- WIP
> > | `- FOO
> > `- Cronspam
> >
> > maildir hierarchy which I noted in Message #75 I'd be happy to
> switch to if
> > necessary.
>
> Right, and thanks for the update, unfortunately that's not a conformant
> Maildir++ layout,
FWIW the disk layout which Evolution displays as above is:
Maildir/{cur,tmp,new} # AKA "INBOX"
Maildir/.PATCHES/{cur,tmp,new}
Maildir/.PATCHES.WIP/{cur,tmp,new}
Maildir/.PATCHES.FOO/{cur,tmp,new}
Maildir/.Cronspam/{cur,tmp,new}
Just mentioning for clarity in case you thought it was:
Maildir/{cur,tmp,new} # AKA "INBOX"
Maildir/PATCHES/{cur,tmp,new}
because I thought the first (with the dots) _was_ compliant Maildir++.
> which is what I'd like to have on my client system to
> match the filesystem layout of my server system.
I can see why you might want that (orthogonally to whether the single .
prefix is valid Maildir++ or not).
> > NB: I'm still tinkering with things, so I'm not 100% sure this is correct,
> > but on first glance it looks so and I'm also not sure if it is applicable
> > to the issue in your context but I hope it turns out to be helpful!
>
> I've not had time to look into this again, but once I do, I guess I'll
> try to prepare a patch, post it here, and if it gets rejected run with
> a local fork. Either that or try to discover how to properly configure
> the program to do what I want, in case it is really possible. :)
Bug#782054: mbsync: New version cannot open Maildir boxes
On Tue, 2015-07-28 at 09:21 +0100, Ian Campbell wrote: > I'm suffering from a similar issue to Guillem, Guillem, I had a realisation which might be useful to you as well: The trailing "/" on a store:mailbox is (or can be) significant, e.g. the following diff against my previous redacted mbsyncrc appears (on first glance) to work and to do what I desire: @@ -8,7 +8,7 @@ Account XXX MaildirStore XXX-local -Path ~/Maildir/.. +Path ~/Maildir/ Inbox ~/Maildir/ #AltMap yes Flatten . @@ -22,9 +22,9 @@ SyncState * Channel XXX-folders -Master :XXX-remote:INBOX/ +Master :XXX-remote:INBOX Slave :XXX-local: -Patterns * !INBOX +Patterns * ! Create Slave Expunge Both SyncState * The change to Master being the primary thing. This results in the: [Account] |-INBOX |- PATCHES | |- WIP | `- FOO `- Cronspam maildir hierarchy which I noted in Message #75 I'd be happy to switch to if necessary. NB: I'm still tinkering with things, so I'm not 100% sure this is correct, but on first glance it looks so and I'm also not sure if it is applicable to the issue in your context but I hope it turns out to be helpful! Cheers, Ian.
Bug#795330: [Pkg-xen-devel] Bug#795330: Suggests noapic but doesn't support it
Control: tag -1 upstream
Jan/Andy & David,
Is there anything we can improve here on either the Xen or kernel side do
you think?
On Thu, 2015-08-13 at 00:59 +0200, Guido Günther wrote:
> Package: xen-hypervisor-4.5-amd64
> Severity: normal
>
> Hi,
> when running xen inside of kvm the hypervisor fails to set up the proper
> IRQ routing and suggests to use noapic.
FTR, it seems to say:
panic("IO-APIC + timer doesn't work! Boot with apic_verbosity=debug "
"and send a report. Then try booting with the 'noapic' option");
Did you also try the first thing it suggested? What was the result?
> If you add this via
>
> GRUB_CMDLINE_XEN_DEFAULT
>
> it will boot futher but then report that noapic isn't supported.
Is this the kernel saying that or Xen? Do you have full boot logs?
I think it is the kernel since I can't find such a message in Xen and
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html says for
the noapic option: "This is not recommended with pvops type kernels."
> So please make Xen not claim to support noapic if it doesn't
I think ultimately this is down to different components being able to
support different things, e.g. Xen's advice might be fine with a FreeBSD
dom0 or some other version of Linux.
> (the issue
> was finally resolved by removeing all virtion devices and doubling the
^virtio ?
> hypervisors RAM so the suggestion was misplaced anyways).
I can see how the virtio thing might make the KVM guest look different to
Xen, but the RAM thing seems orthogonal.
Thanks,
Ian.
Bug#795330: [Xen-devel] [Pkg-xen-devel] Bug#795330: Suggests noapic but doesn't support it
On Fri, 2015-09-04 at 15:04 +0100, David Vrabel wrote:
> On 04/09/15 14:38, Ian Campbell wrote:
> > Control: tag -1 upstream
> >
> > Jan/Andy & David,
> >
> > Is there anything we can improve here on either the Xen or kernel side
> > do
> > you think?
> >
> > On Thu, 2015-08-13 at 00:59 +0200, Guido Günther wrote:
> > > Package: xen-hypervisor-4.5-amd64
> > > Severity: normal
> > >
> > > Hi,
> > > when running xen inside of kvm the hypervisor fails to set up the
> > > proper
> > > IRQ routing and suggests to use noapic.
> >
> > FTR, it seems to say:
> >
> > panic("IO-APIC + timer doesn't work! Boot with
> > apic_verbosity=debug "
> > "and send a report. Then try booting with the 'noapic'
> > option");
>
> This is the Linux kernel making a recommendation for its command line.
I cut-n-paste that message from xen.git. Although maybe in a file which
originates in Linux.
(So now I realised I don't really know which entity was complaining)
> > Did you also try the first thing it suggested? What was the result?
> >
> > > If you add this via
> > >
> > > GRUB_CMDLINE_XEN_DEFAULT
> > >
> > > it will boot futher but then report that noapic isn't supported.
>
> Don't add Linux command line options to the Xen command line.
>
> David
>
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> http://lists.xen.org/xen-devel
Bug#794071: [Pkg-xen-devel] Bug#794071: "xenconsole: Could not open tty `': No such file or directory" during PV guest boot
On Thu, 2015-07-30 at 09:41 +, Andy Smith wrote: > Package: xen-utils-common > Version: 4.4.1-9+deb8u1 > Severity: normal > > Dear Maintainer, > > When booting a PV guest (xl create -c /etc/xen/foo.conf), immediately > after pygrub has determined which kernel/initramfs it will use, the > following error messages are logged: > > xenconsole: Could not open tty `': No such file or directory > libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console > child [0] exited with error status 2 This sounds a bit like the issue fixed by http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=39ba2989b10b6a1852e253b204eb010f8e7026f1 Are you able to run a new Xen (either 4.5.1~rc1-1 from experimental or an upstream version would do) to confirm? (I've also asked for that commit to be backported upstream, since it is certainly a fix for something even if not this issue) Thanks, Ian. > > The boot does however continue normally including all expected console > output from the guest. The resulting console is perfectly usable once > the guest's login prompt is reached. > > Then, once the console is exited with ctrl-], the terminal settings are > messed up such that no text is echoed and pressing return does not > advance to the next line. Terminal usability can be restored by using > "stty sane" or "reset" at this point. > > Searching the web for the above error messages only reveals people who > say that xenconsoled wasn't running, however in this case xenconsoled > *is* running (and the console does work, both continuing from the "xl > create -c …" and also if connected to with "xl console …"). > > Here is an example guest config: > > name = "debtest1" > memory = 1024 > vif= [ "mac=00:16:5e:00:02:39, ip=192.168.82.225, vifname=v > -debtest1" ] > bootloader = "/usr/lib/xen-default/bin/pygrub" > disk = [ "phy:/dev/vg/debtest1_xvda,xvda,w", >"phy:/dev/vg/debtest1_xvdb,xvdb,w", ] > > The kernel command line that pygrub will extract is: > > linux (kernel )(ramdisk > )(args "root=UUID=bb7a41e3-67f4 > -436a-8a80-07ec26573360 ro console=hvc0") > > however it happens with all my guests regardless of distribution or > version. > > -- System Information: > Debian Release: 8.1 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages xen-utils-common depends on: > ii lsb-base4.1+Debian13+nmu1 > ii python 2.7.9-1 > ii ucf 3.0030 > ii udev215-17+deb8u1 > ii xenstore-utils 4.4.1-9+deb8u1 > > xen-utils-common recommends no packages. > > xen-utils-common suggests no packages. > > -- Configuration Files: > /etc/xen/scripts/vif-route changed [not included] > /etc/xen/xl.conf changed [not included] > > -- no debconf information > > ___ > Pkg-xen-devel mailing list > pkg-xen-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel
Bug#763102: [Pkg-xen-devel] Bug#763102: xen-utils-common: xen-init-list fails to parse xm output -> cannot shutdown domains with service xendomains
Control: tag -1 -moreinfo On Sun, 2015-08-23 at 16:33 +0200, Volker Klasen wrote: > > > > I've updated the feature/bug763102 with the following extra patch: > > With both your patches applied, xen-init-list works. Thanks for confirming. Ian.
Bug#763102: [Pkg-xen-devel] Bug#763102: xen-utils-common: xen-init-list fails to parse xm output - cannot shutdown domains with service xendomains
On Sat, 2015-08-22 at 00:24 +0200, Volker Klasen wrote:
Hi Ian,
you can use the patch I posted in the original report,
Uh, how on earth did I miss it!
there are two
places that need to be fixed. I'm using it since November.
Thanks. Since loads is a classmethod I think the right fix for that
issue is to s/self/cls/ in the body rather than s/cls/self/ in the
declaration.
I've updated the feature/bug763102 with the following extra patch:
@@ -14,7 +14,7 @@ class SXPParser(object):
def loads(cls, input):
data = []
stack = []
-for match in self.tokenizer_re.finditer(input):
+for match in cls.tokenizer_re.finditer(input):
if match.group('open'):
stack.append([])
elif match.group('close'):
Ian.
Bug#770456: [Pkg-xen-devel] Bug#770456: Bug#770456: Please start a qemu process in domain 0.
On Mon, 01 Dec 2014 13:02:28 + Ian Campbell i...@debian.org wrote: On Mon, 2014-12-01 at 13:47 +0100, Stefan Bader wrote: Anyway, your diff seems to only add some code to xenstored_start, I was expecting a change to qemu_start -- did you find that code was OK in the end? Or did you end up switching to --exec? Errm, that part was the addition I inlined. The updated change was the full diff between current init script and your changes with the updated qemu_stop_real. And that might have gone missing in the bug tracker at least. It hopefully has survived in the cc that went directly... hopefully... It was even in the copy which went via the BTS, I just missed it, sorry! I've rebased the feature branch (feature/bug770456) and included Stefan's fixes to --exec etc. I didn't include the start-stop-daemon exec rename workaround. Firstly because this is fixed in the kernel in Jessie and secondly because if we are to workaround the buggy kernels then I think we should be doing that everywhere (i.e. in start-stop-daemon) rather than in each individual initscript. Ian.
Bug#795558: qcontrol: lcd command results in Command not found
On Sat, 2015-08-15 at 11:22 +0200, Michele Cane wrote:
Package: qcontrol
Version: 0.5.4-5
Severity: normal
Dear Maintainer,
Thanks for the report.
starting with kernel 4.0 when I issue the command sudo lcd-backlight off it
results in a Command not found.
I tried other qcontrol commnands such as shortbuzz and usbled and they work.
If I revert to kernel 3.16 the command works.
This suggests that the a125 module is not being loaded.
In your qcontrol.conf there should be a:
gpio_select(45, {
function () register(a125, /dev/ttyS0) end,
nil,
nil})
Which registers the module if gpio 45 is in the appropriate state.
Unfortunately I've gone away and left my QNAP box at home turned off :-/
So a few questions:
Are there any messages in daemon.log relating to qcontrol and startup?
Do you have a /dev/ttyS0 device?
Do you have /sys/class/gpio/gpio45/value or the
/sys/class/gpio/gpio45 directory generally? If not then does echo 45
/sys/class/gpio/export cause those to appear?
If you replace the whole gpio_select block with just the:
register(a125, /dev/ttyS0)
bit (i.e. register it unconditionally) then does it work? This would
indicate that gpio_select has been broken somehow.
It's possible that what we have here is a race with the device nodes
being created vs qcontrol starting. This was supposed to have been
worked around by #781886 though.
Ian.
Bug#787193: xen-utils-common: xen-init-list crashes with TypeError, renders reboots unfeasible after upgrade from wheezy to jessie
This bug was already reported as #763102 and was brushed off because maintainer says it implicates xend which is not there in 4.4 anymore. Quoting the explanation sent when closing #763102: If you think a bug has been associated with xend in error please check if it still reproduces with the packages in Jessie (currently 4.4.1-3) and reopen. I'm sorry you felt this was being brushed off but it explicitly acknowledge the possibility of mistakes and explained what to do in such cases. Ian.
Bug#618576: xen-3.2-1: VNC display over HVM XEN 3/Lenny AMD64, displays a blank screen when Debian-Installer Squeeze AMD64 is running on it
Control: tags -1 +moreinfo Hello, Sorry that this bug report seemed to fall through the cracks. Are you still able to reproduce this on a modern dom0? Ian.
Bug#554805: xen-utils-3.2-1: ioemu routed networking on HVM guests fails
Control: tags -1 +upstream On Fri, 06 Nov 2009 17:53:12 +0100 Cyrille =?ISO-8859-1?Q?Ch=E9p=E9lov?= cyrille.chepe...@keyconsulting.fr wrote: Sorry that this bug slipped through the cracks. The reason why this happened is that the scripts/qemu-dm script *assumes* only bridging is ever used, and the scripts/vif-routing *assumes* only netfront is ever used. Here we have routing and ioemu, which causes the failure described above. FYI this has changed somewhat in more recent Xen and vif-route is used for both the PV and EMU interfaces. However there are still some issues with this config as discussed in http://lists.xen.org/archives/html/xen-users/2015-08/msg3.html In your case (only EMU no PV at all) some of the gotchas described there ought to be avoided and the suggested change may well work. Ian.
Bug#796370: xen: Include a reportbug control file to redirect bugs to src:xen
Source: xen
Version: 4.5.1~rc1-1
Severity: wishlist
Tags: patch
http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2015-June/006206.html
suggests that we are prone to loosing bugs as the package versions change
since they include the Xen version.
To avoid this we can ship a reportbug control file to redirect those bugs to
src:xen, which the attached patch does.
I went with three separate debian/templates/FOO.bug dirs for each of the
packages which contain the version number in the name, even though the contents
is currently the same, in anticipation of that they may gain some differences
in the future. I could of course trivially mrge those three directories into
one if you prefer.
I've also done git flow publish to populate the feature/reportbug branch in
git. Note that this also contains two other changes which I needed to be able
to build test against current sid:
- Added upstream patch 3f82ea62826d4eb06002d8dba475bafcc454b845 xen: common:
Use unbounded array for symbols_offset for FTBFS with gcc-5
- Update to linux-support-4.1.0-1
You may or may not want those, but I trust you can cherry-pick as you want.
Cheers,
Ian.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500,
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
From 084b7cf56dd2ccfbf1c04796689222dac9d58ac6 Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@debian.org
Date: Fri, 21 Aug 2015 14:54:13 +0100
Subject: [PATCH] Include a reportbug control file to redirect bugs to src:xen
---
debian/changelog| 8
debian/rules.real | 6 +-
debian/templates/libxen.bug/control | 1 +
debian/templates/xen-hypervisor.bug/control | 1 +
debian/templates/xen-utils.bug/control | 1 +
5 files changed, 16 insertions(+), 1 deletion(-)
create mode 100644 debian/templates/libxen.bug/control
create mode 100644 debian/templates/xen-hypervisor.bug/control
create mode 100644 debian/templates/xen-utils.bug/control
diff --git a/debian/changelog b/debian/changelog
index 70be498..59c261d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+xen (4.5.1~rc1-2) UNRELEASED; urgency=medium
+
+ [ Ian Campbell ]
+ * Include a reportbug control file to redirect bugs to src:xen for
+packages which contain the Xen version in the name.
+
+ -- Ian Campbell i...@debian.org Fri, 21 Aug 2015 14:53:26 +0100
+
xen (4.5.1~rc1-1) experimental; urgency=medium
[ Ian Campbell ]
diff --git a/debian/rules.real b/debian/rules.real
index 7ff231c..bab109a 100644
--- a/debian/rules.real
+++ b/debian/rules.real
@@ -152,6 +152,7 @@ install-hypervisor_$(ARCH)_$(FLAVOUR): $(STAMPS_DIR)/build-hypervisor_$(ARCH)_$(
dh_testroot
dh_prep
dh_installdirs boot
+ dh_install debian/templates/xen-hypervisor.bug/* usr/share/bug/$(PACKAGE_NAME)
cp $(DIR)/xen/xen$(IMAGE_SUFFIX) debian/$(PACKAGE_NAME)/boot/xen-$(VERSION)-$(FLAVOUR)$(IMAGE_SUFFIX)
ifeq ($(ARCH),amd64)
cp $(DIR)/xen/xen.efi debian/$(PACKAGE_NAME)/boot/xen-$(VERSION)-$(FLAVOUR).efi
@@ -159,12 +160,14 @@ endif
+$(MAKE_SELF) install-base
install-libxen_$(ARCH): DIR = $(BUILD_DIR)/install-utils_$(ARCH)
-install-libxen_$(ARCH): DH_OPTIONS = -plibxen-$(VERSION)
+install-libxen_$(ARCH): PACKAGE_NAME = libxen-$(VERSION)
+install-libxen_$(ARCH): DH_OPTIONS = -p$(PACKAGE_NAME)
install-libxen_$(ARCH): $(STAMPS_DIR)/install-utils_$(ARCH) install-libxenstore_$(ARCH)
dh_testdir
dh_testroot
dh_prep
dh_install --sourcedir=$(DIR) usr/lib/*/lib*-$(VERSION).so
+ dh_install debian/templates/libxen.bug/* usr/share/bug/$(PACKAGE_NAME)
dh_strip
dh_makeshlibs -V
dh_shlibdeps
@@ -207,6 +210,7 @@ install-utils_$(ARCH): $(STAMPS_DIR)/install-utils_$(ARCH) install-libxen_$(ARCH
install -D -m644 debian/xen-utils.NEWS $(PACKAGE_DIR)/usr/share/doc/$(PACKAGE_NAME)/NEWS
install -D -m644 debian/xen-utils.README.Debian $(PACKAGE_DIR)/usr/share/doc/$(PACKAGE_NAME)/README.Debian
dh_install --sourcedir=$(DIR) usr/lib/xen-$(VERSION)
+ dh_install debian/templates/xen-utils.bug/* usr/share/bug/$(PACKAGE_NAME)
dh_lintian
( echo -n misc:Built-Using=; dpkg-query -f='$${source:Package} (= $${source:Version}), ' -W ipxe-qemu seabios; echo ) debian/$(PACKAGE_NAME).substvars
dh_python2 -V$(shell pyversions -rv) /usr/lib/xen-$(VERSION)
diff --git a/debian/templates/libxen.bug/control b/debian/templates/libxen.bug/control
new file mode 100644
index 000..3e21b39
--- /dev/null
+++ b/debian/templates/libxen.bug/control
@@ -0,0 +1 @@
+Submit-As: src:xen
diff --git a/debian/templates/xen-hypervisor.bug/control b/debian/templates/xen-hypervisor.bug/control
new file mode 100644
index 000..3e21b39
--- /dev/null
+++ b/debian/templates
Bug#507020: xen-utils-3.2-1: Pygrub says Error: Boot loader didn't return any data!
Control: tags -1 +moreinfo Sorry this bug seems to have fallen through the cracks. On Thu, 27 Nov 2008 09:34:19 +0100 Paul van der Vlis p...@vandervlis.nl wrote: You may find bringing this up on xen-devel useful. Did you bring this up on the upstream list? Does this bug still occur for you? Thanks, Ian.
Bug#503046: xen-utils-3.2-1: inadequate error handling for the case of a failure to use a loopback device
Control: tags -1 +moreinfo On Wed, 22 Oct 2008 14:20:10 +1100 Russell Coker russ...@coker.com.au wrote: Thanks for the report, sorry that it seems to have slipped through the cracks. If there is a problem that prevents correctly allocating the block device (see the above URL for a description of how I encountered it when using a CentOS kernel) then it will not free the loop device. When the domain is destroyed with xm destroy it will leave the loopback device, if you run that a few times (EG you have a script to restart DomU's on error) then you run out of loopback devices for the system. The error handling code needs to deal with this case. Looking at the current upstream code it seems things have changed since this report was filed, and I know that xl is a bit better about handling of when the hotplug scripts are run on teardown etc. So I have a reasonably high hope that this issue has gone away, can you confirm? Thanks, Ian.
Bug#500047: xen-utils-3.0.3-1: domU reboot fails when using DRBD as vbd
Control: tags -1 +moreinfo On Wed, 24 Sep 2008 17:19:08 +0200 Valentin Vidic vvi...@carnet.hr wrote: Package: xen-utils-3.0.3-1 Version: 3.0.3-0-4 Severity: normal Rebooting from inside domU hangs in initrd: Begin: Waiting for root file system... ... Root file system is not available because underlying DRBD device got deactivated during reboot: Sorry this bug seems to have fallen through the cracks. I've heard of people using drdb fairly recently so I think there is a g ood chance that this issue has been fixed in either recent Xen or DRDB packages (I'm not sure where block-drdb comes from these days). Please can you confirm whether or not you are still seeing this issue, thanks. Ian.
Bug#763102: xen-utils-common: xen-init-list fails to parse xm output - cannot shutdown domains with service xendomains
Control: tag -1 +moreinfo
Hello,
It seems this was incorrectly closed as xend only since this code can
be used on upgrade (as part of rebooting from xend into a new system).
I don't have any systems to test but I think the fix is trivially the
following:
@@ -51,7 +51,7 @@ class DataJSON(Data):
class DataSXP(Data):
def __init__(self, p):
-s = SXPParser()(p)
+s = SXPParser.loads(p)
self.data = d = {}
for i in s:
if i and i[0] == 'domain':
Please can you try making that change to /usr/lib/xen-common/bin/xen
-init-list and report whether or not it works?
I've also published the fix to the feature/bug763102 branch of the pkg
-xen git repository.
Thanks,
Ian
Bug#785132: [Pkg-xen-devel] Bug#785132: Bug#785132: No screen refresh on Windows 8.1 with xen-hypervisor-4.5-amd64
On Fri, 2015-05-15 at 17:43 +0200, zer0 divide wrote: Hi, Here the packages related to xen installed on my system : This was badly whitespace mangled, please spare a thought for those trying to read things (especially such large amounts of stuff) and format them clearly, or attach them instead. Qemu packages : ii qemu 1:2.2+dfsg-5exp amd64fast processor emulator [...] ldd /usr/bin/qemu-system-i386 [...] libxenctrl-4.4.so = /usr/lib/x86_64-linux-gnu/libxenctrl-4.4.so (0x7f08010ab000) libxenguest-4.4.so = /usr/lib/x86_64-linux-gnu/libxenguest-4.4.so (0x7f0800e8) This indicates that your qemu was linked against the Xen 4.4 toolstack libraries, which may have lead to the issue you are seeing. This is down to a problem with the way the Xen toolstack libraries behave which currently require rebuilding QEMU for new Xen versions. This is something I am looking to fix upstream. In the meantime the only thing you can try is rebuilding QEMU against the libxen-dev from Xen 4.5 or wait for Xen 4.5 to be uploaded to unstable and for QEMU to be rebuilt against it. Ian.
Bug#764912: xen-utils-common: needs to apply SE Linux labels after creating directories in start script
Control: tag -1 +patch Ages ago I pushed this to a feature/bug764912 branch in the packaging git repo, but apparently I forgot to tag and mention it in the buglog. I've just updated the branch to the current development branch and republished the feature branch. Ian.
Bug#439156: xen-hypervisor-3.0.3-1-amd64: large memory not detected
Control: tags -1 +moreinfo On Wed, 22 Aug 2007 15:09:01 -0400 Robert Buels rm...@cornell.edu wrote: Package: xen-hypervisor-3.0.3-1-amd64 Version: 3.0.3-0-2 Severity: important On a machine with 2 dual-core Opterons and 16GB of memory, only about 3GB is detected by the hypervisor. Hi, It seems this bug fell through the cracks at some point. I think it is very likely that this issue has been fixed at some point. Please can you confirm if you are still seeing it? Cheers, Ian. Transcript: root@thismachine:~# xm dmesg Xen version 3.0.3-1 (Debian 3.0.3-0-2) (ultrot...@debian.org) (gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)) Fri Nov 3 00:21:27 CET 2006 Latest ChangeSet: Tue Oct 17 22:09:52 2006 +0100 (XEN) Command line: /boot/xen-3.0.3-1-amd64.gz (XEN) Physical RAM map: (XEN) - 0009c800 (usable) (XEN) 0010 - bfff (usable) (XEN) System RAM: 3071MB (3145264kB) (XEN) Xen heap: 14MB (14384kB) (XEN) found SMP MP-table at 000ff780 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: RSDP (v002 ACPIAM) @ 0x000f9750 (XEN) ACPI: XSDT (v001 A M I OEMXSDT 0x1624 MSFT 0x0097) @ 0xbfff0100 (XEN) ACPI: FADT (v003 A M I OEMFACP 0x1624 MSFT 0x0097) @ 0xbfff0290 (XEN) ACPI: MADT (v001 A M I OEMAPIC 0x1624 MSFT 0x0097) @ 0xbfff0390 (XEN) ACPI: SPCR (v001 A M I OEMSPCR 0x1624 MSFT 0x0097) @ 0xbfff0420 (XEN) ACPI: SLIT (v001 A M I OEMSLIT 0x1624 MSFT 0x0097) @ 0xbfff04b0 (XEN) ACPI: OEMB (v001 A M I AMI_OEM 0x1624 MSFT 0x0097) @ 0xbfffe040 (XEN) ACPI: HPET (v001 A M I OEMHPET0 0x1624 MSFT 0x0097) @ 0xbfff7400 (XEN) ACPI: IPET (v001 A M I OEMHPET1 0x1624 MSFT 0x0097) @ 0xbfff7440 (XEN) ACPI: SRAT (v001 AMDHAMMER 0x0001 AMD 0x0001) @ 0xbfff7480 (XEN) ACPI: SSDT (v001 A M I POWERNOW 0x0001 AMD 0x0001) @ 0xbfff7590 (XEN) ACPI: DSDT (v001 BOTO_ BOTO_110 0x0110 INTL 0x20051117) @ 0x (XEN) ACPI: Local APIC address 0xfee0 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 15:1 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) (XEN) Processor #1 15:1 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) (XEN) Processor #2 15:1 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) (XEN) Processor #3 15:1 APIC version 16 (XEN) ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 4, version 17, address 0xfec0, GSI 0-23 (XEN) ACPI: IOAPIC (id[0x05] address[0xdccff000] gsi_base[24]) (XEN) IOAPIC[1]: apic_id 5, version 17, address 0xdccff000, GSI 24-47 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) ACPI: IRQ14 used by override. (XEN) ACPI: IRQ15 used by override. (XEN) Enabling APIC mode: Flat. Using 2 I/O APICs (XEN) ACPI: HPET id: 0x10de8201 base: 0xfed0 (XEN) Using ACPI (MADT) for SMP configuration information (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Initializing CPU#0 (XEN) Detected 2400.122 MHz processor. (XEN) CPU0: AMD Flush Filter disabled
Bug#441539: xen-hypervisor-3.0.3-1-amd64: Xen failing to boot with FATAL TRAP error
Control: tags -1 +morienfo On Mon, 10 Sep 2007 11:28:05 +0100 James Ray j@qmul.ac.uk wrote: Package: xen-hypervisor-3.0.3-1-amd64 Version: 3.0.3-0-2 Severity: important about every 1 in 10 boots I am getting the following error: (XEN) (XEN) CPU0 FATAL TRAP 6 (invalid opcode), ERROR_CODE , IN INTERRUPT CONTEXT. (XEN) System shutting down -- need manual reset. (XEN) This seems to happen in the CPU detection stage. It seems this bug fell through the cracks at some point. I think it is very likely that this issue has been fixed at some point. Please can you confirm if you are still seeing it? Cheers, Ian.
Bug#477525: Reason for close
Sorry, used bts close instead of bts done by mistake so didn't get the expected chance to explain why I was closing... I closed this because xend (and hence network-route) was removed from Xen packaging in 4.4.0-1 (and is also gone upstream). Ian.
Bug#399073: xen-hypervisor-3.0.3-1-i386: dom0 crashes with a domU that define more than 6 vdb
Control: tags -1 +moreinfo Hello, On Fri, 17 Nov 2006 14:47:02 +0100 Laurent Corbes laurent.cor...@smartjog.com wrote: Package: xen-hypervisor-3.0.3-1-i386 Version: 3.0.3-0-2 Severity: important When I try to start a domU with more than 6 vdb it crash. I'm sorry, it seems this bug slipped through the cracks at some point. I think it is highly likely that this issue has been fixed in the time since you filed it, but just to check: Are you still seeing this issue with modern Debian/Xen? Ian.
Bug#502845: Three years and counting.
On Thu, 2015-08-20 at 16:13 +0100, Julia Longtin wrote: It has now been three years I have been applying lisa's patch to userspace, and using that. is anyone actually looking at this? Reviewing the bug log it looks to me as if the correct place to be pushing for a fix is upstream. Once it is fixed there I'm sure it will flow into Debian in the normal course of things. Ian.
Bug#796019: dgit sbuild stalls
Package: dgit Version: 1.3 Severity: normal During development (i.e. with an open debian/changelog) then running: dgit --quilt=smash sbuild --dist sid --arch amd64 --no-apt-update --no-apt-upgrade Gets to the sbuild Summary banner and then hangs. The process tree is: $ pstree -ap 9912 dgit,9912 -w /usr/bin/dgit --quilt=smash -wdd sbuild --dist sid --arch amd64 --no-apt-update --no-apt-upgrade └─sbuild,10100 /usr/bin/sbuild -A --dist sid --arch amd64 --no-apt-update --no-apt-upgrade -d UNRELEASED sunxi-tools_1.2-3.dsc └─package log for,10106 $ strace -p 10100 Process 10100 attached wait4(10106, ^CProcess 10100 detached detached ... $ strace -p 10106 Process 10106 attached read(0, ^CProcess 10106 detached detached ... Running just: sbuild --dist sid --arch amd64 --no-apt-update --no-apt-upgrade Is fine. (nb: --no-apt-* make no difference, I just happened to be using them) I think the issue is the trailing -d UNRELEASED which dgit has tacked onto the sbuild command line. If I omit --dist sid from my bare sbuild command then this fails too, since sbuild will then parse UNRELEASED from the changelog. Perhaps there is also an sbuild bug here, but I think at best it could be expected to error out (unknown distribution) rather succeeding so dgit would still prevent me from passing the required options. I have sbuild=0.65.2-1 (sid) and schroot=1.6.10-1+b1 (stretch). Thanks, Ian. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dgit depends on: ii ca-certificates20150426 ii coreutils 8.23-4 ii curl 7.43.0-1 ii devscripts 2.15.8 ii dpkg-dev 1.18.1 ii dput 0.9.6.4 ii git [git-core] 1:2.5.0-1 ii libdpkg-perl 1.18.1 ii libjson-perl 2.90-1 ii libwww-perl6.13-1 ii perl [libdigest-sha-perl] 5.20.2-6 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:6.7p1-6 Versions of packages dgit suggests: ii sbuild 0.65.2-1 -- debconf-show failed
Bug#796016: dgit: Does not work with single-debian-patch (perhaps only in the presence of merge commits)
Package: dgit Version: 1.3 Severity: normal Using this package repo: ssh://i...@git.debian.org/git/collab-maint/sunxi-tools.git wip/dgit Which is a 3.0 (quilt) package with single-debian-patch enabled in debian/source/local-options and running 'dgit build-source' results in: $ dgit build-source Format `3.0 (quilt)', checking/updating patch stack HEAD is now at c7105b6 Switch to debian/$version tags. dgit: quilt fixup cannot be linear. Stopped at: dgit: ..: merge (2 nontrivial parents) dgit: quilt fixup naive history linearisation failed. dgit: Use dpkg-source --commit by hand; or, --quilt=smash for one ugly patch Moving debian/source/local-options to debian/source/options does not change the behaviour. Using --quilt=smash as suggested does produce a source package however it also produces a commit adding the single-debian-patch to the source repo. My main reason for using single-debian-patch is that dpkg-source will create that patch for me without needing to have debian/patches in git at all (or more importantly maintain it when I git cherry-pick). I'm hoping that it will be possible to avoid injecting this synthesised commit only into my maintainer history (perhaps only pushing it to the dgit repo?). If not then I would probably choose to switch to more explicitly managing debian/patches e.g. with git-dpm or gbp pq. As an aside the current synthesised patch does not honour debian/source/patch-header which is what dpkg-source would use as the intro to the patch (in my case I use it to point people to git for the full history, although dgit does make that somewhat less necessary). Thanks, Ian. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dgit depends on: ii ca-certificates20150426 ii coreutils 8.23-4 ii curl 7.43.0-1 ii devscripts 2.15.8 ii dpkg-dev 1.18.1 ii dput 0.9.6.4 ii git [git-core] 1:2.5.0-1 ii libdpkg-perl 1.18.1 ii libjson-perl 2.90-1 ii libwww-perl6.13-1 ii perl [libdigest-sha-perl] 5.20.2-6 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:6.7p1-6 Versions of packages dgit suggests: ii sbuild 0.65.2-1 -- debconf-show failed
Bug#795694: git-dpm: Lots of warnings about GREP_OPTIONS
Package: git-dpm Version: 0.9.1-1 Severity: normal I recently noticed that git-dpm on my laptop was producing quite a lot of: grep: warning: GREP_OPTIONS is deprecated; please use an alias or script This appears to be as a result of #411931 being fixed in grep as of 2.21-1. git-dpm seems to be using this for: export GREP_OPTIONS=--color=never I suppose to override any local user version. Perhaps you could achieve the same goal while remaining compatible with old and new grep by just clearing the variable rather than setting it? Cheers, Ian. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages git-dpm depends on: ii dpkg-dev 1.18.1 ii git 1:2.5.0-1 Versions of packages git-dpm recommends: ii bzip2 1.0.6-8 ii devscripts 2.15.8 ii sensible-utils 0.0.9 ii xz-utils5.1.1alpha+20120614-2.1 Versions of packages git-dpm suggests: ii pristine-tar 1.33 ii sharutils 1:4.15.2-1 -- no debconf information
Bug#795281: autofs: Please provide a mechanism to make automount root mount points shared
Package: autofs
Version: 5.0.8-2
Severity: wishlist
Dear Maintainer,
As described in the final section of
https://www.kernel.org/doc/Documentation/filesystems/autofs4.txt it is
necessary to run mount --make-shared /autofs/mount/point on systems
which make use of bind mounts and/or namespaces, or else things start
spuriously failing with ELOOP.
Assuming that there is no desire to change the default then having an
easy way to configure this would be very useful. Locally I've gone
with the following patch but it is obviously pretty specific to our NIS
environment.
diff --git a/init.d/autofs b/init.d/autofs
index 2de0f26..cc6bf97 100755
--- a/init.d/autofs
+++ b/init.d/autofs
@@ -60,6 +60,17 @@ start() {
return 1
fi
log_end_msg 0
+
+ # See end of
https://www.kernel.org/doc/Documentation/filesystems/autofs4.txt
+ # autofs mount points need to be made shared else they can interact
+ # badly with the use of namespaces.
+ log_action_begin_msg Making automount roots shared
+ for mnt in $(ypcat -k auto.master | cut -f1 -d' ') ; do
+ log_action_cont_msg $mnt
+ mount --make-shared $mnt
+ done
+ log_end_msg 0
+
return 0
}
I'm running Jessie but I've checked the Stretch and Sid changelogs (Debian and
upstream) and I didn't see anything which suggested this had changed.
Thanks!
Ian.
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages autofs depends on:
ii libc6 2.19-18
ii libxml22.9.1+dfsg1-5
ii multiarch-support 2.19-18
ii ucf3.0030
Versions of packages autofs recommends:
ii kmod 18-3
ii module-init-tools 18-3
ii nfs-common 1:1.2.8-9
autofs suggests no packages.
-- Configuration Files:
/etc/apm/event.d/autofs 374404a5115c1c9ef87fc99fab9600c1 [Errno 2] No such file
or directory: u'/etc/apm/event.d/autofs 374404a5115c1c9ef87fc99fab9600c1'
/etc/auto.master a0e3fc444b0824664ffc04826e2f3c97 [Errno 2] No such file or
directory: u'/etc/auto.master a0e3fc444b0824664ffc04826e2f3c97'
/etc/auto.net 0acd3943236c9eae496eb815610c25db [Errno 2] No such file or
directory: u'/etc/auto.net 0acd3943236c9eae496eb815610c25db'
/etc/auto.smb eec3f773e09846b7d4325f0ce20ab5bd [Errno 2] No such file or
directory: u'/etc/auto.smb eec3f773e09846b7d4325f0ce20ab5bd'
/etc/default/autofs 424c4415a458ca32a56e88f847a80690 [Errno 2] No such file or
directory: u'/etc/default/autofs 424c4415a458ca32a56e88f847a80690'
/etc/init.d/autofs changed:
PROG=automount
DAEMON=/usr/sbin/$PROG
NAME=autofs
PIDFILE=/var/run/$NAME.pid
test -e $DAEMON || exit 0
PATH=/sbin:/usr/sbin:/bin:/usr/bin
export PATH
. /lib/lsb/init-functions
if [ -r /etc/default/autofs ]; then
. /etc/default/autofs
fi
start_stop_autofs() {
start-stop-daemon $@ --pidfile $PIDFILE --exec $DAEMON -- \
$OPTIONS --pid-file $PIDFILE
}
start() {
log_action_begin_msg Starting $PROG
if ! grep -qw autofs /proc/filesystems
then
if ! modprobe autofs4 /dev/null 21
then
log_action_end_msg 1 failed to load autofs4 module
return 1
fi
elif [ -f /proc/modules ] grep -q ^autofs[^4] /proc/modules
then
log_action_end_msg 1 autofs kernel module is loaded, autofs4
required
return 1
fi
if ! start_stop_autofs --start --oknodo --quiet ; then
log_action_end_msg 1 no valid automount entries defined.
return 1
fi
log_end_msg 0
# See end of
https://www.kernel.org/doc/Documentation/filesystems/autofs4.txt
# autofs mount points need to be made shared else they can interact
# badly with the use of namespaces.
log_action_begin_msg Making automount roots shared
for mnt in $(ypcat -k auto.master | cut -f1 -d' ') ; do
log_action_cont_msg $mnt
mount --make-shared $mnt
done
log_end_msg 0
return 0
}
stop() {
log_action_begin_msg Stopping $PROG
if ! start_stop_autofs --stop --retry 5 --oknodo --quiet ; then
log_action_end_msg 1
return 1
fi
log_end_msg 0
return 0
}
reload() {
log_action_begin_msg Reloading $PROG maps
if ! start_stop_autofs --stop --signal=HUP --quiet
then
log_action_end_msg 1 $PROG not running
return 1
fi
log_action_end_msg 0
return 0
}
forcestart() {
OPTIONS=$OPTIONS --force
start
}
case $1 in
Bug#795231: fails on cubietruck with FAT /boot
Control: tags -1 wontfix On Tue, 2015-08-11 at 23:43 -0400, Joey Hess wrote: Package: flash-kernel Version: 3.36 Severity: normal A few places in flash-kernel try to ln -s, and this fails if /boot is a FAT filesystem. It should be possible to fall back to cp in this case. I general /boot on FAT is not supported, not just flash-kernel will have potential problems but also dpkg itself (hard links atomic ops), kernel hooks, initramfs hooks etc. The cubietruck u-boot is more than capable of booting from an ext filesystem, so you should just do that, in fact everything should work in this mode out of the box, how did you end up with a FAT /boot? On platforms where u-boot is only capable of reading FAT the recommended approach is to use a dedicated FAT partition which is not normally mounted and use flash-kernel's Boot-Device option to cause the boot images to be copied to it. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771949: modified patch
On Fri, 24 Jul 2015 09:30:46 +0200 =?ISO-8859
-2?Q?=22Jan_Bub=EDk_=28ACVy=B9kov=29=22?=
bu...@acvyskov.cz wrote:
Hi all, I had the same problem in Xenserver 5.6 environment with Jessie
in PV DomU.
I confirm that Dominique's patch helps with a minor modification. The
original patch creates paths that start like //vmlinuz-3.16.0-4-amd64.
That is not compatible with Xenserver PVGRUB. I attach a corrected
patch. That creates paths like /vmlinuz-3.16.0-4-amd64.
I also confirm, that with this patch applied, update-menu-lst generates
correct paths when /boot is on the root partition (eg. not-separated).
I have also just confirmed this, running pv-menu-lst in an arm guest on
Xen, which has a separate /boot by default from d-i.
Looking at the package git tree I see that support for creating relative
paths was actually deliberately removed. The best solution might be to
simply revert the commit below?
Ian.
commit 1a419be5828cf56ce02b88e8cb1470f8ac8df62e
Author: Charles Plessy ple...@debian.org
Date: Sat Jan 25 22:51:53 2014 +0900
Remove make_system_path_relative_to_its_root, only called on absolute paths
here.
diff --git a/update-menu-lst b/update-menu-lst
index 5eb0319..d0793dc 100755
--- a/update-menu-lst
+++ b/update-menu-lst
@@ -28,53 +28,6 @@ set -e
host_os=`uname -s | tr '[A-Z]' '[a-z]'`
-# This function was borrowed from grub2/util/update-grub_lib.in
-make_system_path_relative_to_its_root ()
-{
- path=$1
- # abort if file doesn't exist
- if test -e $path ; then : ;else
-return 1
- fi
-
- # canonicalize
- if path=`readlink -f $path` ; then : ; else
-return 1
- fi
-
- # if not a directory, climb up to the directory containing it
- if test -d $path ; then
-dir=$path
- else
-dir=`echo $path | sed -e s,/[^/]*$,,g`
- fi
-
- num=`stat -c %d $dir`
-
- # this loop sets $dir to the root directory of the filesystem we're
inspecting
- while : ; do
-parent=`readlink -f $dir/..`
-if [ x`stat -c %d $parent` = x$num ] ; then : ; else
- # $parent is another filesystem; we found it.
- break
-fi
-if [ x$dir = x/ ] ; then
- # / is our root.
- break
-fi
-dir=$parent
- done
-
- # This function never prints trailing slashes (so that its output can be
- # appended a slash unconditionally). Each slash in $dir is considered a
- # preceding slash, and therefore the root directory is an empty string.
- if [ $dir = / ] ; then
-dir=
- fi
-
- echo $path | sed -e s,^$dir,,g
-}
-
# The grub installation directory
grub_dir=/boot/grub
@@ -114,7 +67,7 @@ esac
boot_device=$(find_device /boot)
# where grub looks for the kernels at boot time
-kernel_dir=`make_system_path_relative_to_its_root /boot`
+kernel_dir=/boot
# the -t abstraction check is a workaround untill #484297 is fixed
if abstraction=`grub-probe -t abstraction --device ${root_device} 2
/dev/null` [ $abstraction = ] \
@@ -583,7 +536,7 @@ echo $buffer
echo -n Searching for splash image ... 2
current_splash=`grep '^splashimage=' ${menu_file} || true`
-grub_dir_rel=`make_system_path_relative_to_its_root $grub_dir`
+grub_dir_rel=$grub_dir
splashimage_path=splashimage=${grub_root_device}/${grub_dir_rel##${kernel_dir}}/splash.xpm.gz
if [ `sed -e /^$start/,/^$end/d $menu_file | grep -c '^splashimage='` != 0
] ; then
#checks for splashscreen defined outside the autoupdated part
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794403: flash-kernel: command update-initramfs -uk kver result in boot images in false version
On Mon, 2015-08-03 at 01:27 +0900, Roger Shimizu wrote: Package: flash-kernel Version: 3.45 Severity: normal Tags: patch Dear Maintainer, Hook script initramfs-hook/flash-kernel will be called when update-initramfs is invoked. However flash-kernel only build the latest kernel version it find, rather than the specific version passing from update-initramfs. For example, after running update-initramfs -uk , the is successfully passed to initramfs-hook/flash-kernel, and then flash-kernel script, but flash-kernel script simply ignore that version, except adding a --force flag, which is why this patch is here. The update-initramfs -uk kver command is intended to update the initramfs for kver, it is not intended to mean and boot kver next time, that is not update-initramfs's job (on other platforms it does not e.g. call grub-set-default or grub-reboot either). flash-kernel normally always tries to keep the latest kernel installed. It offers a command line override for this, but this is not expected to be used by automatic callers. Really this capability is more for debugging (by booting an older kernel once or twice) than anything else. If you want to permanently boot kver then at the moment you have to arrange that kver is the newest installed kernel. I think your patch will break things by automatically installing (via the initramfs hook in the kernel postinst) whatever kernel was most recently installed/upgraded, instead of the latest kernel by version. We do not want this: consider people who still have stable+testing in their sources.list and the stable+testing kernel's both installed, they are expecting to use the testing kernel and do not want to get a surprise stable kernel installed whenever a DSA is issued against the Linux package in stable. I also checked the log for initramfs-hook/flash-kernel, as commit 7bacb9 the kernel version was actually not passed to flash-kernel script, but from commit e05fc9, this has been changed, which I think it means the flash-kernel script need to honor what kernel version update-initramfs is working on. I'm afraid not, when called from the initramfs-hook flash-kernel should arrange for the update only if operating on the newest kernel. An acceptable alternative to your patch might be to add support for a new option in /etc/default/flash-kernel e.g. LINUX_KERNEL_VERSION which names an explicit version which is the one which should should always be installed in flash (unless overridden on the command line). Care would need to be taken that the kernel exists and to do the right thing if it is is removed. I think a suitable algorithm for determining the version would be to consider in order: 1. The version on the command line, if any. If one is given but doesn't exist then error out. 2. The version from /etc/default/flash -kernel:$LINUX_KERNEL_VERSION, if it doesn't exist then fall through to next option(*) with a big fat warning printed. 3. The currently installed version with the greatest version number. The fall through from option 2 to option 3 is important, otherwise a kernel removal/upgrade/install (which invokes flash-kernel) may find itself unable to complete if the desired kernel is missing and abort the whole operation, which will be potentially tricky to recover from since it will block further apt/dpkg operations until it is sorted out. Installing the latest kernel if the preferred option is not available seems better than failing in this case. People who then want to boot an older kernel could set LINUX_KERNEL_VERSION and call flash-kernel to make it take effect. Ian. Thanks and looking forward to your comments. Cheers, Roger -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (1, 'experimental') Architecture: armel (armv5tel) Kernel: Linux 4.0.0-2-kirkwood Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages flash-kernel depends on: ii debconf [debconf-2.0] 1.5.56 ii devio 1.2-1+b1 ii initramfs-tools0.120 ii linux-base 3.5 ii ucf3.0030 Versions of packages flash-kernel recommends: ii u-boot-tools 2014.10+dfsg1-5 flash-kernel suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Sat, 2015-08-01 at 10:51 +0100, Ian Campbell wrote: http://git.kernel.org/linus/07949bf9c63c9a80027fe8452d5fe8b9ba9b3c23 I'll see about backporting that to the 4.1 kernel in Debian until we move to 4.2. It turns out that this patch while necessary is not sufficient and I also needed the following for full cpufreq autoloading on Cubietruck with Debian's modular kernel config. Cheers, Ian. 8--- From 38880ed1b26e8778268c1da41ab2bb52c6797947 Mon Sep 17 00:00:00 2001 From: Ian Campbell i...@hellion.org.uk Date: Sat, 1 Aug 2015 13:44:06 +0100 Subject: [PATCH] regulator: axp20x: Add module alias This allows the module to be autoloaded. Together with 07949bf9c63c (cpufreq: dt: allow driver to boot automatically) this is sufficient to allow a modular kernel (such as Debian's) to enable cpufreq on a Cubietruck. Signed-off-by: Ian Campbell i...@hellion.org.uk Cc: Liam Girdwood lgirdw...@gmail.com Cc: Mark Brown broo...@kernel.org Cc: Signed-off-by: Chen-Yu Tsai w...@csie.org Cc: Maxime Ripard maxime.rip...@free-electrons.com --- drivers/regulator/axp20x-regulator.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c index e4331f5..2c82131 100644 --- a/drivers/regulator/axp20x-regulator.c +++ b/drivers/regulator/axp20x-regulator.c @@ -264,3 +264,4 @@ module_platform_driver(axp20x_regulator_driver); MODULE_LICENSE(GPL v2); MODULE_AUTHOR(Carlo Caione ca...@caione.org); MODULE_DESCRIPTION(Regulator Driver for AXP20X PMIC); +MODULE_ALIAS(platform:axp20x-regulator); -- 2.1.4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Thu, 2015-07-30 at 15:47 +0800, Chen-Yu Tsai wrote: On Sat, Jul 25, 2015 at 11:30 PM, Ian Campbell i...@debian.org wrote: On Sat, 2015-07-25 at 22:54 +0800, Chen-Yu Tsai wrote: On Sat, Jul 25, 2015 at 10:46 PM, Leonardo Canducci leonardo.candu...@gmail.com wrote: I got lost somewhere in that long thread but I saw cpufreq on cubie* works for someone [0]. It's just a matter of loading two modules. I tried myself on my jessie install (kernel from experimental) and can confirm that: leo@cubetto:~$ sudo modprobe axp20x-regulator leo@cubetto:~$ sudo modprobe cpufreq-dt leo@cubetto:~$ ls /sys/devices/system/cpu/cpu0/cpufreq/ affected_cpus related_cpus scaling_governor cpuinfo_cur_freqscaling_available_frequencies scaling_max_freq cpuinfo_max_freqscaling_available_governors scaling_min_freq cpuinfo_min_freqscaling_cur_freq scaling_setspeed cpuinfo_transition_latency scaling_driver statsplatform_device_register_simple How do I make this change persistent? Add both module names to /etc/modules. Is there any way to arrange for these modules to be loaded automatically without the user needing to configure it manually, likeplatform_device_register_simple(cpufreq-dt, -1, NULL, 0); any other h/w driver? I'd expect at least the axp20x-regulator driver to get autoloaded when the relevant hardware is present. Not sure about the cpufreq-dt one, * In particular, when such drivers are built as modules, they can't be * hotplugged. but should it not be loaded if the relevant nodes are present? cpufreq-dt is not a node in the DT. It is added in platform code. See arch/arm/mach-sunxi/sunxi.c. That is this: platform_device_register_simple(cpufreq-dt, -1, NULL, 0); AFAIK all other users of cpufreq-dt use this method. Not sure how you can automatically detect this... Supposedly there wouldfeatures/all/cpufreq-dt-allow-driver-to-boot-automatically.patch be an event to udev? I would expect the register to emit something, perhaps all that is missing is a suitable MODULE_ALIAS. Looking around there seems to be a fair few MODULE_ALIAS(platform:foo) which appear to serve this purpose. ...searches..., aha!: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350884.html which is in v4.2-rc1 as: http://git.kernel.org/linus/07949bf9c63c9a80027fe8452d5fe8b9ba9b3c23 I'll see about backporting that to the 4.1 kernel in Debian until we move to 4.2. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793786: initramfs-tools: fix the broken netconsole feature in initramfs-tools
On Wed, 2015-07-29 at 18:50 +0900, Roger Shimizu wrote: Dear Ian, Thanks for your response! I'd like to ask whether you could offer the Reviewed-by for my first patch of Bug#793786? (0001-advance-the-timing-of-insmod-netconsole.patch) You must be a netconsole user that understand the reasoning why to load netconsole module with param should be earlier than calling load_modules routine. I'm afraid I'm not, the pinnacle of my understanding of netconsole was back when I wrote that blog post and basically everything I knew (which wasn't much) was written there. I haven't used it much since that debugging incident (although I keep thinking I should deploy it properly). Is the 1st patch basically because if netconsole is (or might be) listed in the /etc/initramfs-tools/modules then it is loaded with whatever options are given there and so when you come to do the load in /sbin/init it is already loaded and present? In which case that does seem to make sense, yes. Does netconsole.netconsole=FOO (which is really module.param=value, the module and param just happen to have the same name) on the command line not get honoured by the load inside load_modules too? Even if it is then netconsole= is a nice convenience shortcut, so I think that your first patch probably makes sense, at least so far as I understand the implications. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791794: UUID not found for root
On Thu, 2015-07-30 at 12:02 -0400, Martin Michlmayr wrote: * Ian Campbell i...@debian.org [2015-07-22 09:10]: I think it is the DEBIAN_FRONTEND which is supposed to work for the installer case, which you added back in 2008. in-target appears to have set DEBIAN_FRONTEND=passthrough since 2005, but perhaps something has gotten into (or out of) the middle in the meantime? Or perhaps something has changed to using in-target which wasn't before? In any case, perhaps the answer is to check for DEBIAN_FRONTEND either noninteractive or passthrough? Or maybe even just for it being set at all, since even if it were =text or =newt or whatever echo+read doesn't seem like the right answer... I've no idea what would be best. I was hoping Colin would comment. Unless someone has an alternative suggestion I think I'll make the flash-kernel initramfs-hook gate its waiting for Ctrl-C on failure behaviour on either DEBIAN_FRONTEND or DEBIAN_HAS_FRONTEND being non -empty. Today the DEBIAN_FRONTEND check is explicitly for noninteractive which omits at least passthrough as another problematic case. It seems to me that few of the other possible options would benefit from being made to wait here (graphical ones surely not, likewise newt, maybe text would be ok, but lets not bother special casing it). I found an old branch where I tried to get the initramfs-hook to use debconf if it appears to be already running. I don't think I ever got it working, and it looks like I was having trouble arranging for flash -kernel's templates to be loaded (since we are running in the context of some other packages debconf invocation), which matches my vague recollection. I've pasted the key hunk below in case any one has any ideas how to make this work correctly. Ian. # Script is called from update-initramfs which in term can be # called manually by the admin from the CLI or via various # postinst and trigger hooks or from the installer. # - # If debconf appears to be running then it is important that - # we do not block on stdin since this would hang the - # installer. + # If debconf appears to be running then use it to notify the + # user. This is particularly important if the error occurs + # during the installer. if [ $DEBIAN_HAS_FRONTEND ]; then echo Unable to abort; system will probably be broken! 2 + # No need to worry about confmodule re-execing the + # script since we check $DEBIAN_HAS_FRONTEND + # immediately above + . /usr/share/debconf/confmodule + # Make sure our templates are loaded + db_x_loadtemplatefile $(dpkg-query --control-path flash-kernel templates) flash-kernel + db_title flash-kernel + db_subst flash-kernel/$template ROOTDEV $rootdev + db_input critical flash-kernel/$template + db_go + #db_get flash-kernel/$template else + echo 2 echo Press Ctrl-C to abort build, or Enter to continue 2 read _ignored fi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782054: mbsync: New version cannot open Maildir boxes
Hi Oswald,
I'm suffering from a similar issue to Guillem, which I'll mention below,
but first a wishlist feature request (I hope you don't mind):
It would be super useful if mbsync -l could produce the actual literal path
of the Maildir to which a given folder was being sync'd. With sufficient
debug/verbosity I can infer from the reading sync state message, but
having a concise way to see how things will end up would greatly simplify
tweaking the config.
Anyway, on to the issue I'm having:
On Wed, 8 Apr 2015 09:53:40 +0200 Oswald Buddenhagen
oswald.buddenha...@gmx.de wrote:
i suspect this is due to the trailing dot in the Path specification,
i.e., your attempt to create a namespace which uniformly uses leading
dots, not only for subfolders.
I currently have a Maildir with:
$ cat ~/Maildir/..maildir++
maildir++ 1
$
and a layout like:
~/Maildir/{new,tmp,cur} # AKA INBOX
~/Maildir/..PATCHES.WIP/{new,tmp,cur} # From now on {...}
~/Maildir/..PATCHES.FOO/{...}
~/Maildir/..Cronspam/{...}
Which results (in the Evolution MUA GUI) in a tree like:
[Account]
`-INBOX
|- PATCHES
| |- WIP
| `- FOO
`- Cronspam
As an alternative I could switch to:
~/Maildir/{new,tmp,cur} # AKA INBOX
~/Maildir/.PATCHES.WIP/{new,tmp,cur} # From now on {...}
~/Maildir/.PATCHES.FOO/{...}
~/Maildir/.Cronspam/{...}
Which would result in:
[Account]
|-INBOX
|- PATCHES
| |- WIP
| `- FOO
`- Cronspam
I'd be fine with switching to this if that is better supported somehow.
However this:
~/Maildir/{new,tmp,cur} # AKA INBOX
~/Maildir/PATCHES.WIP/{new,tmp,cur} # From now on {...}
~/Maildir/PATCHES.FOO/{...}
~/Maildir/Cronspam/{...}
Results in:
[Account]
`-INBOX
i.e. subfolders without the leading . are ignored. It was my understanding
(confirmed by the links which Guillem has posted) that the leading . was a
requirement of Maildir++.
I'm currently using 1.1.2-1 but due to this happening:
Maildir error: UID 580 is beyond highest assigned UID 153.
I thought I should upgrade to 1.2.0-1 (I know how to fix this manually, and
have done, but I'd rather upgrade). On upgrade I trip over the Error:
channel server: slave [...] cannot be opened. issue which Guillem
describes.
So, please could you recommend a set of options which produce a Maildir
tree which is compatible with Evolution's Maildir++?
My (redacted) .mbsyncrc is attached.
FWIW the other end in this case is a MS Exchange IMAP, I don't know which
version.
Many thanks,
Ian.IMAPAccount XXX
Host x
User x
Pass x
CertificateFile /etc/ssl/certs/ca-certificates.crt
IMAPStore XXX-remote
Account XXX
MaildirStore XXX-local
Path ~/Maildir/..
Inbox ~/Maildir/
#AltMap yes
Flatten .
Channel XXX-inbox
Master :XXX-remote:
Slave :XXX-local:
Patterns INBOX
Create Slave # Without this no sync
Expunge Both
SyncState *
Channel XXX-folders
Master :XXX-remote:INBOX/
Slave :XXX-local:
Patterns * !INBOX
Create Slave
Expunge Both
SyncState *
Bug#793786: initramfs-tools: fix the broken netconsole feature in initramfs-tools
On Wed, 2015-07-29 at 01:16 +0900, Roger Shimizu wrote: Hope you don't mind that I polished your code and post in BTS. Absolutely not, thanks for doing so! In case it is necessary any code from http://www.hellion.org.uk/blog/po sts/debugging-initramfs-over-netconsole/ should be considered: Signed-off-by: Ian Campbell i...@debian.org for the purposes of inclusion in initramfs-tools. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Sat, 2015-07-25 at 22:54 +0800, Chen-Yu Tsai wrote: On Sat, Jul 25, 2015 at 10:46 PM, Leonardo Canducci leonardo.candu...@gmail.com wrote: I got lost somewhere in that long thread but I saw cpufreq on cubie* works for someone [0]. It's just a matter of loading two modules. I tried myself on my jessie install (kernel from experimental) and can confirm that: leo@cubetto:~$ sudo modprobe axp20x-regulator leo@cubetto:~$ sudo modprobe cpufreq-dt leo@cubetto:~$ ls /sys/devices/system/cpu/cpu0/cpufreq/ affected_cpus related_cpus scaling_governor cpuinfo_cur_freqscaling_available_frequencies scaling_max_freq cpuinfo_max_freqscaling_available_governors scaling_min_freq cpuinfo_min_freqscaling_cur_freq scaling_setspeed cpuinfo_transition_latency scaling_driver stats How do I make this change persistent? Add both module names to /etc/modules. Is there any way to arrange for these modules to be loaded automatically without the user needing to configure it manually, like any other h/w driver? I'd expect at least the axp20x-regulator driver to get autoloaded when the relevant hardware is present. Not sure about the cpufreq-dt one, but should it not be loaded if the relevant nodes are present? Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793185: linux-image-3.16.0-4-armmp: missing cpufreq on cubieboard (Allwinner A10 sun4i)
On Wed, 2015-07-22 at 14:33 +0200, Leonardo Canducci wrote: I tried comparing dmesg from sunxi kernel (3.4) and experimental (4.1) but I couldn't spot anything relevant. Both are attached as I'm not skilled enough and I might have missed something. I don't see anything either, please could you take this to the upstream mailing list: linux-su...@googlegroups.com . Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793179: debian-installer stretch reboots because of watchdog
On Wed, 2015-07-22 at 16:09 +0100, Ian Campbell wrote: On Wed, 2015-07-22 at 08:07 -0700, Martin Michlmayr wrote: * Ian Campbell i...@debian.org [2015-07-22 10:56]: I think you might be right, apart from backports. Maybe in the context of the udeb we should not worry about that though? I think in the past the gpio_keys file was required, otherwise qcontrol wouldn't even start. I'm not sure if the gpio_keys are optional nowadays, i.e. whether qcontrol will still function if the file doesn't exist (apart from keys, obviously). Yes, they are optional (or that was my intention with that bit of lua in the cfg file at least!). Ah, I was thinking backwards about the backports, it doesn't matter what name the kernel provides because everything which makes the device optional would come along with the backported qcontrol. So, I think we should just nuke the check. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793179: debian-installer stretch reboots because of watchdog
On Wed, 2015-07-22 at 08:07 -0700, Martin Michlmayr wrote: * Ian Campbell i...@debian.org [2015-07-22 10:56]: I think you might be right, apart from backports. Maybe in the context of the udeb we should not worry about that though? I think in the past the gpio_keys file was required, otherwise qcontrol wouldn't even start. I'm not sure if the gpio_keys are optional nowadays, i.e. whether qcontrol will still function if the file doesn't exist (apart from keys, obviously). Yes, they are optional (or that was my intention with that bit of lua in the cfg file at least!). Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793157: flash-kernel: syslinux-style boot configuration on recent u-boot versions
On Tue, 2015-07-21 at 23:09 +0200, Thibaut Girka wrote: On Tue, Jul 21, 2015 at 09:48:32PM +0100, Ian Campbell wrote: […] Long story short, I manually manually == with debootstrap from a host system or some other way? Yes, debootstrap from my amd64 laptop (second stage in a chroot with qemu-static). I also installed the kernel and flash-kernel in the chroot. I just deleted the /boot/extlinux directory and ran flash-kernel again in the booted system, but it still doesn't work. installed Debian Jessie (as well as linux-image-4.0.0-2-armmp and u -boot from u-boot-sunxi=2015.04+dfsg1-2) on an A20-OLinuXino-LIME2 from Olimex but couldn't get it to boot (even with the boot.scr created by flash-kernel when invoked in a chroot with “FK_MACHINE=Olimex A20-OLinuXino-LIME2 flash-kernel”) until I created the simple /boot/extlinux/extlinux.conf file attached. This is a bug, the boot.scr method is expected to work and should be supported for this system, since there is a db entry. If it is broken we'd like to know the details of how please, including full logs if possible. It appears to load the kernel, and then nothing happens anymore, the screen is black and everything appears dead. I have not tried accessing it through the serial console as I don't have the required hardware (that is the reason why I haven't used d-i in the first place, as it lacks display support). It's hard to say without logs but I suspect you are missing the contents of /etc/default/flash-kernel which according to your working extlinux.conf in your case should should contain: LINUX_KERNEL_CMDLINE=root=/dev/mmcblk0p1 ro rootwait This would normally be setup by d-i. You can either edit that file directly or dpkg-reconfigure -plow flash-kernel in the chroot. You might also be able to add console=tty there to override the default serial console. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791794: UUID not found for root
On Wed, 2015-07-22 at 00:02 -0700, Martin Michlmayr wrote: Is $DEBIAN_HAS_FRONTEND supposed to be set when d-i runs in-target? in-target (via chroot-setup.sh in debian-installer-utils) unsets it and always has AFAICT from the git log. From #721485 that clause is there to handle failure when running via a new package install or dpkg-reconfigure on an installed system. I think it is the DEBIAN_FRONTEND which is supposed to work for the installer case, which you added back in 2008. in-target appears to have set DEBIAN_FRONTEND=passthrough since 2005, but perhaps something has gotten into (or out of) the middle in the meantime? Or perhaps something has changed to using in-target which wasn't before? In any case, perhaps the answer is to check for DEBIAN_FRONTEND either noninteractive or passthrough? Or maybe even just for it being set at all, since even if it were =text or =newt or whatever echo+read doesn't seem like the right answer... Ian, do you know what's going on? It seems the fixes you applied are not working. They were for other cases than d-i. Since the fixup to put the DEBIAN_FRONTEND check back I don't think the behaviour under d-i has changed for years. It would be nice (tm) if that bit of code could actually use debconf if it happens to be there, but maybe that's one for another time. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793185: linux-image-3.16.0-4-armmp: missing cpufreq on cubieboard (Allwinner A10 sun4i)
On Wed, 2015-07-22 at 09:41 +0200, Leonardo Canducci wrote: Package: src:linux Version: 3.16.7-ckt11-1 i just installed jessie on my cubieboard as described on the debian wiki page. All is fine but I can't see CPU freq: It seems that cpufreq from sunxi was added to mainline in 4.0. I expect this should work with the 4.0 kernel in sid or the 4.1 kernel from experimental. Please could you try those and report back. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793179: debian-installer stretch reboots because of watchdog
On Tue, 2015-07-21 at 23:45 -0700, Martin Michlmayr wrote:
Package: qcontrol
Version: 0.5.4-4
Severity: important
Tags: patch
Marco Basso reported that d-i stretch alpha 1 reboots after 5
minutes.
The watchdog doesn't get disabled.
The following patch makes it work.
Thanks. I think it should probably check for both names to ease
backporting etc.
Comments:
1) I don't think we need to add backwards compatibility for the old
filename since this is only for d-i.
2) I wonder if we can drop that check altogether with current
qcontrol; not sure.
I think you might be right, apart from backports. Maybe in the context
of the udeb we should not worry about that though?
diff --git a/debian/udeb/qcommand b/debian/udeb/qcommand
index 04d767c..ddb7523 100644
--- a/debian/udeb/qcommand
+++ b/debian/udeb/qcommand
@@ -22,7 +22,7 @@ esac
# The gpio_keys character device is required with the default
# Debian configuration file.
test_event_dev() {
- [ -c /dev/input/by-path/platform-gpio-keys-event ] || return
1
+ [ -c /dev/input/by-path/platform-gpio_keys-event ] || return
1
}
case $device in
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793185: linux-image-3.16.0-4-armmp: missing cpufreq on cubieboard (Allwinner A10 sun4i)
On Wed, 2015-07-22 at 13:21 +0200, Leonardo Canducci wrote: Maybe some device-tree issue? Perhaps. Does anything in the dmesg from the newer kernel give a clue? If not then please can you take this to the upstream list. I don't see any config options which are obviously missing. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793209: evolution: Please backport fix for https://bugzilla.gnome.org/show_bug.cgi?id=751079
Package: evolution Version: 3.16.3-1 Severity: normal Tags: patch upstream Since the update to 3.16.3 there is now a Lose formatting? dialog everytime I try to reply to an HTML mail. Dealing with HTML mail is annoying enough as it is without encouraging more people to send it. Please can you backport the (trivial looking) patch referenced by https://bugzilla.gnome.org/show_bug.cgi?id=751079 It looks like upgrading to 3.17.1+ would also suffice to deal with this issue. Thanks, Ian. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel, arm64 Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages evolution depends on: ii cdebconf [debconf-2.0] 0.194 ii dbus1.8.18-1 ii debconf [debconf-2.0] 1.5.56 ii evolution-common3.16.3-1 ii evolution-data-server 3.16.3-1+b1 ii libatk1.0-0 2.16.0-2 ii libc6 2.19-18 ii libcamel-1.2-52 3.16.3-1+b1 ii libclutter-gtk-1.0-01.6.2-1 ii libecal-1.2-18 3.16.3-1+b1 ii libedataserver-1.2-20 3.16.3-1+b1 ii libevolution3.16.3-1 ii libglib2.0-02.44.1-1.1 ii libgtk-3-0 3.16.5-1 ii libical1a 1.0-1.3 ii libnotify4 0.7.6-2 ii libsoup2.4-12.50.0-2 ii libwebkitgtk-3.0-0 2.4.9-2 ii libxml2 2.9.1+dfsg1-5 ii psmisc 22.21-2 Versions of packages evolution recommends: ii bogofilter 1.2.4+dfsg1-3 ii evolution-plugins 3.16.3-1 ii yelp 3.16.1-1 Versions of packages evolution suggests: pn evolution-ews none pn evolution-plugins-experimental none ii gnupg 1.4.19-3 ii network-manager 1.0.2-2 -- debconf information: evolution/needs_shutdown: evolution/kill_processes: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793157: flash-kernel: syslinux-style boot configuration on recent u-boot versions
On Tue, 2015-07-21 at 22:02 +0200, Thibaut Girka wrote: Package: flash-kernel Severity: normal syslinux-style /boot/extlinux/extlinux.conf superseed boot.scr in recent u-boot versions and seems to be the way forward for u-boot configuration, It's an alternative, but boot.scr remains a valid option and is what we support in Jessie. but I couldn't find anything to automatically generate them in Debian. Long story short, I manually manually == with debootstrap from a host system or some other way? installed Debian Jessie (as well as linux-image-4.0.0-2-armmp and u -boot from u-boot-sunxi=2015.04+dfsg1-2) on an A20-OLinuXino-LIME2 from Olimex but couldn't get it to boot (even with the boot.scr created by flash-kernel when invoked in a chroot with “FK_MACHINE=Olimex A20-OLinuXino-LIME2 flash-kernel”) until I created the simple /boot/extlinux/extlinux.conf file attached. This is a bug, the boot.scr method is expected to work and should be supported for this system, since there is a db entry. If it is broken we'd like to know the details of how please, including full logs if possible. I'm not sure whether flash-kernel is the correct package to implement this feature, but there should be a way to automaticaly generate such files. The extlinux packages support generating these files, that support just needs to be split out and made non-x86 specific I think. That support shouldn't be duplicated in flash-kernel. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789798: Bug#792547: Bug#789798: grub-installer: add option to _not_ install to UEFI boot order
On Thu, 2015-07-16 at 08:34 +0100, Ian Campbell wrote: Control: block 789798 by 792547 I've tested both of these patches (grub-installer [0] and grub2 [1] together but the grub-installer one doesn't do much without the grub2 one, since it appears that the installation of the grub-* packages also ends up running grub-install during installation. To clarify, I rebuilt the Jessie d-i version with this modified grub-installer included in the initrd and did two tests: A normal x86/UEFI install, from mini.iso, which showed no change in behaviour (i.e. Debian was added to the boot order as expected). In the installed system I then installed the updated version of grub2 and manually confirmed that /var/cache/debconf/config.dat had the new option set to true and that having deleted Debian from the boot order dpkg-reconfigure grub-efi-amd64 put it back and that dpkg-reconfigure -plow grub-efi-amd64 asked me the question and it behaved as expected (i.e. didn't add the entry if I deselected the new option). I then reinstalled using my patched d-i but with grub-installer/install-to-nvram=false added tothe kernel command line. I ran through the install and observed in syslog that grub-installer had passed --no-nvram but that Debian was added to the boot order by the existing grub2 packages from the archive (not my patched version) as they were installed. Then in the installed system I confirmed that /var/cache/debconf/config.dat had the new question in it set to false. Deleting the boot order and then installing my patched grub2 packages then correctly obeyed that setting, leading me to conclude that if it had been present in the archive during install then the right thing would have happened. Ian. Ian. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789798#65 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792547#5 ___ Pkg-grub-devel mailing list pkg-grub-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grub-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789798: Updated patch to add option to _not_ install to UEFI boot order
Attached new patch inverts the sense of the option after review of the wording by debian-l10n-english and fixes the propagation of the setting to the installed grub2 package. Ian. From 4e038e33ea681dde7cccb05ba5a1a6b1e3ae8d6f Mon Sep 17 00:00:00 2001 From: Ian Campbell i...@hellion.org.uk Date: Fri, 19 Jun 2015 15:17:40 +0100 Subject: [PATCH] Allow avoiding installation to NVRAM on EFI or IEEE1275 systems On systems which demand greater control over the boot order (e.g. ones which PXE boot) it is useful to avoid messing with this during installation. (Closes: #789798) --- debian/changelog| 2 ++ debian/grub-installer.templates | 12 grub-installer | 12 3 files changed, 26 insertions(+) diff --git a/debian/changelog b/debian/changelog index 24873db..87f4d17 100644 --- a/debian/changelog +++ b/debian/changelog @@ -3,6 +3,8 @@ grub-installer (1.125) UNRELEASED; urgency=medium [ Ian Campbell ] * Correctly propagate grub-installer/force-efi-extra-removable to installed system. (Closes: #792247). + * Add preseedable option to allow avoiding installation to NVRAM. +(Closes: #789798) -- Ian Campbell i...@debian.org Mon, 13 Jul 2015 09:01:46 +0100 diff --git a/debian/grub-installer.templates b/debian/grub-installer.templates index e294afb..73cbff0 100644 --- a/debian/grub-installer.templates +++ b/debian/grub-installer.templates @@ -285,3 +285,15 @@ _Description: Force GRUB installation to the EFI removable media path? installing GRUB there will make that operating system temporarily unbootable. GRUB can be manually configured later to boot it if necessary. + +Template: grub-installer/install-to-nvram +Type: boolean +Default: true +# :sl4: +_Description: Add GRUB to firmware NVRAM configuration? + By default, GRUB will be registered into NVRAM on platforms where this is + required, such as UEFI Boot Manager or OpenFirmware boot devices. + . + Occasionally this is not desired (for instance on systems that PXE boot + and then chainload). If you reject this option, the NVRAM will be left + untouched. diff --git a/grub-installer b/grub-installer index c407cd1..296419e 100755 --- a/grub-installer +++ b/grub-installer @@ -813,6 +813,18 @@ $grub_package grub2/force_efi_extra_removable boolean true EOF fi + # Should we avoid installing/registering GRUB in NVRAM? + db_input low grub-installer/install-to-nvram || [ $? -eq 30 ] + db_go || exit 10 + db_get grub-installer/install-to-nvram + if [ $RET = false ]; then + grub_install_params=$grub_install_params --no-nvram + # Make sure this happens on upgrades too + $chroot $ROOT 'debconf-set-selections' EOF +$grub_package grub2/install_to_nvram boolean false +EOF + fi + if [ $ARCH = powerpc/chrp_pegasos ] ; then # nvram is broken here grub_install_params=$grub_install_params --no-nvram -- 2.1.4
Bug#792547: grub2: add option to _not_ install to UEFI boot order
Source: grub2
Version: 2.02~beta2-26
Severity: wishlist
Tags: patch
In #789798 against grub-installer I said:
I have a need to repeatedly install Debian from PXE on systems which are
UEFI only (arm64 as it happens but I think all of the below applies to x86
UEFI too). When we want to actually boot the installed OS we chainload from
the PXE grub.efi to the one on the ESP (using
grub-installer/force-efi-extra-removable for simplicity, but that's by the
by, I think).
This is for automated testing which does a fresh install before most tests.
The problem is that during install Debian inserts itself into the UEFI boot
order _before_ the PXE entry, this happens via grub-installer.udeb -
grub-install (from the main grub deb) - efibootmgr -c.
This means that when we come to want to regroove the box it won't boot from
PXE.
grub-install offers an option to avoid this (--no-nvram) which is passed by
grub-installer under some very specific circumstances (known broken
hardware) but it would be very useful if this was a pre-seedable option so
it could be used in circumstances such as the above as well.
The solution to this turns out to require patching the grub2 packages as well,
to avoid it installing to NVRAM either during initial package installation or
upgrade. This is achieved by having grub-installer propagate a debconf setting
which is added by this patch. The text of the question was reviewed by
debian-l10n-english in the context of #789798.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500,
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel, arm64
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
From c4edeef5bf548675aadf3aa75e1061a162cb61c2 Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@debian.org
Date: Sat, 11 Jul 2015 11:15:18 +0100
Subject: [PATCH] Add debconf question to avoid installation to NVRAM on EFI or
IEEE1275 systems.
On systems which demand greater control over the boot order (e.g. ones which
PXE boot) it is useful to avoid messing with this during installation.
grub-install exposes --no-nvram for this purpose which only has meaning for
these to classes of systems, so only ask it on those.
(Closes: #xx)
---
debian/changelog| 7 +++
debian/config.in| 5 +
debian/postinst.in | 15 +--
debian/templates.in | 11 +++
4 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 0c2d2ee..d4692f5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+grub2 (2.02~beta2-27) UNRELEASED; urgency=medium
+
+ * Add option to avoid installation to NVRAM on EFI or IEEE1275 systems.
+(Closes: #xx)
+
+ -- Ian Campbell i...@debian.org Sat, 11 Jul 2015 11:14:37 +0100
+
grub2 (2.02~beta2-26) unstable; urgency=medium
[ William Grant ]
diff --git a/debian/config.in b/debian/config.in
index 27775c3..e498da7 100644
--- a/debian/config.in
+++ b/debian/config.in
@@ -78,4 +78,9 @@ case @PACKAGE@ in
db_input low grub2/force_efi_extra_removable || true
;;
esac
+case @PACKAGE@ in
+ grub-*efi*|grub-*ieee1275*)
+db_input low grub2/install_to_nvram || true
+ ;;
+esac
db_go
diff --git a/debian/postinst.in b/debian/postinst.in
index 0ea6fd4..c56c333 100644
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -384,6 +384,16 @@ case $1 in
;;
esac
+case @PACKAGE@ in
+ grub-*efi*|grub-*ieee1275*)
+db_get grub2/install_to_nvram
+if [ $RET = false ]; then
+ NO_INSTALL_TO_NVRAM=--no-nvram
+ # else default is to do so on relevant platforms
+fi
+ ;;
+esac
+
ucf --three-way --debconf-ok --sum-file=/usr/share/grub/default/grub.md5sum ${tmp_default_grub} /etc/default/grub
package=$(ucfq --with-colons /etc/default/grub | cut -d : -f 2)
if echo $package | grep -q ^grub- ; then
@@ -707,7 +717,7 @@ case $1 in
if [ $RET = true ]; then
FORCE_EXTRA_REMOVABLE=--force-extra-removable
fi
- run_grub_install --target=$target $FORCE_EXTRA_REMOVABLE
+ run_grub_install --target=$target $NO_INSTALL_TO_NVRAM $FORCE_EXTRA_REMOVABLE
fi
# /boot/grub/ has more chances of being accessible by GRUB
@@ -725,7 +735,8 @@ case $1 in
# Output may be empty; if so, just update the core image but
# don't install it to any PReP partition.
prep_bootdev=$(/usr/lib/grub/powerpc-ieee1275/prep-bootdev)
-run_grub_install --target=powerpc-ieee1275 $prep_bootdev
+
+run_grub_install --target=powerpc-ieee1275 $NO_INSTALL_TO_NVRAM $prep_bootdev
;;
esac
;;
diff --git a/debian
Bug#789798: grub-installer: add option to _not_ install to UEFI boot order
Control: block 789798 by 792547 I've tested both of these patches (grub-installer [0] and grub2 [1] together but the grub-installer one doesn't do much without the grub2 one, since it appears that the installation of the grub-* packages also ends up running grub-install during installation. Ian. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789798#65 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792547#5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789798: [RFR] New grub-installer-template
On Wed, 2015-07-01 at 07:00 +0200, Christian PERRIER wrote: _Description: Add GRUB to firmware NVRAM configuration? By default, GRUB will be registered into NVRAM on platforms where this is required, such as UEFI Boot Manager or OpenFirmware boot devices. . Occasionally this is not desired (for instance on systems that PXE boot and then chainload). If you do not choose this option, the NVRAM will be left untouched. Thanks, this is what I went with. I needed a similar text for grub2 itself, so I reused the same thing. I'll update the bug shortly. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784880: [PATCH for-4.6] tools: libxl: Handle failure to create qemu dm logfile
On Mon, 2015-07-13 at 14:07 +0100, Wei Liu wrote:
On Mon, Jul 13, 2015 at 01:31:23PM +0100, Ian Campbell wrote:
If libxl_create_logfile fails for some reason then
libxl__create_qemu_logfile previously just carried on and dereferenced
the uninitialised logfile.
Check for the error from libxl_create_logfile, which has already
logged for us.
This was reported as Debian bug #784880.
Reported-by: Russell Coker russ...@coker.com.au
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: 784...@bugs.debian.org
Acked-by: Wei Liu wei.l...@citrix.com
Applied, thanks.
Ian, please:
Should be backported.
---
tools/libxl/libxl_dm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index ad434f0..8ed2d2e 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -46,9 +46,11 @@ static const char *qemu_xen_path(libxl__gc *gc)
static int libxl__create_qemu_logfile(libxl__gc *gc, char *name)
{
char *logfile;
-int logfile_w;
+int rc, logfile_w;
+
+rc = libxl_create_logfile(CTX, name, logfile);
+if (rc) return rc;
-libxl_create_logfile(CTX, name, logfile);
logfile_w = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644);
free(logfile);
--
2.1.4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791794: RAID device not active during boot
On Tue, 2015-07-14 at 13:52 +0200, Peter Nagel wrote: [...] As suggested in the bug report (see message#109) For others reading along this is in #784070 not #791794. Problem solved ... ... and many thanks to Phil. Huzzah! PS: There is still one thing I do not understand: The file etc/mdadm/mdadm.conf (within initrd.img.*) contains an UUID (see below) ... ARRAY /dev/md/0 metadata=1.2 UUID=92da2301:37626555:6e73a527:3ccc045f name=debian:0 spares=1 ... wich seems to be different from the output of ls -l /dev/disk/by-uuid: lrwxrwxrwx 1 root root 9 Jul 14 11:27 c4263f89-eb0c-4372-90ae-ce1a1545613e - ../../md0 I _think_ this is because the former is the UUID of the RAID device, while the latter is the UUID of the filesystem contained within it. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784880: [PATCH for-4.6] tools: libxl: Handle failure to create qemu dm logfile
If libxl_create_logfile fails for some reason then
libxl__create_qemu_logfile previously just carried on and dereferenced
the uninitialised logfile.
Check for the error from libxl_create_logfile, which has already
logged for us.
This was reported as Debian bug #784880.
Reported-by: Russell Coker russ...@coker.com.au
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: 784...@bugs.debian.org
---
Should be backported.
---
tools/libxl/libxl_dm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index ad434f0..8ed2d2e 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -46,9 +46,11 @@ static const char *qemu_xen_path(libxl__gc *gc)
static int libxl__create_qemu_logfile(libxl__gc *gc, char *name)
{
char *logfile;
-int logfile_w;
+int rc, logfile_w;
+
+rc = libxl_create_logfile(CTX, name, logfile);
+if (rc) return rc;
-libxl_create_logfile(CTX, name, logfile);
logfile_w = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644);
free(logfile);
--
2.1.4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792247: grub-installer: Does not correctly propagate grub-installer/force-efi-extra-removable to installed system
Package: grub-installer Version: 1.102 Severity: important Tags: d-i patch While hacking on #789798 and cribbing code from #767037 I spotted a syntax error in the propagation of grub-installer/force-efi-extra-removable to grub2/force_efi_extra_removable in that the input passed to debconf-set-selections omits the package name. The fix is pretty simple by analogy with other uses of debconf-set-selections, see below. This should be fixed in sid/stretch and backported to jessie as well. Stretch side needs coordination with https://lists.debian.org/debian-boot/2015/07/msg00161.html . Ian. From 849a2fe74c31e8acb5768d259e23bdb480e68a4b Mon Sep 17 00:00:00 2001 From: Ian Campbell i...@hellion.org.uk Date: Sun, 12 Jul 2015 22:09:24 +0100 Subject: [PATCH] Fix preseeding of grub2/force_efi_extra_removable into installed system --- grub-installer | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/grub-installer b/grub-installer index 8bbde2e..296419e 100755 --- a/grub-installer +++ b/grub-installer @@ -809,7 +809,7 @@ if [ -z $frdisk ]; then grub_install_params=$grub_install_params --force-extra-removable # Make sure this happens on upgrades too $chroot $ROOT 'debconf-set-selections' EOF -grub2/force_efi_extra_removable boolean true +$grub_package grub2/force_efi_extra_removable boolean true EOF fi -- 2.1.4 -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel, arm64 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785187: [Xen-devel] [PATCH] xen: earlycpio: Pull in latest linux earlycpio.[ch]
On Mon, 2015-07-06 at 17:00 +0100, Jan Beulich wrote: On 01.07.15 at 16:43, ian.campb...@citrix.com wrote: AFAICT our current version does not correspond to any version in the Linux history. This commit resynchronised to the state in Linux commit 598bae70c2a8e35c8d39b610cca2b32afcf047af. Differences from upstream: find_cpio_data is __init, printk instead of pr_*. This appears to fix Debian bug #785187. Appears because my test box happens to be AMD and the issue is that the (valid) cpio generated by the Intel ucode is not liked by the old Xen code. I've tested by hacking the hypervisor to look for the Intel path. Reported-by: Stephan Seitz stse+debianb...@fsing.rootsland.net Signed-off-by: Ian Campbell ian.campb...@citrix.com Not that it really matters for a Linux import refresh, but anyway: Acked-by: Jan Beulich jbeul...@suse.com Applied, thanks. Please could you also queue this for the next appropriate stable release(s). Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789192: flash-kernel: Add support for UDOO Quad
Control: tag -1 +pending On Thu, 2015-06-18 at 21:10 +0200, Michael Fladischer wrote: Heres my db.all entry that I'm using to boot my board: Thanks, I've added that to the git tree. This should also work with the dual core variant but I was not yet able to test it. Comparing imx6dl-udoo.dts with imx6q-udoo.dts I think there is a pretty strong chance it will Just Work, so I also added: Machine: Udoo i.MX6 Dual-lite Board Kernel-Flavors: armmp DTB-Id: imx6dl-udoo.dtb Boot-Script-Path: /boot/boot.scr U-Boot-Script-Name: bootscr.uboot-generic Required-Packages: u-boot-tools i.e. identical other than the DTB-Id and Machine name. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790833: jessie-pu: package flash-kernel/3.35
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu This upload fixes #788782 which results in upgrades to Jessie not booting on the Freescale MX53 LOCO (AKA Quickstart) platform. The issue was that we had ended up with duplicated entries for this system, one which handled device tree and one which used the older board file mechanism, and that the Wheezy-Jessie kernel upgrade switched which one was needed, hence f-k would do the wrong thing for the new krnel whiletheo ld one was running. Flash-kernel does have a udeb but there should be no functional impact to new installs of Jessie since they will already be running the DT kernel during install time. debdiff: diff -Nru flash-kernel-3.35/db/all.db flash-kernel-3.35+deb8u1/db/all.db --- flash-kernel-3.35/db/all.db 2015-04-06 23:19:51.0 +0100 +++ flash-kernel-3.35+deb8u1/db/all.db 2015-06-17 08:22:41.0 +0100 @@ -131,7 +131,8 @@ Bootloader-Sets-Incorrect-Root: yes Machine: Freescale i.MX53 Quick Start Board -Kernel-Flavors: armmp +Machine: Freescale MX53 LOCO Board +Kernel-Flavors: armmp mx5 DTB-Id: imx53-qsb.dtb DTB-Append-From: 3.12 Boot-DTB-Path: /boot/dtb @@ -142,14 +143,6 @@ Required-Packages: u-boot-tools Bootloader-Sets-Incorrect-Root: no -Machine: Freescale MX53 LOCO Board -Kernel-Flavors: armmp mx5 -U-Boot-Kernel-Address: 0x70008000 -U-Boot-Initrd-Address: 0x0 -Boot-Kernel-Path: /boot/uImage -Boot-Initrd-Path: /boot/uInitrd -Required-Packages: u-boot-tools - Machine: Genesi Efika Smartbook Kernel-Flavors: armmp mx5 U-Boot-Kernel-Address: 0x90008000 diff -Nru flash-kernel-3.35/debian/changelog flash-kernel-3.35+deb8u1/debian/changelog --- flash-kernel-3.35/debian/changelog 2015-04-06 23:33:25.0 +0100 +++ flash-kernel-3.35+deb8u1/debian/changelog 2015-06-17 08:22:41.0 +0100 @@ -1,3 +1,10 @@ +flash-kernel (3.35+deb8u1) stable; urgency=medium + + * Combine i.MX53 QSB and LOCO board entries, they are the same thing and the +LOCO variant was missing DTB information. (Closes: #788782) + + -- Ian Campbell i...@debian.org Wed, 17 Jun 2015 08:22:22 +0100 + flash-kernel (3.35) unstable; urgency=medium * Team upload. -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785187: [PATCH] xen: earlycpio: Pull in latest linux earlycpio.[ch]
AFAICT our current version does not correspond to any version in the
Linux history. This commit resynchronised to the state in Linux
commit 598bae70c2a8e35c8d39b610cca2b32afcf047af.
Differences from upstream: find_cpio_data is __init, printk instead of
pr_*.
This appears to fix Debian bug #785187. Appears because my test box
happens to be AMD and the issue is that the (valid) cpio generated by
the Intel ucode is not liked by the old Xen code. I've tested by
hacking the hypervisor to look for the Intel path.
Reported-by: Stephan Seitz stse+debianb...@fsing.rootsland.net
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Stephan Seitz stse+debianb...@fsing.rootsland.net
Cc: 785...@bugs.debian.org
---
This should be backported.
---
xen/common/earlycpio.c | 39 ---
xen/include/xen/earlycpio.h |1 +
2 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/xen/common/earlycpio.c b/xen/common/earlycpio.c
index 5e54142..f6b1a9e 100644
--- a/xen/common/earlycpio.c
+++ b/xen/common/earlycpio.c
@@ -54,25 +54,26 @@ enum cpio_fields {
/**
* cpio_data find_cpio_data - Search for files in an uncompressed cpio
- * @path: The directory to search for, including a slash at the end
- * @data: Pointer to the the cpio archive or a header inside
- * @len:Remaining length of the cpio based on data pointer
- * @offset: When a matching file is found, this is the offset to the
- * beginning of the cpio. It can be used to iterate through
- * the cpio to find all files inside of a directory path
+ * @path: The directory to search for, including a slash at the end
+ * @data: Pointer to the the cpio archive or a header inside
+ * @len:Remaining length of the cpio based on data pointer
+ * @nextoff:When a matching file is found, this is the offset from the
+ * beginning of the cpio to the beginning of the next file, not
the
+ * matching file itself. It can be used to iterate through the
cpio
+ * to find all files inside of a directory path.
*
- * @return: struct cpio_data containing the address, length and
- * filename (with the directory path cut off) of the found file.
- * If you search for a filename and not for files in a directory,
- * pass the absolute path of the filename in the cpio and make sure
- * the match returned an empty filename string.
+ * @return: struct cpio_data containing the address, length and
+ * filename (with the directory path cut off) of the found file.
+ * If you search for a filename and not for files in a directory,
+ * pass the absolute path of the filename in the cpio and make
sure
+ * the match returned an empty filename string.
*/
struct cpio_data __init find_cpio_data(const char *path, void *data,
- size_t len, long *offset)
+ size_t len, long *nextoff)
{
const size_t cpio_header_len = 8*C_NFIELDS - 2;
- struct cpio_data cd = { NULL, 0 };
+ struct cpio_data cd = { NULL, 0, };
const char *p, *dptr, *nptr;
unsigned int ch[C_NFIELDS], *chp, v;
unsigned char c, x;
@@ -129,17 +130,17 @@ struct cpio_data __init find_cpio_data(const char *path,
void *data,
if ((ch[C_MODE] 017) == 010
ch[C_NAMESIZE] = mypathsize
!memcmp(p, path, mypathsize)) {
- *offset = (long)nptr - (long)data;
+ *nextoff = (long)nptr - (long)data;
if (ch[C_NAMESIZE] - mypathsize = MAX_CPIO_FILE_NAME) {
printk(
File %s exceeding MAX_CPIO_FILE_NAME [%d]\n,
p, MAX_CPIO_FILE_NAME);
}
- if (ch[C_NAMESIZE] - 1 /* includes \0 */ == mypathsize)
{
- cd.data = (void *)dptr;
- cd.size = ch[C_FILESIZE];
- return cd; /* Found it! */
- }
+ strlcpy(cd.name, p + mypathsize, MAX_CPIO_FILE_NAME);
+
+ cd.data = (void *)dptr;
+ cd.size = ch[C_FILESIZE];
+ return cd; /* Found it! */
}
len -= (nptr - p);
p = nptr;
diff --git a/xen/include/xen/earlycpio.h b/xen/include/xen/earlycpio.h
index 85d144a..16d9404 100644
--- a/xen/include/xen/earlycpio.h
+++ b/xen/include/xen/earlycpio.h
@@ -6,6 +6,7 @@
struct cpio_data {
void *data;
size_t size;
+ char name[MAX_CPIO_FILE_NAME];
};
struct cpio_data find_cpio_data(const char *path, void *data, size_t len,
--
1.7.10.4
Bug#789798: grub-installer: add option to _not_ install to UEFI boot order
On Wed, 2015-06-24 at 16:02 +0100, Ian Campbell wrote: +# Should we avoid installing/registering GRUB in NVRAM? + db_input low grub-installer/no-nvram || [ $? -eq 30 ] + db_go || exit 10 + db_get grub-installer/no-nvram + if [ $RET = true ]; then + grub_install_params=$grub_install_params --no-nvram + # Make sure this happens on upgrades too + $chroot $ROOT 'debconf-set-selections' EOF +grub-installer/no-nvram boolean true +EOF + fi Reminder to self: As it stands this last bit is bogus. I need to arrange for there to be a similar grub2/no-nvram question in grub itself and set that here not the grub-installer one. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789798: [RFR] New grub-installer-template
Hello l10n-english, In http://bugs.debian.org/789798 I've proposed a new debconf question for grub-installer (part of d-i which handles installing grub on those platforms which use it as a bootloader). The question is low priority and I would normally expect it to be used via preseeding, nonetheless some review of the wording would be appreciated. I've already applied the tweak suggested by Steve in the bug to the text below. Here it is: Template: grub-installer/no-nvram Type: boolean Default: false # :sl4: _Description: Avoid adding GRUB to Firmmware NVRAM configuration? By default GRUB will be registered into NVRAM on platforms where this is required. e.g. UEFI Boot Manager or OpenFirmware boot device. . This is sometimes not desirable, e.g. for systems which PXE boot and chainload instead and do not want the firmware configuration adjusted. Answering no here will avoid making such adjustments. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789798: grub-installer: add option to _not_ install to UEFI boot order
On Mon, 2015-06-29 at 14:12 +0100, Steve McIntyre wrote: diff --git a/debian/grub-installer.templates b/debian/grub-installer.templates index e294afb..e5d090b 100644 --- a/debian/grub-installer.templates +++ b/debian/grub-installer.templates @@ -285,3 +285,15 @@ _Description: Force GRUB installation to the EFI removable media path? installing GRUB there will make that operating system temporarily unbootable. GRUB can be manually configured later to boot it if necessary. + +Template: grub-installer/no-nvram +Type: boolean +Default: false +# :sl4: +_Description: Avoid adding GRUB to Firmmware NVRAM configuration? + By default GRUB will be registered into NVRAM on platforms where this is + required. e.g. UEFI Boot Manager or OpenFirmware boot device. + . + This is sometimes not desirable, e.g. for systems which PXE boot and chainload + instead and do not want the firmware configuration adjusted. Answering no here + will avoid make such adjustments. s/make such/making such/ ? Yes, that is much better, thanks. I suppose I ought to run this by the English i18n list too. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789798: [RFR] New grub-installer-template
On Tue, 2015-06-30 at 10:28 +0100, Philip Hands wrote: Ian Campbell i...@debian.org writes: Hello l10n-english, In http://bugs.debian.org/789798 I've proposed a new debconf question for grub-installer (part of d-i which handles installing grub on those platforms which use it as a bootloader). The question is low priority and I would normally expect it to be used via preseeding, nonetheless some review of the wording would be appreciated. I've already applied the tweak suggested by Steve in the bug to the text below. Here it is: Template: grub-installer/no-nvram Type: boolean Default: false # :sl4: _Description: Avoid adding GRUB to Firmmware NVRAM configuration? By default GRUB will be registered into NVRAM on platforms where this is required. e.g. UEFI Boot Manager or OpenFirmware boot device. . This is sometimes not desirable, e.g. for systems which PXE boot and chainload instead and do not want the firmware configuration adjusted. Answering no here will avoid making such adjustments. There seems to be a double negative here. The parameter is 'no-nvram' so I'd expect 'True' to indicate that one should avoid touching the NVRAM, whereas the text says: Answering _no_ here will avoid making such adjustments. I think that no should be yes. Indeed, checking the code: +# Should we avoid installing/registering GRUB in NVRAM? + db_input low grub-installer/no-nvram || [ $? -eq 30 ] + db_go || exit 10 + db_get grub-installer/no-nvram + if [ $RET = true ]; then + grub_install_params=$grub_install_params --no-nvram + # Make sure this happens on upgrades too + $chroot $ROOT 'debconf-set-selections' EOF +grub-installer/no-nvram boolean true +EOF + fi I did seem to mean yes. Also, the and do not want the firmware configuration adjusted. seems a bit redundant, given the preceding not desirable. How about: Ocasionally this is not desired (e.g. on systems that PXE boot and then chainload). Answering yes here will leave NVRAM untouched. Sounds good. BTW Is yes actually the right thing to say here? Or should one say setting the option or some such, so it works with GUIs that present this as a tick-box, say. I'll assume this is a question to the list since I have no idea... (it does sound sensible though). I'd also make the device at the end of the first paragraph be devices instead. Sure. Thanks for the review! Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790343: ITP: lua-udev -- udev library for the Lua language
Package: wnpp Severity: wishlist Owner: Ian Campbell i...@debian.org * Package name: lua-udev Version : 0.2 Upstream Author : dodo dodo.the.l...@gmail.com * URL : https://github.com/dodo/lua-udev * License : Expat Programming Lang: Lua, C Description : udev library for the Lua language This package contains the Lua udev library, that allows one to interact with udev from the Lua language. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790075: msr-tools: Silently accepts unknown arguments and provides an answer
Package: msr-tools Version: 1.3-2 Severity: wishlist Tags: upstream Dear Maintainer, I tried to use rdmsr to read a particular MSR using: # rdmsr MSR_K8_TOP_MEM2 Thinking that if it didn't know what MSR_K8_TOP_MEM2 was it would produce an error and I could look up the proper number. Instead it said 0 which was a plausible answer and so I carried on. However it turns out that it actually read whatever MSR strtoul(MSR_K8_TOP_MEM2, NULL, 0) produces, which is unlikely to be the MSR which was wanted. It would be great if there could be some sanity checking of the input and/or the error checks on the strtoul. The strtoul(3) manpage suggests setting errno=0 before calling strtoul and then checking for no-zero errno afterwards, since 0 is a legitimate converstion result. ` Thanks, Ian. -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages msr-tools depends on: ii libc6 2.19-18 msr-tools recommends no packages. msr-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789798: grub-installer: add option to _not_ install to UEFI boot order
Package: grub-installer Version: 1.124 Severity: wishlist Tags: patch I have a need to repeatedly install Debian from PXE on systems which are UEFI only (arm64 as it happens but I think all of the below applies to x86 UEFI too). When we want to actually boot the installed OS we chainload from the PXE grub.efi to the one on the ESP (using grub-installer/force-efi-extra-removable for simplicity, but that's by the by, I think). This is for automated testing which does a fresh install before most tests. The problem is that during install Debian inserts itself into the UEFI boot order _before_ the PXE entry, this happens via grub-installer.udeb - grub-install (from the main grub deb) - efibootmgr -c. This means that when we come to want to regroove the box it won't boot from PXE. grub-install offers an option to avoid this (--no-nvram) which is passed by grub-installer under some very specific circumstances (known broken hardware) but it would be very useful if this was a pre-seedable option so it could be used in circumstances such as the above as well. The attached patch adds a preseedable grub-installer/no-nvram (heavily inspired by the grub-installer/force-efi-extra-removable option) which forces the --no-nvram option to be used. I've tested this by rebuilding the Jessie installer with a patched version of grub-installer. The English text could probably do with some review on the appropriate list. Thanks, Ian. -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) commit 3f74e51b6a10253d4fe598a1bf83a3d21783b0be Author: Ian Campbell i...@hellion.org.uk Date: Fri Jun 19 15:17:40 2015 +0100 Add preseedable option to allow avoiding installation to NVRAM. (Closes: #xx) diff --git a/debian/changelog b/debian/changelog index cf6fda2..47a679c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +grub-installer (1.124) UNRELEASED; urgency=medium + + * Add preseedable option to allow avoiding installation to NVRAM. +(Closes: #xx) + + -- Ian Campbell i...@debian.org Fri, 19 Jun 2015 15:16:47 +0100 + grub-installer (1.123) unstable; urgency=medium [ Updated translations ] diff --git a/debian/grub-installer.templates b/debian/grub-installer.templates index e294afb..e5d090b 100644 --- a/debian/grub-installer.templates +++ b/debian/grub-installer.templates @@ -285,3 +285,15 @@ _Description: Force GRUB installation to the EFI removable media path? installing GRUB there will make that operating system temporarily unbootable. GRUB can be manually configured later to boot it if necessary. + +Template: grub-installer/no-nvram +Type: boolean +Default: false +# :sl4: +_Description: Avoid adding GRUB to Firmmware NVRAM configuration? + By default GRUB will be registered into NVRAM on platforms where this is + required. e.g. UEFI Boot Manager or OpenFirmware boot device. + . + This is sometimes not desirable, e.g. for systems which PXE boot and chainload + instead and do not want the firmware configuration adjusted. Answering no here + will avoid make such adjustments. diff --git a/grub-installer b/grub-installer index 777b3b2..ee186d2 100755 --- a/grub-installer +++ b/grub-installer @@ -813,6 +813,18 @@ grub2/force_efi_extra_removable boolean true EOF fi +# Should we avoid installing/registering GRUB in NVRAM? + db_input low grub-installer/no-nvram || [ $? -eq 30 ] + db_go || exit 10 + db_get grub-installer/no-nvram + if [ $RET = true ]; then + grub_install_params=$grub_install_params --no-nvram + # Make sure this happens on upgrades too + $chroot $ROOT 'debconf-set-selections' EOF +grub-installer/no-nvram boolean true +EOF + fi + if [ $ARCH = powerpc/chrp_pegasos ] ; then # nvram is broken here grub_install_params=$grub_install_params --no-nvram
Bug#788689: u-boot: Please add support for Tegra (Jetson TK1)
On Sun, 2015-06-21 at 08:31 -0700, Vagrant Cascadian wrote: On 2015-06-14, Ian Campbell wrote: Attached is a patch to enable support for the Jetson Tegra K1 board via a new u-boot-tegra package. It is based on the experimental-2015.07 branch of git. I can push it myself if you prefer but I thought I'd best have it reviewed first. Looks fine to me. Feel free to commit it! Thanks, will do (maybe not until the weekend though). One question this brings up, though: According to wikipedia, there is also a 64-bit variant; would that use a different u-boot? I _think_ (and I'm only 90% sure) that the 64-bit SoC is called the Tegra X1, rather than K1. I'm not aware yet of a 64-bit dev board with this SoC though I suppose there will be something eventually. All the u-boot packages are marked multi-arch: same, but if there's the possibility of both an armhf and amd64 u-boot-tegra package containing different builds, maybe we'll need to reconsider how to handle multi-arch with u-boot packaging... Hrm, so u-boot-tegra:armhf and u-boot-tegra:arm64 cannot be installed at the same time? even if the files which they contain do not overlap? They shouldn't contain overlapping files[0] which I thought was enough to allow multiple arches to be installed. [0] or at least I think it's unlikely any 64-bit board will be called precisely jetson-tk1 (-tx1, maybe...) I'm not entirely happy with the requirement (documented in the README) to use L4T to do the flashing but I've not yet worked out a fully working alternative (I think something must be possible using some combination of tegracrm and cbotimage both of which are in Debian, but I've not figured out the exact steps yet). You could perhaps include a TODO item in the README (or a separate TODO file); that might stir someone else to submit improved docs... A good idea, thanks. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788911: qcontrol for QNAP TS-221 in Jessie
Source: qcontrol Version: 0.5.4-2 On Mon, 2015-06-15 at 17:39 -0400, Martin Michlmayr wrote: * Adam Ward cay...@internode.on.net [2015-06-15 11:24]: Is this supported ? If not, what needs to be done to get support into qcontrol ? The TS-221 should work without any problems. Did you experience a problem with it? Ian, maybe we need something like the following: Indeed, filing into the BTS so I don't forget. diff --git a/README b/README index 0de0456..3c8dae2 100644 --- a/README +++ b/README @@ -3,7 +3,7 @@ see https://gitorious.org/qcontrol/ Supported devices: - QNAP TS-109, TS-109 II, TS-209 and TS-209 II (ts209) - QNAP TS-409 and TS-409U (ts409) - - QNAP TS-110, TS-119, TS-210, TS-219 and TS-219P (ts219) - - QNAP TS-410, TS-410U, TS-419P and TS-419U (ts41x) + - QNAP TS-11x, TS-12x, HS-210, TS-21x and TS-22x (ts219) + - QNAP TS-41x and TS-42x (ts41x) - Synology Diskstation and Rackstation (synology) diff --git a/debian/control b/debian/control index 5d08cef..f6530eb 100644 --- a/debian/control +++ b/debian/control @@ -19,10 +19,10 @@ Description: hardware control for QNAP Turbo Station devices presses or temperature, with events triggering actions defined in the configuration file. . - Supported devices at this time are the QNAP TS-109, TS-110, TS-119, - TS-209, TS-210, TS-219, TS-219P, TS-409, TS-409U, TS-410, TS-410U, - TS-419P and TS-419U but the code is extensible so more devices may - be added in future releases. + Currently supported devices are the QNAP TS-109, QNAP TS-11x, + QNAP TS-12x, QNAP TS-209, QNAP HS-210, QNAP TS-21x, QNAP TS-22x, + QNAP TS-409, QNAP TS-409U, QNAP TS-41x, QNAP TS-42x and Synology + Diskstation and Rackstation. Package: qcontrol-udeb Section: debian-installer diff --git a/debian/qcontrol.1 b/debian/qcontrol.1 index 1ef6de0..942523b 100644 --- a/debian/qcontrol.1 +++ b/debian/qcontrol.1 @@ -18,10 +18,10 @@ Note: the current version does not have a real daemon mode. Caution is therefore advised when using qcontrol as a real daemon to monitor and control a device. .PP -Currently supported devices are the QNAP TS-109, QNAP TS-110, QNAP TS-119, -QNAP TS-209, QNAP TS-210, QNAP TS-219, QNAP TS-219P, QNAP TS-409, QNAP -TS-409U, QNAP TS-410, QNAP TS-410U, QNAP TS-419P and QNAP TS-419U but -support for additional devices may be added in future releases. +Currently supported devices are the QNAP TS-109, QNAP TS-11x, QNAP TS-12x, +QNAP TS-209, QNAP HS-210, QNAP TS-21x, QNAP TS-22x, QNAP TS-409, QNAP +TS-409U, QNAP TS-41x, QNAP TS-42x and Synology Diskstation and Rackstation. +Support for additional devices may be added in future releases. .SH BASIC USAGE Normally a control process will be started when the system is booted. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788782: Need to add DTB settings for non-DTB Freescale MX53 LOCO Board too
On Sun, 2015-06-14 at 23:27 +0100, Steve McIntyre wrote: Package: flash-kernel Version: 3.35 Severity: important Looking at the settings for the two different stanzas for imx53, they're quite different for no good reason that I can see: Probably just that it's not immediately obvious that QSB==Loco so whoever added it missed it. The obvious fix is to clone the settings from the first stanza here to the second. We actually support multiple Machine fields per stanza, for just this so of case. I've merged them into a single (hopefully correct) entry (patch below). I wasn't totally sure about moving the obsolete mx5 kernel flavour over, but it seems harmless enough. It's also worth checking any *other* supported machine types for the same bug. I had a look and nothing jumped out at me. This also *really* needs to be back-ported to stable! Agreed. So I can tell SRM if so -- do we use the LOCO as a buildd board still? Ian. diff --git a/db/all.db b/db/all.db index a348f0d..f41aac6 100644 --- a/db/all.db +++ b/db/all.db @@ -131,7 +131,8 @@ Required-Packages: u-boot-tools Bootloader-Sets-Incorrect-Root: yes Machine: Freescale i.MX53 Quick Start Board -Kernel-Flavors: armmp +Machine: Freescale MX53 LOCO Board +Kernel-Flavors: armmp mx5 DTB-Id: imx53-qsb.dtb DTB-Append-From: 3.12 Boot-DTB-Path: /boot/dtb @@ -142,14 +143,6 @@ Boot-Initrd-Path: /boot/uInitrd Required-Packages: u-boot-tools Bootloader-Sets-Incorrect-Root: no -Machine: Freescale MX53 LOCO Board -Kernel-Flavors: armmp mx5 -U-Boot-Kernel-Address: 0x70008000 -U-Boot-Initrd-Address: 0x0 -Boot-Kernel-Path: /boot/uImage -Boot-Initrd-Path: /boot/uInitrd -Required-Packages: u-boot-tools - Machine: Genesi Efika Smartbook Kernel-Flavors: armmp mx5 U-Boot-Kernel-Address: 0x90008000 diff --git a/debian/changelog b/debian/changelog index f732bff..ef9dcc4 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +flash-kernel (3.43) UNRELEASED; urgency=medium + + * Combine i.MX53 QSB and LOCO board entries, they are the same thing and the +LOCO variant was missing DTB information. (Closes: #788782) + + -- Ian Campbell i...@debian.org Mon, 15 Jun 2015 19:04:31 +0100 + flash-kernel (3.42) unstable; urgency=medium * Only install bootscripts relevant to the arch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788689: u-boot: Please add support for Tegra (Jetson TK1)
Source: u-boot
Version: 2014.10+dfsg1-5
Severity: wishlist
Tags: patch
Hello Vagrant,
Attached is a patch to enable support for the Jetson Tegra K1 board via a new
u-boot-tegra package. It is based on the experimental-2015.07 branch of git. I
can push it myself if you prefer but I thought I'd best have it reviewed first.
I'm not entirely happy with the requirement (documented in the README) to use
L4T to do the flashing but I've not yet worked out a fully working alternative
(I think something must be possible using some combination of tegracrm and
cbotimage both of which are in Debian, but I've not figured out the exact steps
yet).
Cheers,
Ian.
-- System Information:
Debian Release: 8.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500,
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
From 7a667f75db13d80e68179554f344774132c4a7fd Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@debian.org
Date: Sun, 7 Jun 2015 22:40:20 +0100
Subject: [PATCH] Add support for Tegra Jetson TK-1
---
debian/control| 15 +++
debian/targets| 3 +++
debian/u-boot-tegra.README.Debian | 13 +
debian/u-boot-tegra.install | 2 ++
debian/u-boot-tegra.lintian-overrides | 11 +++
5 files changed, 44 insertions(+)
create mode 100644 debian/u-boot-tegra.README.Debian
create mode 100755 debian/u-boot-tegra.install
create mode 100644 debian/u-boot-tegra.lintian-overrides
diff --git a/debian/control b/debian/control
index 1433227..292241d 100644
--- a/debian/control
+++ b/debian/control
@@ -36,6 +36,21 @@ Description: A boot loader for imx systems
.
This package includes boot loaders for various imx platforms.
+Package: u-boot-tegra
+Architecture: armhf
+Multi-Arch: same
+Depends: ${misc:Depends}
+Breaks: u-boot ( 2014.10~rc2+dfsg1-2~)
+Replaces: u-boot ( 2014.10~rc2+dfsg1-2~)
+Description: A boot loader for tegra systems
+ Das U-Boot is a cross-platform bootloader for embedded systems,
+ used as the default boot loader by several board vendors. It is
+ intended to be easy to port and to debug, and runs on many
+ supported architectures, including PPC, ARM, MIPS, x86, m68k,
+ NIOS, and Microblaze.
+ .
+ This package includes boot loaders for various tegra platforms.
+
Package: u-boot-omap
Architecture: armhf
Multi-Arch: same
diff --git a/debian/targets b/debian/targets
index ab1e2e4..95f2d84 100644
--- a/debian/targets
+++ b/debian/targets
@@ -44,6 +44,9 @@ armhf imx usbarmory u-boot.imx
# Robert Nelson robertcnel...@gmail.com
armhf imx wandboard u-boot.img spl/u-boot-spl.bin SPL
+# Ian Campbell i...@debian.org
+armhf tegra jetson-tk1 u-boot-dtb-tegra.bin
+
# Vagrant Cascadian vagr...@debian.org
# Andrew M.A. Cater amaca...@galactic.demon.co.uk
armhf omap am335x_boneblack u-boot.img spl/u-boot-spl.bin MLO
diff --git a/debian/u-boot-tegra.README.Debian b/debian/u-boot-tegra.README.Debian
new file mode 100644
index 000..3d5d79f
--- /dev/null
+++ b/debian/u-boot-tegra.README.Debian
@@ -0,0 +1,13 @@
+== Installation ==
+
+At this point, you must install U-Boot to flash yourself from a host
+system using the Linux_For_Tegra tools.
+
+sudo ./flash.sh -L /usr/lib/u-boot/jetson-tk1/u-boot-dtb-tegra.bin jetson-tk1 mmcblk1p1
+
+It seems that L4T R19.3.0 is currently required (image does not boot
+if flashed with L4T R21.X).
+
+== U-Boot environment tools ==
+
+fw_printenv / fw_setenv read /etc/fw_env.config for configuration.
diff --git a/debian/u-boot-tegra.install b/debian/u-boot-tegra.install
new file mode 100755
index 000..15b8ab9
--- /dev/null
+++ b/debian/u-boot-tegra.install
@@ -0,0 +1,2 @@
+#!/bin/sh
+debian/bin/u-boot-install-targets tegra
diff --git a/debian/u-boot-tegra.lintian-overrides b/debian/u-boot-tegra.lintian-overrides
new file mode 100644
index 000..3884f10
--- /dev/null
+++ b/debian/u-boot-tegra.lintian-overrides
@@ -0,0 +1,11 @@
+
+# There are no file conflicts across architectures for u-boot, as each
+# target is only installed on a single architecture. In theory, some
+# targets could be built on multiple architectures, but could instead install
+# the package for the architecture needed.
+u-boot-tegra [armhf]: arch-dependent-file-not-in-arch-specific-directory usr/lib/u-boot/jetson-tk1/uboot.elf
+
+# These bootloaders need to be statically linked.
+u-boot-tegra [armhf]: statically-linked-binary usr/lib/u-boot/jetson-tk1/uboot.elf
+
+u-boot-tegra: description-synopsis-starts-with-article
--
2.1.4
Bug#788532: grub-efi-ia32-bin should be shipped on install DVD
Control: reassign -1 debian-cd
This is actually the responsibility of the debian-cd package,
reassigning.
On Fri, 2015-06-12 at 15:17 +0200, Gregor Riepl wrote:
Package: grub-efi-ia32-bin
Version: 2.02~beta2-22
Severity: important
Tags: d-i
Dear Maintainer,
When installing Debian 8 on a system with a x86_64 CPU, but with a 32bit UEFI,
debian-installer correctly identifies the system as requiring a 32bit EFI
Grub,
and thus tries to install grub-efi-ia32-bin.
However, this package is not contained on the amd64 installation DVD,
requiring
an active internet connection to get the package from a package server. This
may not always be possible, for example when the network hardware is not
supported by the installed Linux kernel and no alternative network connection
is available.
Please add this package to the installation DVD so an internet connection is
not required during installation.
Thank you.
-- Package-specific info:
*** WARNING grub-setup left core.img in filesystem
*** BEGIN /proc/mounts
/dev/dm-0 / ext4 rw,noatime,discard,errors=remount-ro,data=ordered 0 0
/dev/sda1 /boot vfat
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro
0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/disk/by-id/ata-SAMSUNG_MZ7TD256HAFV-000L7_S16GNEAD601136
(hd1) /dev/disk/by-id/usb-SanDisk_Cruzer_Pattern_3109330F0440D127-0:0
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ ${next_entry} ] ; then
set default=${next_entry}
set next_entry=
save_env next_entry
set boot_once=true
else
set default=0
fi
if [ x${feature_menuentry_id} = xy ]; then
menuentry_id_option=--id
else
menuentry_id_option=
fi
export menuentry_id_option
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod fat
set root='hd0,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1
--hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 --hint='hd0,gpt1' 200E-9FE4
else
search --no-floppy --fs-uuid --set=root 200E-9FE4
fi
font=/grub/unicode.pf2
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=C
insmod gettext
fi
terminal_output gfxterm
if [ ${recordfail} = 1 ] ; then
set timeout=-1
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod fat
set root='hd0,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1
--hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 --hint='hd0,gpt1' 200E-9FE4
else
search --no-floppy --fs-uuid --set=root 200E-9FE4
fi
insmod png
if background_image /grub/.background_cache.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload=${1}
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-c4db752c-876c-403f-9197-ccf5f677265f' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod fat
set root='hd0,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1
--hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 --hint='hd0,gpt1' 200E-9FE4
else
search --no-floppy --fs-uuid --set=root
Bug#788459: /usr/sbin/iucode-tool: Please install to /usr/bin
Package: iucode-tool Version: 1.1.1-1 Severity: wishlist File: /usr/sbin/iucode-tool As well as loading firmware etc iucode-tool is useful for unpacking and repacking firmware blobs and converting between the various formats, which does not require root privileges. For example in our automated test system at work it is used as part of the test controller infrastructure to prepare things to be installed on the host, this does not run as root. I think this binary could therefore be moved to /usr/bin. Thanks, Ian. -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages iucode-tool depends on: ii libc6 2.19-18 Versions of packages iucode-tool recommends: ii intel-microcode 3.20150121.1 iucode-tool suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788221: flash-kernel: Cubietruck failed to boot with flash-kernel 3.41
On Tue, 2015-06-09 at 23:35 +0200, Karsten Merker wrote:
if test -e ${device} ${partition} ${pathprefix}vmlinuz-${kvers}
^^
Ah yes, well spotted, thanks.
I'd switched my system to use the generic script as an experiment (it
worked) and then forgotten to switch it back.
I tried the obvious change though and it doesn't seem to have helped :-(
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788221: flash-kernel: Cubietruck failed to boot with flash-kernel 3.41
On Wed, 2015-06-10 at 09:07 +0100, Ian Campbell wrote: I'll cook something up. I pushed to git which WFM with bootscr.sunxi on Cubietruck as well as bootscr.uboot-generic both with and without fdtfile being set on Jetson. Please take a look, I'll upload tonight unless one of you spots an issue. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788221: flash-kernel: Cubietruck failed to boot with flash-kernel 3.41
On Wed, 2015-06-10 at 08:41 +0100, Ian Campbell wrote:
I tried the obvious change though and it doesn't seem to have helped :-(
It looks like the || construct from #78307 used to handle fallback
for the DTB on platforms without ${fdtfile} doesn't work as expected.
The chain stops after loading the first dtb, I think because || turns
out to be higher precedence that . i.e. it is
( load kernel load fdtfile ) || (load dtb load ramdisk boot )
and not
load kernel ( load fdtfile || load dtb ) load ramdisk boot
as required.
My Jetson (my other test system) doesn't set ${fdtfile}, so it falls
back ok to loading the second one and then continues.
_But_ if I set fdtfile on Jetson then it works, but I think it is
falling back to the non-versioned case which the generic version tries
if the versioned one fails.
u-boot's scripting language doesn't seem to understand () nor {}. I
think something using test to see if fdtfile is set might be required
here.
I'll cook something up.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788221: flash-kernel: Cubietruck failed to boot with flash-kernel 3.41
Control: tag -1 +moreinfo
On Tue, 2015-06-09 at 22:12 +0800, Zhang Jingqiang wrote:
I didn't connect to its serial port to find the error message as it is
not convenience, but if
you really need that, I will find some time to unpack the box and check that.
I'm afraid that since this works for me on Cubietruck that will be
necessary.
As well as the boot log it would be interesting to see the logs from
running flash-kernel too.
[...]
-- Configuration Files:
/etc/flash-kernel/db changed:
Boot-Device: /dev/mmcblk0p1
Machine: Cubietech Cubietruck
Kernel-Flavors: armmp-lpae
Boot-Script-Path: /boot/boot.scr
DTB-Id: sun7i-a20-cubietruck.dtb
U-Boot-Script-Name: bootscr.sunxi
Required-Packages: u-boot-tools
Why have you modified this from the default?
In particular setting Boot-Device is not normally necessary when the
device can boot from /boot (as a CT can), and since it is the same
device as your root appears to be (judging from the below) it is likely
to cause strangeness (e.g. mounting the device twice).
Have you customised anything else, e.g. the u-boot boot environment
perhaps?
Ian.
-- debconf information:
* flash-kernel/linux_cmdline: console=ttyS0,115200 hdmi.audio=EDID:0
disp.screen0_output_mode=EDID:1280x1024p60 root=/dev/mmcblk0p1 rootwait
panic=10 ${extra}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783074: flash-kernel: improvements to uboot-generic bootscript
On Sun, 2015-06-07 at 09:36 -0700, Vagrant Cascadian wrote:
On 2015-06-07, Ian Campbell wrote:
On Mon, 2015-05-04 at 12:01 -0700, Vagrant Cascadian wrote:
I can confirm that wandboard, cubox-i and hummingboard all default to
console=ttymxc0, and several other boards by grepping through u-boot's
include/configs. Some actually do setenv bootargs
console=ttymxc0,${baudrate} before their various boot commands.
If you prefer a more specific comment, maybe Workaround lack of
baudrate included with console on various iMX systems (e.g. wandboard,
cubox-i, hummingboard). An exhaustive list might prove more trouble
than it's worth. :)
For sure!
I was thinking about this some more and it occurred to me that
console=ttymxc0 (or indeed any console=ttyFOO) ought really to be
inheriting the existing baud rate etc settings from the bootloader and
Just Work(tm).
It defaults to 9600 baud (u-boot defaults to 115200), and consequently
the serial console looks like gibberish.
That lead me to drivers/tty/serial/imx.c:imx_console_get_options() in
the kernel which is called if no options are given.
That code has been there since the beginning of git history. Did you try
with just console=ttymxc0 and it didn't work? (Sorry if this is a silly
question, I think many people don't realise the baud etc is optional so
it never gets tried).
If you've tried without and it doesn't work then either that code isn't
called when I think, or it is broken. In either case I'm not too
inclined to investigate further than does console=ttymxc0 work and if
not then apply that bit of the patch.
I haven't investigated the kernel code, but my experience shows that
without specifying the baud rate it defaults to 9600.
9600 baud seems a bit antiquated at this point... :)
Absolutely. I really think you've found a kernel bug though, the code
looks very much like it is trying to read the baud rate from the HW if
it is enabled. I can't see by inspection why it is not working. Maybe
u-boot disables the uart before booting the kernel?
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781742: initramfs-tools use of triggers and DPKG_MAINTSCRIPT_PACKAGE
(this conversation really should have been going to the flash-kernel clone in #781882 and not to the original upgrade-report bug in #781742, I've adjusted CC and moved the original to BCC) On Thu, 2015-05-07 at 15:04 +0100, Ian Campbell wrote: Resending with a more obvious subject. The workaround I describe in the final paragraph does seem to work, but I'm not sure that's the best way to go. So I've been mulling this over for a while and I'm afraid the conclusion I've eventually reached is that if the initramfs has been regenerated then we really ought to be writing it to flash too, since otherwise we risk leaving the system in an unbootable state. I think this risk is already somewhat present in the gap between some package's update and the initramfs trigger but adding another delay between the initramfs trigger and the flash-kernel trigger is certainly widening it. This may even be the logic behind initramfs clobbering $DPKG_MAINTSCRIPT_PACKAGE for all I know. I think if there is anything to be done here it would be to investigate reducing the number of times the initramfs is regenerated in the first place. Thanks for the report, it was certainly worth investigating and considering. I'm closing the cloned bug against flash-kernel with this message, I'll leave it up to the initramfs-tools maintainers (or others) if they want to reclone the original bug (where all the actual useful info is) into something. Ian. On Mon, 2015-05-04 at 15:31 +0100, Ian Campbell wrote: (CC initramfs-tools@packages, context is flash-kernel invocation not being deferred via triggers during upgrade and ultimately running several times in a dist-upgrade) On Sat, 2015-04-04 at 10:49 +0100, Ian Campbell wrote: At first glance it seems like invocations via the initramfs-tools hooks are not being deferred. This is because initramfs-tools.postinst contains: # Regenerate initramfs whenever we go to dpkg state `installed' if [ x$1 != xtriggered ]; then # this activates the trigger, if triggers are working update-initramfs -u else # force it to actually happen DPKG_MAINTSCRIPT_PACKAGE='' update-initramfs -u fi and flash-kernel uses [ -n $DPKG_MAINTSCRIPT_PACKAGE ] when deciding to defer to a trigger. So the invocations of flash-kernel via /etc/initramfs/post-update.d/flash-kernel end up never being deferred. I don't think initramfs-tools is wrong to do this per-se, but it does mean that anything hooked off the post-update.d hooks cannot reliably use triggers (dpkg-trigger uses $DPKG_MAINTSCRIPT_PACKAGE itself). flash-kernel itself does something similar, but instead of manipulating DPKG_MAINTSCRIPT_PACKAGE it instead sets FLASH_KERNEL_NOTRIGGER=1 and keys off that. It seems like the best solution would a patch to switch initramfs-tools to a similar scheme, would such a patch be accepted? If not then I will arrange for /etc/initramfs/post-update.d/flash-kernel to signal to f-k somehow that triggers should be used despite the lack of DPKG_MAINTSCRIPT_PACKAGE. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783074: flash-kernel: improvements to uboot-generic bootscript
On Mon, 2015-05-04 at 12:01 -0700, Vagrant Cascadian wrote:
The changelog says some imx systems, do you have a list I could drop
in a comment or should I just say #Workaround lack of console on
someIMX systems?
I can confirm that wandboard, cubox-i and hummingboard all default to
console=ttymxc0, and several other boards by grepping through u-boot's
include/configs. Some actually do setenv bootargs
console=ttymxc0,${baudrate} before their various boot commands.
If you prefer a more specific comment, maybe Workaround lack of
baudrate included with console on various iMX systems (e.g. wandboard,
cubox-i, hummingboard). An exhaustive list might prove more trouble
than it's worth. :)
For sure!
I was thinking about this some more and it occurred to me that
console=ttymxc0 (or indeed any console=ttyFOO) ought really to be
inheriting the existing baud rate etc settings from the bootloader and
Just Work(tm).
That lead me to drivers/tty/serial/imx.c:imx_console_get_options() in
the kernel which is called if no options are given.
That code has been there since the beginning of git history. Did you try
with just console=ttymxc0 and it didn't work? (Sorry if this is a silly
question, I think many people don't realise the baud etc is optional so
it never gets tried).
If you've tried without and it doesn't work then either that code isn't
called when I think, or it is broken. In either case I'm not too
inclined to investigate further than does console=ttymxc0 work and if
not then apply that bit of the patch.
(I'm going to apply the other two aspects now)
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783074: flash-kernel: improvements to uboot-generic bootscript
On Mon, 2015-05-04 at 12:01 -0700, Vagrant Cascadian wrote:
The kernel versioning its also make it possible to use a kernel without
relying on the various vmlinuz, initrd, dtb smlinks being valid, or for
troubleshooting an alternate version.
What do you think about wrapping the load in a for kver in -${kvers '';
do and loading e.g. ${prefix}vmlinuz${kver}. IOW making it so that it
will try the suffixed version first but fallback to the symlinks if that
fails?
I like the idea, but the for loop implementation seems to ignore '', ,
' ' or in the loop... I'm not sure how to get it to respect an empty
value.
In the end I'm going to go with just duplicating the entire block with
and without the kvers, which is a bit unsatisfactory but the best I
could manage with the syntax available.
I'm also planning to use:
if test -n ${fk_kvers}; then
fk_kvers='@@KERNEL_VERSION@@'
fi
(and then fk_kvers throughout)
Which should allow for a very rudimentary form of picking which kernel
you wanted by setenv fk_kvers FOO; boot (e.g. to boot older versions
in an emergency).
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783074: flash-kernel: improvements to uboot-generic bootscript
On Sun, 2015-06-07 at 10:27 +0100, Ian Campbell wrote:
On Mon, 2015-05-04 at 12:01 -0700, Vagrant Cascadian wrote:
The changelog says some imx systems, do you have a list I could drop
in a comment or should I just say #Workaround lack of console on
someIMX systems?
I can confirm that wandboard, cubox-i and hummingboard all default to
console=ttymxc0, and several other boards by grepping through u-boot's
include/configs. Some actually do setenv bootargs
console=ttymxc0,${baudrate} before their various boot commands.
If you prefer a more specific comment, maybe Workaround lack of
baudrate included with console on various iMX systems (e.g. wandboard,
cubox-i, hummingboard). An exhaustive list might prove more trouble
than it's worth. :)
For sure!
I was thinking about this some more and it occurred to me that
console=ttymxc0 (or indeed any console=ttyFOO) ought really to be
inheriting the existing baud rate etc settings from the bootloader and
Just Work(tm).
That lead me to drivers/tty/serial/imx.c:imx_console_get_options() in
the kernel which is called if no options are given.
That code has been there since the beginning of git history. Did you try
with just console=ttymxc0 and it didn't work? (Sorry if this is a silly
question, I think many people don't realise the baud etc is optional so
it never gets tried).
If you've tried without and it doesn't work then either that code isn't
called when I think, or it is broken. In either case I'm not too
inclined to investigate further than does console=ttymxc0 work and if
not then apply that bit of the patch.
Actually, the way you've structured the conditions it's utterly harmless
even if it turns out not to be needed, so I committed this bit too.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787229: [Pkg-xen-devel] Bug#787229: xen-hypervisor-4.4-amd64: xl command hangs on Dell R720
I'm afraid I don't know what may or may not have happened to your installation, just that this fake-start-stop-daemon thing is very likely interfering with the operation of Xen by not actually starting daemons. I suggest you try asking somewhere like the debian-users list to see if anyone there knows what this thing is or what to do about it. Ian. On Tue, 2015-06-02 at 15:22 +0200, Benoît Tonnerre wrote: Hi, Thanks for your answer. During the Debian jessie installation, I had a problem at grub step. The os-prober part was stuck : grub was at 66 % (os-prober tried to browse all the VM on LVM partitions) After more than 15 minutes, os-prober seems to be stuck, so I rebooted the server. I had to boot in rescue mode, then, reinstalled grub and modified it to add GRUB_DISABLE_OS_PROBER=true. It seems it solved the problem, I was able to boot the server. Maybe there are some missing things in my Debian installation ? Do you want me to fill an other bug report (concerning the installation problem ?) I have not this problem with Debian Wheezy installation. Thanks for your time and for your help. Benoit 2015-05-30 10:31 GMT+02:00 Ian Campbell i...@debian.org: On Sat, 2015-05-30 at 05:23 +0200, Benoît Tonnerre wrote: mai 29 23:20:50 jango xen[1150]: Starting Xen daemons: xenfs xenstored mai 29 22:20:50 jango xen[1150]: Warning: Fake start-stop-daemon called, doing nothing. mai 29 23:20:50 jango xen[1150]: Warning: Fake start-stop-daemon called, doing nothing. This suggests that the xen daemons and in particular xenstored are not actually running, the result of which will be any command which tries to talk to xenstored (like xl list, most xl commands and the xenstore-write seen in the status log) will never get an answer and will appear to hang. I don't know what Fake start-stop-daemon is, but it sounds like the root of your problems. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783718: linux-image-3.16.0-4-kirkwood: Regression: mv_cesa crypto driver fails a self-test
Control: fixed -1 4.0.4-1 Control: fixed -1 3.18.5-1~exp1 On Sun, 2015-05-31 at 01:54 +0100, Ben Hutchings wrote: On Fri, 2015-05-29 at 13:27 +0200, JM wrote: I have tested linux-image-kirkwood-4.0.0-2 from unstable and I can confirm that this bug has been fixed upstream and mv_cesa passes kernel self-tests. Unfortunately I can't see any relevant changes to the driver or tests between 3.16 and 4.0. Neither can I, nor to arch/arm/mach-mvebu/ or arch/arm/boot/dts/kirkwood*, which were long shots anyway :-( The upgrade from 3.16 to 4.0 will have also have involved a switch from board file to DTS based support. It would be conceivable that v3.16 board files were broken and that DTS would work, but I booted v3.16 with a DTB and it still fails as described. http://thread.gmane.org/gmane.linux.kernel.cryptoapi/6720/focus=6730 looks interesting. One of the two issues (non-zero nbytes to callback) was fixed in v3.3 but the other one (dcaches) doesn't look to have been fixed, at least not in a way which is obvious in the logs. Those two did make me wonder about some of the scatter list and bounds value stuff I see in git log v3.16..v4.0 -- drivers/crypto from Leonidas S. Barbosa, which seemed to hit in v3.19, but unfortunately all the v3.19's we uploaded FTBFS on armel so I can't easily check. https://buildd.debian.org/status/logs.php?pkg=linuxarch=armel shows v3.18 built which might be worth trying since it would split the upstream commit range about in half at least, although it is still a big range. I tried 3.18.5-1~exp1 and it didn't have the errors, so it seems like it was already fixed by then. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786716: Debian on Allwinner A20 installation report (fail)
Control: reassign -1 src:linux 4.0.2-1 On Sun, 2015-05-24 at 19:08 +, Mitch Winkle wrote: 1. Older versions detect ethernet network and begin installer download which fails because of mis-matched kernel modules. 2. Newer version have no ethernet support for the Cubieboard2 (sunxi-emac) and so there is no way to download the installer. Used dailies from 2015-05-08 forward. All dailies newer than 05-12-2015 fail on loading ethernet driver. This seems to correspond with the switch in sid from 3.16.0-4-armmp to 4.0.0-1-armmp. An initrd with 3.16.0-4-armmp won't work against the archive any longer due to version mismatch. The initrd from http://d-i.debian.org/daily-images/armhf/20150514-00:36/netboot/initrd.gz (which I think should be the first bad one) contains: /lib/modules/4.0.0-1-armmp/kernel/drivers/net/ethernet/allwinner/sun4i-emac.ko So the issue isn't that the module is missing altogether. I booted the SD image from that date on a Cubieboard2 and indeed sun4i-emac.ko is not automatically loaded and loading it by hand causes no device to appear. Looking around in /proc/device-tree it seems that the _gmac_ device is marked enabled and the _emac_ device is disabled. The driver for this is stmmac. Using the image from 20150512-00:43 this is the driver which is loaded, so sunxi-emac is a red-herring I think. stmmac.ko is also included in the 20150514-00:36 but also isn't autoloaded and loading manually doesn't help. Ah, it seems like we also need a new module, stmmac-platform.ko, to be included in the nic-modules udeb. I'll arrange for that to be in the next kernel upload. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786936: [Pkg-xen-devel] Bug#786936: xen-hypervisor-4.4-amd64: Upgrade dom0 from wheezy to jessie on Dell R610 results in dom0 unaccessible with xen_netback issue
Control: reassign -1 linux-image-3.16.0-4-amd64 3.16.7-ckt9-3~deb8u1 On Wed, 2015-05-27 at 08:44 +1000, Andrew Perry wrote: Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9 Severity: critical Justification: breaks the whole system Dear Maintainer, After upgrading the R610 server from Debian 7 to Debian 8, the dom0 becomes unresponsive via ssh after an hour or so, although the domUs still remain accessible. Initially we thought it may be a disk space issue on / or /boot so action was taken to increase those petition sizes but it has no effect. We get the following trace in /var/log/syslog: May 26 09:18:59 servername kernel: [31526.937788] BUG: unable to handle kernel paging request at c90013a4b158 May 26 09:18:59 servername kernel: [31526.937798] IP: [a06802a0] xenvif_get_ethtool_stats+0x50/0x80 [xen_netback] This appears to be a dom0 kernel issue rather than a hypervisor issue, I've (hopefully) reassigned accordingly. While we work out a proper fix, since the error appears to be in the ethtool stats gathering code I suspect that there might be a workaround which would be to disable whichever code in dom0 (a monitoring daemon like nagios perhaps?) is calling this path. May 26 09:18:59 servername kernel: [31526.937807] PGD b243c067 PUD b243d067 PMD 8a56c067 PTE 0 May 26 09:18:59 servername kernel: [31526.937813] Oops: [#1] SMP May 26 09:18:59 servername kernel: [31526.937817] Modules linked in: dm_snapshot dm_bufio binfmt_misc xt_tcpudp xt_physdev iptable_filter ip_tables x_tables xen_netback xen_blkback xen_gntdev xen_evtchn xenfs xen_privcmd nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi bridge stp llc nls_utf8 nls_cp437 vfat fat joydev intel_powerclamp coretemp crc32_pclmul ghash_clmulni_intel ttm evdev aesni_intel ipmi_devintf iTCO_wdt iTCO_vendor_support aes_x86_64 drm_kms_helper acpi_power_meter dcdbas lrw gf128mul glue_helper tpm_tis tpm drm i2c_algo_bit ablk_helper processor i2c_core lpc_ich ipmi_si ipmi_msghandler i7core_edac thermal_sys cryptd mfd_core button psmouse pcspkr serio_raw shpchp wmi edac_core loop autofs4 ext4 crc16 mbcache jbd2 dm_mod hid_generic usbhid hid sg sr_mod cdrom ses sd_mod enclosure ata_generic crc32c_intel lpfc crc_t10dif crct10dif_generic ehci_pci uhci_hcd crct10dif_pclmul ata_piix ehci_hcd scsi_transport_fc libata megaraid_sas scsi_tgt usbcore scsi_mod usb_common crct10dif_common bnx2 May 26 09:18:59 servername kernel: [31526.937917] CPU: 0 PID: 1311 Comm: snmpd Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1 May 26 09:18:59 servername kernel: [31526.937922] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.4.0 07/23/2013 May 26 09:18:59 servername kernel: [31526.937927] task: 88008a86a250 ti: 880002b4c000 task.ti: 880002b4c000 May 26 09:18:59 servername kernel: [31526.937931] RIP: e030:[a06802a0] [a06802a0] xenvif_get_ethtool_stats+0x50/0x80 [xen_netback] May 26 09:18:59 servername kernel: [31526.937939] RSP: e02b:880002b4fd70 EFLAGS: 00010283 May 26 09:18:59 servername kernel: [31526.937942] RAX: c90013a14f38 RBX: 0230f940 RCX: 92008ea28c88 May 26 09:18:59 servername kernel: [31526.937946] RDX: 88008ecadc00 RSI: c90013a4b190 RDI: 88008da7c000 May 26 09:18:59 servername kernel: [31526.937949] RBP: 880002b4fe10 R08: a06827e0 R09: 0006 May 26 09:18:59 servername kernel: [31526.937953] R10: 0010ebb8 R11: 0246 R12: 0005 May 26 09:18:59 servername kernel: [31526.937957] R13: 88008da7c000 R14: a0682640 R15: 88008ecadc00 May 26 09:18:59 servername kernel: [31526.937965] FS: 7f93bcc9e700() GS:8800b2a0() knlGS: May 26 09:18:59 servername kernel: [31526.937969] CS: e033 DS: ES: CR0: 8005003b May 26 09:18:59 servername kernel: [31526.937973] CR2: c90013a4b158 CR3: 899ff000 CR4: 2660 May 26 09:18:59 servername kernel: [31526.937977] Stack: May 26 09:18:59 servername kernel: [31526.937979] 814225f1 000400114813 7fff3fff32a8 May 26 09:18:59 servername kernel: [31526.937985] 880002b4ff18 001d3fff32a0 880002b4fde0 814039a6 May 26 09:18:59 servername kernel: [31526.937990] 0005001d 8805 81420455 7fff3fff3280 May 26 09:18:59 servername kernel: [31526.937995] Call Trace: May 26 09:18:59 servername kernel: [31526.938003] [814225f1] ? dev_ethtool+0x921/0x1ac0 May 26 09:18:59 servername kernel: [31526.938009] [814039a6] ? ___sys_recvmsg+0x136/0x2a0 May 26 09:18:59 servername kernel: [31526.938014] [81420455] ? netdev_run_todo+0x55/0x2f0 May 26 09:18:59 servername kernel:
Bug#787229: [Pkg-xen-devel] Bug#787229: xen-hypervisor-4.4-amd64: xl command hangs on Dell R720
On Sat, 2015-05-30 at 05:23 +0200, Benoît Tonnerre wrote: mai 29 23:20:50 jango xen[1150]: Starting Xen daemons: xenfs xenstored mai 29 22:20:50 jango xen[1150]: Warning: Fake start-stop-daemon called, doing nothing. mai 29 23:20:50 jango xen[1150]: Warning: Fake start-stop-daemon called, doing nothing. This suggests that the xen daemons and in particular xenstored are not actually running, the result of which will be any command which tries to talk to xenstored (like xl list, most xl commands and the xenstore-write seen in the status log) will never get an answer and will appear to hang. I don't know what Fake start-stop-daemon is, but it sounds like the root of your problems. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786936: [PATCHv2 1/3] xen-netback: return correct ethtool stats
Control: fixed -1 4.0-1~exp1
On Wed, 2015-03-04 at 11:14 +, David Vrabel wrote:
Use correct pointer arithmetic to get the pointer to each stat.
I think this incorrect arithmetic was also responsible for the crash
reported in http://bugs.debian.org/786936 which was using the resulting
stray pointer.
I'll add the fix to our kernel but: David (Miller) could we also have it
queued for stable please?
Thanks.
Reasoning:
IP: [a06802a0] xenvif_get_ethtool_stats+0x50/0x80 [xen_netback]
(gdb) disas xenvif_get_ethtool_stats+0x50
Dump of assembler code for function xenvif_get_ethtool_stats:
0x5280 +0: callq 0x5285 xenvif_get_ethtool_stats+5
0x5285 +5: mov0x900(%rdi),%r9d
0x528c +12:mov$0x0,%r8
0x5293 +19:lea-0x1(%r9),%r10d
0x5297 +23:imul $0x36258,%r10,%r10
0x529e +30:xchg %ax,%ax
0x52a0 +32:test %r9d,%r9d
0x52a3 +35:je 0x52f8 xenvif_get_ethtool_stats+120
0x52a5 +37:movzwl (%r8),%esi
0x52a9 +41:mov0x8f8(%rdi),%rcx
0x52b0 +48:lea0x0(,%rsi,8),%rax
0x52b8 +56:shl$0x6,%rsi
0x52bc +60:sub%rax,%rsi
0x52bf +63:lea(%rcx,%rsi,1),%rax
0x52c3 +67:lea0x36258(%rcx,%r10,1),%rcx
0x52cb +75:add%rcx,%rsi
0x52ce +78:xor%ecx,%ecx
0x52d0 +80:add0x36220(%rax),%rcx
0x52d7 +87:add$0x36258,%rax
0x52dd +93:cmp%rsi,%rax
0x52e0 +96:jne0x52d0 xenvif_get_ethtool_stats+80
0x52e2 +98:add$0x22,%r8
0x52e6 +102: mov%rcx,(%rdx)
0x52e9 +105: add$0x8,%rdx
0x52ed +109: cmp$0x0,%r8
0x52f4 +116: jne0x52a0 xenvif_get_ethtool_stats+32
0x52f6 +118: repz retq
0x52f8 +120: xor%ecx,%ecx
0x52fa +122: jmp0x52e2 xenvif_get_ethtool_stats+98
End of assembler dump.
(gdb) list *xenvif_get_ethtool_stats+0x50
0x52d0 is in xenvif_get_ethtool_stats
(/build/linux-RGM_Ed/linux-3.16.7-ckt9/drivers/net/xen-netback/interface.c:349).
... and in the Debian kernel interface.c:349 is the accum += line from
the patch.
Ian.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/net/xen-netback/interface.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index f38227a..3aa8648 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -340,12 +340,11 @@ static void xenvif_get_ethtool_stats(struct net_device
*dev,
unsigned int num_queues = vif-num_queues;
int i;
unsigned int queue_index;
- struct xenvif_stats *vif_stats;
for (i = 0; i ARRAY_SIZE(xenvif_stats); i++) {
unsigned long accum = 0;
for (queue_index = 0; queue_index num_queues; ++queue_index) {
- vif_stats = vif-queues[queue_index].stats;
+ void *vif_stats = vif-queues[queue_index].stats;
accum += *(unsigned long *)(vif_stats +
xenvif_stats[i].offset);
}
data[i] = accum;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781886: qcontrol failure to start on boot sometimes (jessie, systemd?)
On Thu, 2015-05-28 at 17:28 +0200, sfr...@googlemail.com wrote: Hi, i've experienced the problem minutes ago after a d-u (qcontrol 0.5.4-2). And i found the problem: In /etc/qcontrol.conf i had the line register(evdev, /dev/input/by-path/platform-gpio-keys-event, 408, restart_button, 133, media_button) while: # ls /dev/input/by-path/ platform-gpio_keys-event You see the difference? gpio_keys vs gpio-keys. Thanks, but I don't think this is the issue seen by the original reporter. The device name change happened with the transition from board file to DTB which was done post Jessie / pre-Stretch while the original issue here was Jessie with Jessie versions of the kernel and qcontrol and is/was a race with the device creation vs. qcontrold starting on systemd systems. For Stretch I will likely change qcontrol to look for both names and I'll arrange for that version to also be in jessie-backports alongside the newer kernel. Ian. So i changed the entry in the conf file and it works now. Hope this helps. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784905: jessie-pu: (preapproval) package qcontrol/0.5.4-1
On Thu, 2015-05-28 at 18:55 +0100, Adam D. Barratt wrote: Control: tags -1 + confirmed On Sun, 2015-05-10 at 13:45 +0100, Ian Campbell wrote: I'd like to fix #781886 qcontrol failure to start on boot sometimes (jessie, systemd?) in Jessie. The issue is that when running in LSB compat mode the devices may not have been created before the initscript runs. This isn't noticed under sysvinit because there is an implicit (or perhaps explicit) udev settle somewhere earlier on. However the proper fix (enabling full systemd support) is IMHO too intrusive for a stable update (see below for the full patch in case you disagree). So instead I would like to upload a workaround: Assuming that the workaround has been tested on jessie, please go ahead. Thanks I've just uploaded 0.5.4-1+deb8u1 to jessie, debdiff below. I've tested it locally on Jessie, although the issue is intermittent. I should probably have though to mention this before, but src:qcontrol does generate udebs, which are included in the d-i initrds. The change in question does not impact them at all since they don't start the daemon and use qcontrol in one-shot mode only. I've CCd Kibi just in case this is an issue. Ian. diff -Nru qcontrol-0.5.4/debian/changelog qcontrol-0.5.4/debian/changelog --- qcontrol-0.5.4/debian/changelog 2014-04-11 17:40:46.0 +0100 +++ qcontrol-0.5.4/debian/changelog 2015-05-30 13:35:38.0 +0100 @@ -1,3 +1,11 @@ +qcontrol (0.5.4-1+deb8u1) jessie; urgency=medium + + * Wait for necessary devices to appear before starting. +(Closes: #781886). This works around an issue exposed by systemd LSB +compatibility mode. Proper systemd support will come later. + + -- Ian Campbell i...@debian.org Sat, 30 May 2015 13:35:21 +0100 + qcontrol (0.5.4-1) unstable; urgency=low * New upstream release 0.5.4. diff -Nru qcontrol-0.5.4/debian/qcontrol.qcontrold.init qcontrol-0.5.4/debian/qcontrol.qcontrold.init --- qcontrol-0.5.4/debian/qcontrol.qcontrold.init 2013-10-20 10:12:28.0 +0100 +++ qcontrol-0.5.4/debian/qcontrol.qcontrold.init 2015-05-30 13:35:38.0 +0100 @@ -38,6 +38,11 @@ case $1 in start) + # Ensure that /dev/input/by-path/platform-gpio-keys-event has + # arrived. Under systemd LSB compatibility mode it may not + # have yet. + udevadm settle + log_daemon_msg Starting qcontrol daemon qcontrol if start-stop-daemon --start --quiet --oknodo --exec $DAEMON -- -d; then log_end_msg 0 signature.asc Description: This is a digitally signed message part
Bug#786882: debian-installer: FTBFS on arm64: can't find dtbs
On Tue, 2015-05-26 at 14:16 +0200, Cyril Brulebois wrote: [...] There seems to be some dtb dance here, and I think the src:linux's having relocated the dtbs under subdirectories is responsible for the FTBFS. Comparing some recent kernels: | kibi@wodi:/tmp/linux-kernel$ debdiff binary-kernel-image-3.16.0-4-arm64-di/kernel-image-3.16.0-4-arm64-di_3.16.7-ckt9-2_arm64.udeb binary-kernel-image-4.0.0-1-arm64-di/kernel-image-4.0.0-1-arm64-di_4.0.2-1_arm64.udeb | [The following lists of changes regard files as different if they have | different names, permissions or owners.] | | Files in second .deb but not in first | - | -rw-r--r-- root/root /lib/modules/4.0.0-1-arm64/modules.builtin | -rw-r--r-- root/root /lib/modules/4.0.0-1-arm64/modules.order | -rw-r--r-- root/root /usr/lib/linux-image-4.0.0-1-arm64/apm/apm-mustang.dtb | -rw-r--r-- root/root /usr/lib/linux-image-4.0.0-1-arm64/arm/foundation-v8.dtb | -rw-r--r-- root/root /usr/lib/linux-image-4.0.0-1-arm64/arm/juno.dtb | -rw-r--r-- root/root /usr/lib/linux-image-4.0.0-1-arm64/arm/rtsm_ve-aemv8a.dtb | | Files in first .deb but not in second | - | -rw-r--r-- root/root /lib/modules/3.16.0-4-arm64/modules.builtin | -rw-r--r-- root/root /lib/modules/3.16.0-4-arm64/modules.order | -rw-r--r-- root/root /usr/lib/linux-image-3.16.0-4-arm64/apm-mustang.dtb | -rw-r--r-- root/root /usr/lib/linux-image-3.16.0-4-arm64/foundation-v8.dtb | -rw-r--r-- root/root /usr/lib/linux-image-3.16.0-4-arm64/rtsm_ve-aemv8a.dtb → Besides the ABI bump, one can see apm/ and arm/ being introduced here. src:debian-installer likely needs to learn how to handle this. Upstream decided to structure things a bit more (by vendor). Sorry for not thinking of d-i when I fixed up the kernel packaging side. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786367: flash-kernel: support BeagleBone Black with u-boot 2015.04+
On Mon, 2015-05-25 at 03:37 +0200, Cyril Brulebois wrote: Hello, Vagrant Cascadian vagr...@debian.org (2015-05-20): Package: flash-kernel Version: 3.37 Severity: wishlist Tags: patch The version of u-boot in experimental, 2015.04+dfsg1-1 contains a patch to the u-boot environment to support distro_bootcmd, but is incompatible with the current bootscript in flash-kernel. The following patch should fix this by setting device, partition and image_locations variables using values provided by distro_bootcmd, falling back to the old default values. […] I intend to upload a newer version of u-boot to unstable sometime soonish, so it would be ideal if this patch could be included in flash-kernel before or at the same time as u-boot is uploaded to unstable. Uploading now looks good to me, but I don't want to stomp on anyone's toes. Ian, are you fine with my uploading a new version with these changes? Sure, go ahead. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785707: Add USB support for APM Mustang
On Sat, 2015-05-23 at 11:42 +0100, Ian Campbell wrote: Including a v3 which is slightly different to what has been posted here [...] So that's the one I intend to apply Looks like Ben a) already spotted there was a v3 and b) committed it to svn for both Sid and Jessie already, so I shall be doing no such thing! Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785707: Add USB support for APM Mustang
On Thu, 2015-05-21 at 20:33 +0100, Steve McIntyre wrote: On Thu, May 21, 2015 at 07:49:37PM +0100, Ian Campbell wrote: On Wed, 2015-05-20 at 07:53 +0100, Steve McIntyre wrote: Here's patch v2... Thanks. Has this been posted to anywhere upstream? Usual policy is that this should happen before we take it into our kernel. That will also give us something (i.e. an archive URL) to put in an Origin: header. I'm just pulling out a patch that Mark already sent upstream. Looking for the URL... It's sometimes a PITA that Google likes Debian lists and the BTS so much - most obvious links are just to this bug now! http://www.spinics.net/lists/arm-kernel/msg373699.html Thanks, the message id there led me to http://thread.gmane.org/gmane.linux.usb.general/117272 which has the whole thread. Including a v3 which is slightly different to what has been posted here so far: http://thread.gmane.org/gmane.linux.usb.general/117272/focus=118786 It uses dma_set_mask_and_coherent rather than individual calls to dma_set_coherent_mask then dma_set_mask, which the various feedback in the thread seems to indicate is more correct. So that's the one I intend to apply along with the Kconfig part of http://thread.gmane.org/gmane.linux.usb.general/117272/focus=118784 (post beer festival though I'm afraid ;-)) Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785707: Add USB support for APM Mustang
On Wed, 2015-05-20 at 07:53 +0100, Steve McIntyre wrote: Here's patch v2... Thanks. Has this been posted to anywhere upstream? Usual policy is that this should happen before we take it into our kernel. That will also give us something (i.e. an archive URL) to put in an Origin: header. We should probably apply this to the sid kernel as well as the jessie one. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
