Bug#724891: [debian-installer] debian-installer: Build firmware for the DNS-320/DNS-325
On Sun, 2014-06-22 at 20:15 +0200, Bastien ROUCARIES wrote: > On Tue, Jun 17, 2014 at 9:42 AM, Ian Campbell wrote: > > On Mon, 2014-06-16 at 23:33 +0200, Bastien ROUCARIES wrote: > >> Le 16 juin 2014 20:48, "Ian Campbell" a écrit : > >> > I understand what the mkdns323fw stuff is all about, but I'm wondering > >> > what the ext2 image is for, how does it fit in? > >> > >> An ext2 image need to solder a rs 232 console. It is a useful but need > >> hardware modification. Mkdns323fw does not need hardware modification. > > > > But does the mkdns323fw not work equally well whether or not you've made > > any hardware modifications? We'd really like to keep the number of > > images to a minimum unless absolutely necessary. It's simpler for users > > and maintainers alike if there is only one image per platform to think > > about/maintain/document/etc. > > Yes they work equally well. But flashing form dlink firmware is a one > way operation. I could not reflash from and thus reinstall from > scratch debian if needed. Even if you have soldered an rs232 console? Perhaps I just don't understand what the ext2 image you are referring to is. I had imaged it was some sort of thing containing the debian installer as a mechanism for injecting it into the system (a kind of backdoor into the factory firmware if you will). Do you actually mean a ready made debootstrapped Debian filesystem image? I don't think Debian typically provides the latter, just the tools to produce them. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1403682868.1829.46.ca...@dagon.hellion.org.uk
Bug#724891: [debian-installer] debian-installer: Build firmware for the DNS-320/DNS-325
On Sun, 2014-07-06 at 14:55 +0200, Bastien ROUCARIES wrote: > Dlink firmware does not work from rs232 console I'm afraid I still don't really understand what you mean. Are you using "rs232 console" to mean "with Debian already installed"? If so then is the purpose of this ext2 image to be able to relaunch the installer after Debian is already installed in order to reinstall Debian? Is it not possible to do this by cat'ting the relevant files into /dev/mtdblock* as with other similar platforms? Anyway, I think reinstalling Debian is a rather secondary use case and I don't think we need to be supplying (or, more importantly, maintaining) such an image by default. Best just to document how to make a suitable USB key IMHO. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404659282.11284.26.ca...@dagon.hellion.org.uk
Bug#751716: [debian-installer] Patch
On Mon, 2014-07-07 at 17:05 +0200, Martin Michlmayr wrote: > * Bastien ROUCARIES [2014-07-06 22:10]: > > >> You combine the kernel and the DTB in $(TEMP)/dns-320/vmlinuz-dns320. > > >> But then > > >> instead of using this file to generate the kernel.uboot, you use the > > >> original > > >> kernel. > > > > Corrected thank > > Looks good. I went to apply this but: mkdir -p ./tmp/kirkwood_network-console/dns-320 cat ./tmp/kirkwood_network-console/vmlinuz-3.14-1-kirkwood ./tmp/kirkwood_network-console/lib/kirkwood-dns320.dtb > ./tmp/kirkwood_network-console/dns-320/vmlinuz-dns320 mkimage -A arm -O linux -T kernel -C none -e 0x8000 -a 0x8000 -n "Debian kernel" -d ./tmp/kirkwood_network-console/dns-320/kernel ./tmp/kirkwood_network-console/dns-320/vmlinuz-dns320 /usr/bin/mkimage: Can't open ./tmp/kirkwood_network-console/dns-320/kernel: No such file or directory config/armel/kirkwood/network-console.cfg:9: recipe for target 'dns-320' failed Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404848355.11945.22.ca...@hastur.hellion.org.uk
Bug#751716: [debian-installer] Patch
On Tue, 2014-07-08 at 23:28 +0200, Bastien ROUCARIES wrote: > On Tue, Jul 8, 2014 at 9:39 PM, Ian Campbell wrote: > > On Mon, 2014-07-07 at 17:05 +0200, Martin Michlmayr wrote: > >> * Bastien ROUCARIES [2014-07-06 22:10]: > >> > >> You combine the kernel and the DTB in $(TEMP)/dns-320/vmlinuz-dns320. > >> > >> But then > >> > >> instead of using this file to generate the kernel.uboot, you use the > >> > >> original > >> > >> kernel. > >> > > >> > Corrected thank > >> > >> Looks good. > > > > I went to apply this but: > > > > mkdir -p ./tmp/kirkwood_network-console/dns-320 > > cat ./tmp/kirkwood_network-console/vmlinuz-3.14-1-kirkwood > > ./tmp/kirkwood_network-console/lib/kirkwood-dns320.dtb > > > ./tmp/kirkwood_network-console/dns-320/vmlinuz-dns320 > > mkimage -A arm -O linux -T kernel -C none -e 0x8000 -a 0x8000 -n > > "Debian kernel" -d ./tmp/kirkwood_network-console/dns-320/kernel > > ./tmp/kirkwood_network-console/dns-320/vmlinuz-dns320 > > /usr/bin/mkimage: Can't open ./tmp/kirkwood_network-console/dns-320/kernel: > > No such file or directory > > config/armel/kirkwood/network-console.cfg:9: recipe for target 'dns-320' > > failed > > My fault here updated version Thanks, pushed. It should show up in the dailies tomorrow. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404892688.11981.5.ca...@dagon.hellion.org.uk
Bug#751816: flash-kernel and dtb
On Fri, 2014-07-11 at 16:33 -0700, Vagrant Cascadian wrote:
> Control: tags 751816 patch
>
> On Tue, Jul 08, 2014 at 08:03:30PM +0100, Ian Campbell wrote:
> > I think the patch below resolves the worst issue and it works for me on
> > cubietruck.
> >
> > The more minor stuff mentioned in that report I'm not sure it is
> > actually worth worrying over. The main one seems to be
> > that /etc/default/flash-kernel:LINUX_KERNEL_CMDLINE is still populated
> > even on systems where there is no way at all for it to get used.
> >
> > Thoughts on that?
>
> Looks good to me.
Thanks. I'll try and find time to do an upload ASAP. I think I'll change
the "(Partially addresses #751816)" into a proper closes and leave the
other more minor issues alone unless/until they bite actual users.
> The only improvement I might suggest is deleting the line entirely if
> LINUX_KERNEL_CMDLINE isn't set, but that's a minor point. Would definitely
> like
> to see the updated flash-kernel hit jessie soon!
You mean the setenv line? I think "setenv bootargs ${bootargs} " should
be harmless enough.
Omitting it would be a bit tricky and would rely on me knowing more
about the supported feature set of each platforms shell or making
flash-kernel more complicated somehow. I don't think it's worth it, what
do you think?
Ian.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1405157220.11981.29.ca...@dagon.hellion.org.uk
Bug#751716: [debian-installer] Patch
On Sun, 2014-07-13 at 00:58 +0200, Bastien ROUCARIES wrote: > On Sun, Jul 13, 2014 at 12:14 AM, Martin Michlmayr wrote: > > * Bastien ROUCARIES [2014-07-12 19:05]: > >> Hi UImage is too big to get into mtd :S You said that it it is a > >> trimmed down version ? Any idea to trim more ? > > > > I believe we said the initramfs generated by initramfs-tools is > > trimmed down. How big is the uimage and how much space do you have? > > 5242880 byte or 5M The kirkwood kernel is just under 2MB, so there's no way the uImage could be 5M. This is enforced at kernel build time see linux/debian/config/armel/defines which has: [kirkwood_image] recommends: uboot-mkimage # SheevaPlug: 4194304 - 8 - 64 = 4194232 # QNAP TS-119/TS-219: 2097152 - 8 - 64 = 2097080 check-size: 2097080 Maybe we are talking about uInitrd/uRamdisk? > >> BTW it seems that this config need a serial console in order to set > >> ssh password. Do you have pointer about documentation of how to set it > >> without serial. I plan to document dns-320 on the wiki. > > > > Take a look at oldsys-preseed. You could just generate a dummy stanza > > that will do DHCP with a fallback IP address (instead of actually > > reading the network config from the device). I always thought that this was the default behaviour of the network-console flavour images, is it not? Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405237159.11981.56.ca...@dagon.hellion.org.uk
Bug#751716: [debian-installer] Patch
On Sun, 2014-07-13 at 12:26 +0200, Bastien ROUCARIES wrote: Sorry the delay, I was procrastinating on responding because I'm wasn't really sure what to suggest. > On Sun, Jul 13, 2014 at 9:39 AM, Ian Campbell wrote: > > On Sun, 2014-07-13 at 00:58 +0200, Bastien ROUCARIES wrote: > >> On Sun, Jul 13, 2014 at 12:14 AM, Martin Michlmayr wrote: > >> > * Bastien ROUCARIES [2014-07-12 19:05]: > >> >> Hi UImage is too big to get into mtd :S You said that it it is a > >> >> trimmed down version ? Any idea to trim more ? > >> > > >> > I believe we said the initramfs generated by initramfs-tools is > >> > trimmed down. How big is the uimage and how much space do you have? > >> > >> 5242880 byte or 5M How big is the current uImage you are building? Looking at other similar installer images I'm guessing it's a little over 5M, so I'm wondering how much space we need to be clawing back. You will probably need to take a look through debian-installer.git/build/pkg-lists/* and the resulting list of udebs which are included in this image to see if there is anything which can be dropped to save some space. It might also be useful to unpack the initrd and see if you can spot anything which is unnecessary. Given that the kernels can now (I think) handle xz compressed initrd perhaps that might also be something to investigate? > > I always thought that this was the default behaviour of the > > network-console flavour images, is it not? > > No it is not. It ask for hostaname and password for ssh I didn't know this. As Martin says though it looks like oldsys-preseed is the fix. Looks at the code it looks like even without the machine specific hooks it should be enough to preseed the networking (letting DHCP take precedence) and set a default password, but it will be aborting because it doesn't recognise the platform. So at a minimum you will need to make it recognise your platform allowing it to take the default actions, but since there is a stanza there for DNS-323 though you might want to consider adding full support for grabbing the existing firmware cfg for DNS-320 too. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405932019.21027.10.ca...@kazak.uk.xensource.com
Bug#758581: debian-installer: FTBFS on armhf/network-console: No library provides non-weak __aeabi_unwind_cpp_pr0
On Tue, 2014-08-19 at 00:34 +0200, Cyril Brulebois wrote:
> | -Object: ./tmp/network-console/tree/lib/libgcc_s.so.1-so-stripped
> […]
> | +1170 symbols, 38 unresolved
> | +Traceback (most recent call last):
> | + File "/usr/bin/mklibs", line 560, in
> | +raise Exception("No library provides non-weak %s" % name)
> | +Exception: No library provides non-weak __aeabi_unwind_cpp_pr0
>
> libgcc_s.so.1 comes from a gcc package, and there's been a gcc-4.9
> package in unstable for 2 days, which might match. But then I don't
> see any difference in package contents or symbols list for the
> libgcc1 packages between 1:4.9.1-5 and 1:4.9.1-7. I'm afraid I'm
> running out of the time to dig deeper into what's mklibs is after
> (possibly a _pic.a but I don't see any for libgcc_s). Having both
> a glibc and a gcc-4.9 upload in the said time window could explain
> this regression, as a wild guess.
The Internet(tm) seems to think that __aeabi_unwind_cpp_pr0 comes from
libunwind, but the wifi in this hotel is making it a rather slow job to
figure out what might be depending on that and/or whether there
is/should be a udeb for it, I'll try and investigate further though.
Interesting that only the network-console flavour is affected
> Could somebody from debian-arm@ (x-d-cc) check what's going on
> precisely and possibly forward the failure to the right place if
> d-i isn't the buggy package here?
>
> Thanks for your time.
>
> Mraw,
> KiBi.
>
>
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1408672231.17003.13.ca...@hellion.org.uk
Bug#758581: debian-installer: FTBFS on armhf/network-console: No library provides non-weak __aeabi_unwind_cpp_pr0
On Fri, 2014-08-22 at 05:26 +0200, Cyril Brulebois wrote: > Ian Campbell (2014-08-22): > > The Internet(tm) seems to think that __aeabi_unwind_cpp_pr0 comes from > > libunwind, but the wifi in this hotel is making it a rather slow job > > to figure out what might be depending on that and/or whether there > > is/should be a udeb for it, I'll try and investigate further though. > > > > Interesting that only the network-console flavour is affected > > Comparing netboot and network-console builds before the library > reduction phase leads to an interesting diff, which I'm not attaching > because I think that's not really needed, see below. > > > (BTW: There's a similar symbol in the kernel but I'm going to assume the > *.ko diff is totally irrelevant to the problem in mklibs…) Yes, I'm sure it is irrelevant. > Letting netboot go through, and grepping for that symbol, there's no > match in the resulting tree; on the contrary, network-console still gets > some: > | Binary file tmp/network-console/tree/lib/libcrypt.so.1-so-stripped matches > | Binary file tmp/network-console/tree/lib/libcrypt.so.1-so matches > | Binary file tmp/network-console/tree/lib/libc.so.6-so matches > > Interestingly, grepping for libcrypt.so in netboot shows no match, while > network-console has: > | Binary file tmp/network-console/tree/bin/gen-crypt matches > | Binary file tmp/network-console/tree/lib/libcrypt.so.1-so-stripped matches > | Binary file tmp/network-console/tree/lib/libcrypt.so.1-so matches > | Binary file tmp/network-console/tree/usr/sbin/sshd matches > > See? Both gen-crypt and sshd are only in the network-console image, and > apparently pulling libcrypt.so.1, which comes from libc: > | libc6:armhf: /lib/arm-linux-gnueabihf/libcrypt.so.1 > > Also in the tree, nm -D shows that this libcrypt.so.1-so* have: > | U __aeabi_unwind_cpp_pr0 > which is likely what mklibs barfs about. > > > Bottom line: FTBFS vs. non-FTBFS depending on image type is likely > explained by the differences in binaries included in each image; Agreed. > and > that FTBFS was likely introduced by a toolchain update which mklibs > doesn't exactly cope nicely with, yet. Possibly. One thing I'm confused about is that the symbol is apparently provided by libgcc_s.so.1 but that doesn't appears under tmp/network-console/ anywhere. But surely some other symbols from libgcc_s must be being used already. Running mklibs by hand in verbose mode AFAICT it is never even considering libgcc_s.so.1. Copying /lib/arm-linux-gnueabihf/libgcc_s.so.1 to tmp/network-console/tree/lib/ (which I'm sure is quite wrong...) doesn't work but it does cause mklibs to spit out some interesting debug: needed_symbols adding __aeabi_unwind_cpp_pr0, weak: False [...] present_symbols adding __aeabi_unwind_cpp_pr0@GCC_3.5@libgcc_s.so.1 [...] Exception: No library provides non-weak __aeabi_unwind_cpp_pr0 (the middle line is from calling mklibs-readelf --print-symbols-provided ./tmp/network-console/tree/lib/libgcc_s.so.1) Which made me wonder if the issue might be to do with symbol versioning somehow? > For the record, I'm listing below where the symbol is referenced (T in > libgcc_s.so.1, U elsewhere). Was it deliberate that this referenced the host (/lib etc) rather than the build tree? I've timed out for now, but I'll continue prodding as I have the chance... Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408911872.30706.31.ca...@hellion.org.uk
Bug#758581: debian-installer: FTBFS on armhf/network-console: No library provides non-weak __aeabi_unwind_cpp_pr0
On Sun, 2014-08-24 at 21:24 +0100, Ian Campbell wrote:
> I've timed out for now, but I'll continue prodding as I have the
> chance...
I caught up with Adam Conrad a debconf and he pointed out that __aeabi_*
are some weird internal ABI thing which doesn't actually indicate an
unresolved symbol. IOW they should be ignored, dpkg-shlibs does this too
(search for __aeabi_ in /usr/share/perl5/Dpkg/Shlibs/SymbolFile.pm)
Rebuilding the installer with mklibs patches as below seems to work, in
that I can "chroot tmp/network-console/tree/ /bin/sh" and then in the
chroot "/usb/sbin/sshd --help" runs and produces output. If the symbol
were actually required at runtime then this would have failed with some
sort of dynamic linker error.
This:
# LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux-armhf.so.3 /usr/sbin/sshd
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0xb6ddd000)
libutil.so.1 => /lib/libutil.so.1 (0xb6dcb000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6da9000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb6d6c000)
libc.so.6 => /lib/libc.so.6 (0xb6cc1000)
/lib/ld-linux-armhf.so.3 (0xb6f7c000)
libdl.so.2 => /lib/libdl.so.2 (0xb6cb)
indicates that the ssh binary is indeed using those libraries which
appear to depend on the problematic symbol.
What's not clear is why this is just occurring now. I suppose changes to
gcc/glibc or something have caused it to be exposed. I don't propose to
dig much deeper into that aspect (mostly on the basis that if
dpkg-shlibs does it mklibs should too).
So I think we should upload a new mklibs and have a new debian-installer
upload which buidld-deps on it.
Ian.
>From cf0887e69d4d150e240fa3770e03464ed79aa442 Mon Sep 17 00:00:00 2001
From: Ian Campbell
Date: Mon, 25 Aug 2014 02:22:15 +0100
Subject: [PATCH] Ignore all ARM EABI symbols (__aeabi_*)
---
debian/changelog | 7 +++
src/mklibs | 11 +++
2 files changed, 18 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index e9afd36..303e1c1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+mklibs (0.1.40) UNRELEASED; urgency=medium
+
+ * Ignore all ARM EABI symbols (__aeabi_*). These are artefacts of the ABI and
+not real symbols which need to be present.
+
+ -- Ian Campbell Mon, 25 Aug 2014 02:08:09 +0100
+
mklibs (0.1.39) unstable; urgency=medium
* Sort objects and libraries to reduce entropy in the output, which
diff --git a/src/mklibs b/src/mklibs
index d9b784b..1f3d60f 100755
--- a/src/mklibs
+++ b/src/mklibs
@@ -137,6 +137,14 @@ class UndefinedSymbol(Symbol):
super(UndefinedSymbol, self).__init__(name, version, library)
self.weak, self.library = weak, library
+def symbol_is_blacklisted(name):
+# The ARM Embedded ABI spec states symbols under this namespace as
+# possibly appearing in output objects.
+if name.startswith("__aeabi_"):
+return True
+
+return False
+
# Return undefined symbols in an object as a set of tuples (name, weakness)
def undefined_symbols(obj):
if not os.access(obj, os.F_OK):
@@ -148,6 +156,9 @@ def undefined_symbols(obj):
for line in output:
name, weak_string, version_string, library_string = line.split()[:4]
+if symbol_is_blacklisted(name):
+continue
+
weak = False
if weak_string.lower() == 'true':
weak = True
--
2.0.1
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1408930160.30706.40.ca...@hellion.org.uk
Re: Alpha install ISOs
On Mon, 2014-08-25 at 21:26 -0700, Bill MacAllister wrote: > [...] > E: Couldn't find any package by regex > 'usb-storage-modules-3.10-3-alpha-generic-di' > Seems like I need to create those packages for Alpha. How do I do that? Those should all come from the kernel packaging. I expect alpha already has a kernel and you just need to update the KERNEL_VERSION = 3.10-3 somewhere in the d-i tree to whatever the current kernel version is. Or perhaps even just to update your di tree to the latest git which ought to be pointing at the current kernel version already. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1409066555.28009.3.ca...@hellion.org.uk
Re: Alpha install ISOs
On Tue, 2014-08-26 at 14:44 -0700, Bill MacAllister wrote: > > --On August 26, 2014 at 4:22:35 PM +0100 Ian Campbell > wrote: > > > On Mon, 2014-08-25 at 21:26 -0700, Bill MacAllister wrote: > >> [...] > >> E: Couldn't find any package by regex > >> 'usb-storage-modules-3.10-3-alpha-generic-di' > > > >> Seems like I need to create those packages for Alpha. How do I do that? > > > > Those should all come from the kernel packaging. I expect alpha already > > has a kernel and you just need to update the KERNEL_VERSION = 3.10-3 > > somewhere in the d-i tree to whatever the current kernel version is. > > I think you are referring to the values in the config/alpha.cfg file. I set > the following values there: > > KERNELVERSION = 3.10-3-alpha-generic > KERNELMAJOR = 3.10 > > That is not the newest version, but it is the one that currently works on > alphas. Which archive/repo are you building against? Does it contain this version of the kernel? I don't see 3.10-3-alpha-generic in the debian-ports.org repo, which seems to have 3.14-2 and 3.15-trunk. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1409095153.28009.60.ca...@hellion.org.uk
Re: Alpha install ISOs
On Tue, 2014-08-26 at 19:13 -0700, Bill MacAllister wrote: > > --On August 27, 2014 at 12:19:13 AM +0100 Ian Campbell > wrote: > > > On Tue, 2014-08-26 at 14:44 -0700, Bill MacAllister wrote: > >> > >> --On August 26, 2014 at 4:22:35 PM +0100 Ian Campbell > >> wrote: > >> > >> > On Mon, 2014-08-25 at 21:26 -0700, Bill MacAllister wrote: > >> >> [...] > >> >> E: Couldn't find any package by regex > >> >> 'usb-storage-modules-3.10-3-alpha-generic-di' > >> > > >> >> Seems like I need to create those packages for Alpha. How do I do that? > >> > > >> > Those should all come from the kernel packaging. I expect alpha already > >> > has a kernel and you just need to update the KERNEL_VERSION = 3.10-3 > >> > somewhere in the d-i tree to whatever the current kernel version is. > >> > >> I think you are referring to the values in the config/alpha.cfg file. I > >> set > >> the following values there: > >> > >> KERNELVERSION = 3.10-3-alpha-generic > >> KERNELMAJOR = 3.10 > >> > >> That is not the newest version, but it is the one that currently works on > >> alphas. > > > > Which archive/repo are you building against? Does it contain this > > version of the kernel? > > http://ftp.debian-ports.org/debian > > > I don't see 3.10-3-alpha-generic in the debian-ports.org repo, which > > seems to have 3.14-2 and 3.15-trunk. > > I should have been more explicit in describing what I have tried. I > initially > tried specifying the 3.10-3 kernel and then tried again with the 3.14-2 > kernel. Both failed and the failures were different only in the version > number of the kernel. Here is the kernel specification I am using now: > > KERNELVERSION = 3.14-2-alpha-generic > KERNELMAJOR = 3.14 > > And here are the errors from the latest run: > > Building dependency tree... Done > E: Unable to locate package fat-modules-3.14-2-alpha-generic-di > E: Couldn't find any package by regex 'fat-modules-3.14-2-alpha-generic-di' Judging from ftp://ftp.debian-ports.org/debian/pool-alpha/main/l/linux/ (assuming you are building against debian-ports) the kernel isn't building any udebs for alpha. I've no idea why that should be, but you probably need to fix that first. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1409106316.28009.87.ca...@hellion.org.uk
Re: Network Console - Where sshd is started
On Wed, 2014-09-03 at 01:34 -0300, Daniel Gaspary wrote: > Hi, sorry if my doubt is too "noobish". > > I have been searching through the installer sources for the reference > to TERM_TYPE environment variable, where it's tested to be "network". > It is set in network-console package. > > What I would like to see is where and how the data is received from / > sent to sshd. I'm not entirely sure what you are asking but sshd is started from the postinst of the network-console udeb. WRT data sent/received it is via the usual kernel sockets interfaces. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1409728629.12977.3.ca...@dagon.hellion.org.uk
partman-auto: Differences between -efi and non-efi recipes
I was taking a look at EFI installer support for arm64 (reusing the recipes-amd64-efi) and came across something I'm not sure of. Part of the diff between recipes/atomic and recipes-amd64-efi/atomic is: -96 512 200% linux-swap +100% 512 200% linux-swap I expected the two to differ only in the presence of an ESP and related ways. Am I naive to expect there to be no other differences? The other recipes seem to differ in similar ways between EFI and non. The result was that on an ARM64 Foundation Model (8GB RAM, 4GB disk) I ended up with a 0.5G EFI System Partition (ESP), a 0.5G / and a 3.1G swap, which wasn't exactly what I wanted ;-) In particular the setting of the minimum size to 100% (size of RAM) rather than 96 is what has caused all my disk to be swap. I expect I'm a bit unusual in having a disk smaller than my RAM, so I can (and will) just deal with this locally but I thought I'd mention it in case someone thought it was a bigger problem. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1409814952.12977.24.ca...@dagon.hellion.org.uk
Bug#760904: installation-reports: no network on linkstation pro with jessie d-i
On Mon, 2014-09-08 at 22:35 -0700, Ryan Tandy wrote: > Booting a Wheezy image is successful and works. I installed Wheezy on > the Linkstation using the 7.6 netboot image and upgraded to Jessie > successfully, That includes having successfully booted the Jessie kernel judging from the dmesg below? I can see the corresponding lsmod below and looking at it I'm suspicious of mvmdio which is a new module needed for networking on some platforms. I can see it in the kirkwood udebs (installer pkg) but not the orion5xs one which could explain you issue. I've enabled it in the kernel package svn repo just now, but to test you'd need to wait for a new kernel upload and d-i daily using it. Ian. > lsmod: Module Size Used by > lsmod: hmac2425 0 > lsmod: sha1_generic1692 0 > lsmod: sha1_arm3318 0 > lsmod: ehci_orion 2718 0 > lsmod: ehci_hcd 36707 1 ehci_orion > lsmod: marvell 5905 0 > lsmod: sg 18802 0 > lsmod: orion_wdt 2661 0 > lsmod: mv_cesa10745 0 > lsmod: mv643xx_eth22134 0 > lsmod: mvmdio 3024 0 > lsmod: usbcore 137224 2 ehci_hcd,ehci_orion > lsmod: usb_common 1266 1 usbcore > lsmod: loop 14519 0 > lsmod: ipv6 291684 12 > lsmod: autofs419744 2 > lsmod: ext4 329145 2 > lsmod: crc16 1097 1 ext4 > lsmod: mbcache 4654 1 ext4 > lsmod: jbd2 62684 1 ext4 > lsmod: sd_mod 34640 4 > lsmod: crc_t10dif 948 1 sd_mod > lsmod: crct10dif_generic 1142 1 > lsmod: crct10dif_common1110 2 crct10dif_generic,crc_t10dif > lsmod: sata_mv24700 3 > lsmod: libata145076 1 sata_mv > lsmod: scsi_mod 133849 3 sg,libata,sd_mod -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410340652.8217.256.ca...@kazak.uk.xensource.com
Bug#760904: installation-reports: no network on linkstation pro with jessie d-i
On Wed, 2014-09-10 at 08:56 -0700, Ryan Tandy wrote: > On 10/09/14 02:17 AM, Ian Campbell wrote: > > I'm suspicious of mvmdio which is a new module needed for networking > > on some platforms. I can see it in the kirkwood udebs (installer pkg) > > but not the orion5xs one which could explain you issue. I've enabled it > > in the kernel package svn repo just now, but to test you'd need to wait > > for a new kernel upload and d-i daily using it. > > That makes sense, thanks! I'll keep an eye out for the next kernel > upload and report back. In the meantime if you could collect the lsmod with a Wheezy kernel for comparison we can check if there is anything else there which ought to be exposed to the installer. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410370087.13239.6.ca...@dagon.hellion.org.uk
Bug#760904: installation-reports: no network on linkstation pro with jessie d-i
On Wed, 2014-09-10 at 14:14 -0700, Ryan Tandy wrote: > On 10/09/14 10:28 AM, Ian Campbell wrote: > > In the meantime if you could collect the lsmod with a Wheezy kernel for > > comparison we can check if there is anything else there which ought to > > be exposed to the installer. > > Attaching dmesg and report-hw from wheezy and jessie for completeness. Thanks. The new networking related bits seem to be marvell.ko and mvmdio.ko. marvell.ko was already packaged in the right place and I added mvmdio.ko yesterday. I remain hopeful that will have solved your issue. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410429175.6166.53.ca...@kazak.uk.xensource.com
Re: Update on the daily builds
On Fri, 2014-09-12 at 17:14 +0200, Cyril Brulebois wrote: > - armhf fails because linux FTBFS there. Fixed in pkg-kernel svn. > - we don't have arm64 yet but I think Ian is actively working on having >the needed linux + debian-installer bits in shape, so having it built >daily isn't a big hindrance IMHO. FWIW I'm running daily builds locally and publishing the results at http://www.hellion.org.uk/debian/didaily/ I'm hoping to collar some folks next week (at the Linaro event) to get a daily build going on a more official system. > http://d-i.debian.org/daily-images/daily-build-overview.html Very nice! Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410536747.27902.16.ca...@kazak.uk.xensource.com
Bug#761514: [armhf/sunxi] [d-i daily 20140914] Cubietruck installation report (installation to MMC)
On Sun, 2014-09-14 at 17:25 +0200, Cyril Brulebois wrote: > Hi, > > Karsten Merker (2014-09-14): > > U-boot:u-boot 2014.10~rc2+dfsg1-1 from experimental > > [...] > > > Comments: > > - The installation was done in expert mode (debconf priority medium). > > - I selected Sid instead of Jessie as target suite as kernel 3.16 > > (required for installation on MMC) has not yet migrated to Jessie. > > - Partitioning was done using the "guided partitioning" option. > > I see you also need u-boot from experimental; I'm not sure it'll reach > sid + testing in time for the next release. Are you in touch with its > maintainer/do you his short term plans? Upstream 2014.10 is due out a few weeks before the Jessie freeze, I believe Vagrant is planning to keep track of the -rcs in experimental and hopefully get v2014.10 final into Jessie. Fingers crossed! Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410709544.11601.0.ca...@hastur.hellion.org.uk
Bug#762007: Kernel command line handling change breaks d-i user-params functionality
Package: debian-installer-utils
X-Debbugs-CC: debian-ker...@lists.debian.org
(CCing debian-kernel just FYI, since I don't think this can/should be
fixed with a kernel change, likewise filing against
debian-installer-utils and not the kernel even though a kernel change
introduced the breakage)
A recent change to the kernel[0] (from v3.15 onwards) has changed the
way the kernel handles its command line, such that it now ignores
anything passed after a "--" marker. This has broken d-i's own use of
that marker which was to separate options intended for the installer
only (before the marker) from those which are intended to be both
consumed by the d-i kernel and propagated to the final installation
(after the marker, returned by the user-params utility).
It used to be that you could do:
vmlinuz some/preseed=value -- console=ttyFOO
which would have the dual affect of having the kernel console (and hence
installer UI) run on ttyFOO and also, via grub-installer's use of
user-params, propagate the console=ttyFOO into the final grub config
(similarly for other bootloaders).
With the kernel change this no longer works -- the kernel doesn't put
its console on ttyFOO since it stops parsing at the --. So you get
silence on boot.
To get the old behaviour you need
vmlinuz some/preseed=value console=ttyFOO -- console=ttyFOO
which is pretty tedious.
Just using
vmlinuz some/preseed=value console=ttyFOO
doesn't propagate the console=ttyFOO to the installed system.
Since the kernel change was related to the "systemd abusing kernel
cmdline" debacle I'm not overly keen on raising this upstream and I
don't think that changing the kernel in a way which diverges from
upstream would not be the right approach here.
I don't know how widely used/documented/Supported this ability was, but
I thought e.g. the pxe and isolinux cfgs made use of it.
Not sure what we can do about this. Perhaps choose another separator
("=="?) and make user-params support both?
Ian.
[0]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51e158c12aca3c9ac63988611a97c05109b14dc9
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1410975910.23505.55.ca...@debian.org
Re: [RFC] d-i hd-media support for armhf
On Mon, 2014-09-22 at 00:17 +0200, Karsten Merker wrote:
(bit of an aside)
> diff --git a/build/boot/arm/bootscr.mainline_common
> b/build/boot/arm/bootscr.mainline_common
> new file mode 100644
> index 000..268eeba
> --- /dev/null
> +++ b/build/boot/arm/bootscr.mainline_common
This be a good starting point for something which could be added to
flash-kernel too as a default/generic boot script too.
Only wrinkle is the dependency on dtbs/${fdtfile}, but
http://lists.linaro.org/pipermail/cross-distro/2014-May/000676.html was
proposing something along those lines too, so perhaps I should just bite
the bullet and move them...
> @@ -0,0 +1,30 @@
> +# Bootscript using the new unified bootcmd handling
> +# introduced with u-boot v2014.10
> +
> +if test -n "${boot_targets}"; then
> + echo "Mainline u-boot / new-style environment detected."
> +else
> + echo "Non-mainline u-boot detected. This boot script uses the unified
> bootcmd"
> + echo "handling of mainline u-boot (>=v2014.10), which is not available on
> your"
> + echo "system. Please boot the installer manually."
> + exit 0
> +fi
> +
> +if test -z "${fdtfile}"; then
> + echo 'fdtfile environment variable not set. Aborting boot process.'
> + exit 0
> +fi
> +
> +if test ! -e ${devtype} ${devnum}:${bootpart} dtbs/${fdtfile}; then
> + echo "This installer medium does not contain a suitable device-tree file
> for"
> + echo "this system (${fdtfile}). Aborting boot process."
> + exit 0
> +fi
> +
> +setenv bootargs "${bootargs} console=${console}"
> +
> +load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} vmlinuz \
> +&& load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} dtbs/${fdtfile} \
> +&& load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} initrd.gz \
> +&& echo "Booting the Debian installer..." \
> +&& bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411497092.27559.28.ca...@hellion.org.uk
Bug#762618: debian-installer: amd64/i386 netboot/mini.iso has empty grub.cfg for EFI boot
Source: debian-installer Version: 20130613+deb7u2 Severity: normal While looking for an example to crib for arm64 I noticed that the amd64 mini.iso has a grub cfg (used when booting on EFI) which doesn't contain any menu entries. Booting on non-EFI would use the isolinux menus in the usual way. Looking at the code I expect this will apply to i386 too, although I've not checked. The netinst images build by debian-cd contain a grub.cfg which is autogenerated from the syslinux configuration. Confirmed by inspection for both current Wheezy and the Jessie dailies. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf armel Kernel: Linux 3.14-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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140923192926.5250.15281.report...@dagon.hellion.org.uk
Re: [RFC] d-i hd-media support for armhf
On Tue, 2014-09-23 at 12:02 -0700, Steve Langasek wrote:
> On Tue, Sep 23, 2014 at 07:31:32PM +0100, Ian Campbell wrote:
> > On Mon, 2014-09-22 at 00:17 +0200, Karsten Merker wrote:
>
> > (bit of an aside)
> > > diff --git a/build/boot/arm/bootscr.mainline_common
> > > b/build/boot/arm/bootscr.mainline_common
> > > new file mode 100644
> > > index 000..268eeba
> > > --- /dev/null
> > > +++ b/build/boot/arm/bootscr.mainline_common
>
> > This be a good starting point for something which could be added to
> > flash-kernel too as a default/generic boot script too.
>
> > Only wrinkle is the dependency on dtbs/${fdtfile}, but
> > http://lists.linaro.org/pipermail/cross-distro/2014-May/000676.html was
> > proposing something along those lines too, so perhaps I should just bite
> > the bullet and move them...
>
> Did that thread converge on a recommendation?
It appears not :-/
Thinking about it some more we don't really need this for the sort of
default boot script I was thinking about, just a dtb -> dtb-$uname
symlink to match the vmlinuz/initrd.img ones is sufficient given the
ability to supply our own boot.scr, and flash kernel can arrange that
regardless of the packaged location.
I notice that the Debian powerpc packages use the same /usr/lib path as
the arm ones, I don't have the knowledge to go messing around with that,
which makes me inclined to leave ARM alone too rather than diverge
across the arches.
> The linked wiki page still lists a set of options.
FWIW this new u-boot stuff include $fdtfile which is the file name, but
I don't think it includes (or cares about) the path to it.
> At the time of that thread, I recall that the proposed standardization of
> dtb locations was mostly not useful for the platforms I cared about because
> they were going to be placed in locations that wouldn't help u-boot find
> them in order to pass them to the kernel.
Anywhere under /boot would do, wouldn't it? Debian and Ubuntu seem to be
the main ones which use /usr or /lib.
Ian.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411502506.3824.4.ca...@hellion.org.uk
Bug#762907: base-installer: Kernel version selection does not exclucde -dbg packages
Source: base-installer Severity: normal Dear Maintainer, I got asked this while working on the arm64 installer: Install the base system --- The list shows the available kernels. Please choose one of them in order to make the system bootable from the hard drive. Kernel to install: 1: linux-image-3.14-2-arm64 [*], 3: none, 2: linux-image-3.14-2-arm64-dbg, Prompt: '?' for help, default=1> And adding a simple case to the test suite shows the issue for amd64 too, I suspect all arches have this issue: diff --git a/kernel/tests/amd64/cittagazze.test b/kernel/tests/amd64/cittagazze.test index c45d9fc..90d8780 100644 --- a/kernel/tests/amd64/cittagazze.test +++ b/kernel/tests/amd64/cittagazze.test @@ -6,3 +6,5 @@ kernel-2.6 \ usable \ linux-image-amd64 \ linux-image-2.6.18-4-amd64 +unusable \ + linux-image-2.6.18-4-amd64-dbg diff --git a/kernel/tests/arm64/mustang.test b/kernel/tests/arm64/mustang.test index 330f259..80ab19f 100644 --- a/kernel/tests/arm64/mustang.test +++ b/kernel/tests/arm64/mustang.test @@ -8,3 +8,5 @@ kernel-3.10 \ usable \ linux-image-arm64 \ linux-image-3.14-1-arm64 +unusable \ + linux-image-3.14-1-arm64-dbg Leading to: $ ./runtests amd64 FAIL amd64/cittagazze.test arch_check_usable_kernel 2.6 linux-image-2.6.18-4-amd64-dbg should be unusable amd64: 8 passes, 1 failures. It seems this has been the case since -dbg packages were introduced (at least Wheezy if not sooner) so this apparently isn't causing issues in the real world (not sure why arm64 asked me that question...), so not a huge worry I don't think but filing so it doesn't get lost. Ian. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf armel Kernel: Linux 3.14-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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140926074335.15701.7024.report...@dagon.hellion.org.uk
Bug#762007: Kernel command line handling change breaks d-i user-params functionality
On Wed, 2014-09-17 at 18:45 +0100, Ian Campbell wrote:
> Not sure what we can do about this. Perhaps choose another separator
> ("=="?) and make user-params support both?
Reading the kernel source it seems it only checks for exactly "--". So I
propose we support "---" in addition to "--", something like the
following (untested) patch.
diff --git a/user-params b/user-params
index 53677b5..2d41e05 100755
--- a/user-params
+++ b/user-params
@@ -14,7 +14,7 @@ for item in $(sed -e 's/[^ =]*="[^"]*[ ][^"]*"//g' \
# Remove trailing '?' for debconf variables set with '?='
var="${var%\?}"
- if [ "$item" = "--" ]; then
+ if [ "$item" = "--" ] || [ "$item" = "---" ]; then
inuser=1
collect=""
elif [ "$inuser" ]; then
Ian.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411822917.23482.6.ca...@hellion.org.uk
Bug#762618: debian-installer: amd64/i386 netboot/mini.iso has empty grub.cfg for EFI boot
Control: tag -1 +patch On Tue, 2014-09-23 at 20:29 +0100, Ian Campbell wrote: > While looking for an example to crib for arm64 I noticed that the amd64 > mini.iso has a grub cfg (used when booting on EFI) which doesn't contain any > menu entries. Booting on non-EFI would use the isolinux menus in the usual > way. > Looking at the code I expect this will apply to i386 too, although I've not > checked. I wrote a script to generate a grub.cfg for arm64. Since it was based on the grub.cfg which debian-cd produces for x86 it is pretty trivial to reuse it here. diff --git a/build/config/x86.cfg b/build/config/x86.cfg index d54ebcb..de903bd 100644 --- a/build/config/x86.cfg +++ b/build/config/x86.cfg @@ -265,6 +265,10 @@ arch_miniiso: x86_syslinux x86_grub_efi ln -f $(TEMP_KERNEL) $(TEMP_CD_TREE)/linux ln -f $(TEMP_INITRD) $(TEMP_CD_TREE)/initrd.gz + mkdir -p $(TEMP_CD_TREE)/.disk + echo "Debian GNU/Linux $(DEBIAN_VERSION) $(ARCH) - netboot mini.iso $(BUILD_DATE)"\ + > $(TEMP_CD_TREE)/.disk/info + # Use a non-empty character for beep by default to make sure the menu # is wide enough when beep is enabled. beep="_"; \ @@ -296,9 +300,12 @@ arch_miniiso: x86_syslinux x86_grub_efi set -e; \ mkdir -p $(TEMP_CD_TREE)/boot/grub/x86_64-efi; \ cp -a $(TEMP_GRUB_EFI)/efi.img $(TEMP_CD_TREE)/boot/grub/; \ - cat boot/x86/grub/grub-efi.cfg \ - | bootvars-subst KERNEL /linux \ + grub-gencfg \ + KERNEL /linux \ INITRD /initrd.gz \ + HEADER boot/x86/grub/grub-efi.cfg \ + -- \ + $(VIDEO_MODE) \ > $(TEMP_CD_TREE)/boot/grub/grub.cfg; \ cp -a $(GRUB_FONT) $(TEMP_CD_TREE)/boot/grub/font.pf2; \ cp -a $(TEMP_GRUB_EFI)/boot/grub/x86_64-efi/* \ diff --git a/debian/changelog b/debian/changelog index 9c10cc4..e435657 100644 --- a/debian/changelog +++ b/debian/changelog @@ -10,6 +10,7 @@ debian-installer (2014) UNRELEASED; urgency=low * Switch to installing Jessie by default on ARM64. * Build netboot mini.iso on ARM64. * Build cdrom flavour for ARM64. + * Add grub.cfg to netboot mini.iso for use on EFI systems (Closes: #762618). [ Cyril Brulebois ] * Deal with even more incompatible changes on the syslinux side by -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1411849825.3824.30.ca...@hellion.org.uk
Bug#763127: UEFI corner case - installer booted in UEFI mode, existing system in BIOS mode
On Sun, 2014-09-28 at 10:26 +0100, Steve McIntyre wrote: > On Sun, Sep 28, 2014 at 08:48:11AM +0200, Wouter Verhelst wrote: > >On Sun, Sep 28, 2014 at 02:28:06AM +0100, Steve McIntyre wrote: > >> If the user wants to continue, we could even suggest blanking the > >> partition table(s) and starting again with GPT, but I don't think > >> we currently have a "blank partition table" option exposed within > >> d-i? > >> > >> What do people think of this plan? What have I missed? > > > >Isn't it better to run this test in partman-efi's isinstallable script? > >Then if things are set up in the described way, grub-efi just won't be > >installed, but the normal grub will, and the system will continue to > >boot in BIOS fallback as before. > > That was my initial thought, but then someone pointed out: what > happens to a user who explicitly *wants* to replace their existing > legacy system with a new UEFI one? Is isinstallable allowed to ask debconf question? Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1411903149.23482.13.ca...@hellion.org.uk
Re: Time for Jessie Beta 2?
On Fri, 2014-09-26 at 21:05 +0200, Cyril Brulebois wrote: > Cyril Brulebois (2014-09-10): > > as you might have seen, a number of uploads happened lately and the d-i > > BoF notes from DebConf kindly provided by Steve (thanks!) reminded me > > about uploading d-i more often. So I think I'll try and achieve that as > > soon as linux 3.16 reaches testing (it was just uploaded to unstable, > > and FTBFSes on several architectures, so not this week ;)). > > linux/linux-latest are now ready, baring nvidida (#762977). > > > Some things got set into motion, like syslinux menu overhaul (mainly > > discussion around the switch to graphical by default, didn't see any > > patch yet) or tasksel changes (alternative desktops, blends support). > > I'm unsure they're going to be ready at that point, so I guess it would > > make sense not to wait for them and publish another release in the > > meanwhile. I'll probably gather opinions when linux is ready, this mail > > is mainly meant to be a heads-up. > > I'll probably skip syslinux vs. multi-arch this time, mostly due to lack > of time and other large ongoing changes: let's see if we can get > debian-cd to cope with latest tasksel changes soon. Should we do anything about #762007 (user-params breakage due to kernel changes) or can it wait? WRT #762618 (empty grub.cfg in x86 mini.iso, used on EFI systems only) I didn't push that patch because of the pending beta (and it touches x86 which I didn't want to mess with unannounced). Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1411905547.23482.19.ca...@hellion.org.uk
Re: Time for Jessie Beta 2?
On Sun, 2014-09-28 at 15:47 +0200, Cyril Brulebois wrote: > Ian Campbell (2014-09-28): > > Should we do anything about #762007 (user-params breakage due to > > kernel changes) or can it wait? > > I might be mistaken but I think it can wait a bit until we agree on a > solution and have some time to get it tested. Ack. > > WRT #762618 (empty grub.cfg in x86 mini.iso, used on EFI systems only) > > I didn't push that patch because of the pending beta (and it touches > > x86 which I didn't want to mess with unannounced). > > Same story. Filed as a normal bug so I'm tempted to let it wait until > after Beta 2. Filed as normal because I didn't know if it was minor or important (or worse) ;-) I suspect it's more on the minor end of things, so Ack. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1411923267.17796.9.ca...@hellion.org.uk
Bug#763127: UEFI corner case - installer booted in UEFI mode, existing system in BIOS mode
On Sun, 2014-09-28 at 18:54 +0200, Wouter Verhelst wrote: > On Sun, Sep 28, 2014 at 10:26:20AM +0100, Steve McIntyre wrote: > > On Sun, Sep 28, 2014 at 08:48:11AM +0200, Wouter Verhelst wrote: > > >On Sun, Sep 28, 2014 at 02:28:06AM +0100, Steve McIntyre wrote: > > >> If the user wants to continue, we could even suggest blanking the > > >> partition table(s) and starting again with GPT, but I don't think > > >> we currently have a "blank partition table" option exposed within > > >> d-i? > > >> > > >> What do people think of this plan? What have I missed? > > > > > >Isn't it better to run this test in partman-efi's isinstallable script? > > >Then if things are set up in the described way, grub-efi just won't be > > >installed, but the normal grub will, and the system will continue to > > >boot in BIOS fallback as before. > > > > That was my initial thought, but then someone pointed out: what > > happens to a user who explicitly *wants* to replace their existing > > legacy system with a new UEFI one? > > If that is a warning (as opposed to error) message saying something > along the lines of "note that with this setup you won't be able to boot > your current system anymore", then that isn't an actual problem. A user > who is planning to replace a system shouldn't be worried about the > installer warning them that they can't boot the (to be replaced) old > system anymore, and can safely ignore that message. I was thinking more along the lines of a yes/no question which would either cause partman-efi.isinstallable to fail or not. Allowing selection between the "wants to convert to EFI" and "wants to stick with regular grub not grub-efi" cases. Ian. > > -- > It is easy to love a country that is famous for chocolate and beer > > -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 > > -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1411923732.17796.11.ca...@hellion.org.uk
Bug#763127: UEFI corner case - installer booted in UEFI mode, existing system in BIOS mode
On Sun, 2014-09-28 at 18:14 +0100, Steve McIntyre wrote: > On Sun, Sep 28, 2014 at 06:02:12PM +0100, Ian Campbell wrote: > >I was thinking more along the lines of a yes/no question which would > >either cause partman-efi.isinstallable to fail or not. Allowing > >selection between the "wants to convert to EFI" and "wants to stick with > >regular grub not grub-efi" cases. > > That sounds better to me too, assuming we can sensibly do a question > at that point. Is that allowed? I honestly don't know... :-/ It just occurred to me to look, and it seems that a handful of them do to some extent, e.g. grub-installer's isinstallable does "db_get grub-installer/skip". On the other hand I don't see any uses of db_go/db_input so it may only be usable for preseeded answers. an -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1411928345.17796.13.ca...@hellion.org.uk
Re: getting wheezy installer code
On Mon, 2014-09-29 at 11:52 -0700, Ross Boylan wrote: > Assuming an already checked out copy of the installer > (https://wiki.debian.org/DebianInstaller/CheckOut), what's the best > way to switch to wheezy? > > mr git checkout -b wheezy origin/wheezy > ? I'm not sure that mr has branch management capabilities like this. I expect it's a case of digging down in the package/* one by one and checking out the wheezy branch (if one exists for that package). Hopefully you have an idea which subpackages you are interested in and can optimise this a bit rather than going through them all (which would be pretty tedious, possibly scriptable though). I expect quite a lot of them don't have a wheezy branch though, since no wheezy specific release was needed. I think running "apt-get source " on a system with Wheezy configured in sources.list should get you the actual current source package. You might need to add a "deb-src $MIRROR wheezy main/debian-installer" line to sources.list though? HTH Ian. > I'm not really sure what to make of the svn/git hybrid nature of > what's on my disk. > > Thanks. > Ross Boylan > > -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1412061526.17796.26.ca...@hellion.org.uk
Re: Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs
On Fri, 2014-09-26 at 00:08 +0100, Ben Hutchings wrote: > However, at the moment initramfs-tools won't include PHY drivers even in > that configuration. I spent some time last week hunting for a sysfs link between a device and the phys which it is using, without success. Do you have any ideas? Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1412061597.17796.27.ca...@hellion.org.uk
Re: getting wheezy installer code
On Tue, 2014-09-30 at 12:07 +0200, Cyril Brulebois wrote: > > You might need to add a "deb-src $MIRROR wheezy > > main/debian-installer" line to sources.list though? > > But not that part: there's no udeb-specific Sources. :) So you only need > the main/debian-installer part in 'deb' lines to be able to 'dget' or > 'apt-get download' udebs. apt-get source for udebs should just work out > of the box (spoiler alert: it does ;)). Even better! Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1412072396.25650.0.ca...@hellion.org.uk
Re: Are there packages for which NO upload is wished right now?
On Fri, 2014-10-03 at 07:05 +0200, Cyril Brulebois wrote: > > flash-kernel (3.26) UNRELEASED; urgency=medium > > > > * Install a symlink to the latest dtb in /boot/dtb and keep a backup of > > the > > actual file. > > * Add a generic u-boot boot.scr using the upstream config_distro_bootcmd.h > > infrastructure. > > * Add support for the Arndale board. > > * Install uImage and uRamdisk to /boot on Xgene platform and load dtb from > > the correct path. > > > > -- Ian Campbell Tue, 23 Sep 2014 19:51:12 +0100 > > I'd say talk to f-k guys before touching that one; I fully trust their > judgment and (pretend I) don't know anything about it. I've been deliberately holding off on this upload so as to not interfere with the beta2 release. AIUI we are currently in the grey area between uploads to unstable becoming OK again and the formal announcement of the beta. I'm happy to wait or not as you like. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1412323107.17796.49.ca...@hellion.org.uk
Bug#764320: rsync in rescue mode
Control: reassign -1 rsync Control: forcemerge 729069 764320 Note that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729069 includes a link to http://lackof.org/taggart/hacking/d-i-tricks/ which may be helpful (but hacky!) to the original submitter (I've not tried the approach there myself). Another approach for now would be a live cd rather than the Debian installer CD in rescue mode. Cheers, Ian. On Tue, 2014-10-07 at 10:31 +0200, Julien Cristau wrote: > Package: debian-installer > Severity: wishlist > Control: submitter -1 r...@atlas.cz > X-Debbugs-Cc: debian-test...@lists.debian.org > > - Forwarded message from r...@atlas.cz - > > From: r...@atlas.cz > Date: Sun, 05 Oct 2014 11:36:51 +0200 > To: debian-test...@lists.debian.org > Subject: Ask for rsync > Message-Id: <20141005113651.a111e...@atlas.cz> > > > Dear Debian developers, > > I kindly ask you for help. I am using instalation CD > in rescue mode and I need to rescue my data. > In rescue environment there is no rsync command, > which would resolve my task. > > I kindly ask you, please add rsync command > to standalone rescue environment. > > Thank you for help, R. > > - End forwarded message - -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1412675006.4972.20.ca...@hellion.org.uk
Bug#762007: Kernel command line handling change breaks d-i user-params functionality
On Sat, 2014-09-27 at 14:01 +0100, Ian Campbell wrote:
> On Wed, 2014-09-17 at 18:45 +0100, Ian Campbell wrote:
> > Not sure what we can do about this. Perhaps choose another separator
> > ("=="?) and make user-params support both?
>
> Reading the kernel source it seems it only checks for exactly "--". So I
> propose we support "---" in addition to "--", something like the
> following (untested) patch.
I've built an di-utils with this patch and built a di using that
package. I booted (on x86 FWIW) with a command line ending
"--- quiet console=ttyS0,115200n8"
instead of "-- quiet console=ttyS0,115200n8".
Dropping straight to a shell and running user-params returns those two
options as expected.
I've left a complete install running but I'm pretty confident that it
will succeed.
As well as this fix I think we need to investigate which of these need
fixing too (i.e. with s/--/---/ in appropriate places):
* The pxe/grub etc configs in debian-installer.git
* Debian-cd
* Installation guide
I'm sure that list must be incomplete but it was all I could come up
with. Sadly, as you might imagine, "--" is not terribly amenable to grep
or codesearch.d.o.
Ian.
>
> diff --git a/user-params b/user-params
> index 53677b5..2d41e05 100755
> --- a/user-params
> +++ b/user-params
> @@ -14,7 +14,7 @@ for item in $(sed -e 's/[^ =]*="[^"]*[ ][^"]*"//g' \
> # Remove trailing '?' for debconf variables set with '?='
> var="${var%\?}"
>
> - if [ "$item" = "--" ]; then
> + if [ "$item" = "--" ] || [ "$item" = "---" ]; then
> inuser=1
> collect=""
> elif [ "$inuser" ]; then
>
> Ian.
>
>
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1412840904.11505.6.ca...@debian.org
Bug#762007: Kernel command line handling change breaks d-i user-params functionality
severity 762007 important
tag 762007 +pending
clone 762007 -1 -2 -3
reassign -1 src:debian-installer
title -1 debian-installer: Please use "---" not "--" on installer's kernel
command line
block -1 by 762007
reassign -2 src:debian-cd
title -2 debian-cd: Please use "---" not "--" on installer's kernel command line
block -2 by 762007
reassign -3 src:installation-guide
title -3 installation-guide: Please use "---" not "--" on installer's kernel
command line
block -3 by 762007
thanks
TL;DR for the above packages: A kernel change broke the use of "--" on
the kernel command line as a separator for d-i user-params purposes
(i.e. the bit which affects the installer but is also propagated to the
installed system). We now support "---" as well and should use that
wherever we currently use "--".
On Thu, 2014-10-09 at 08:48 +0100, Ian Campbell wrote:
> I've left a complete install running but I'm pretty confident that it
> will succeed.
It did. So I have pushed the patch to git.
> As well as this fix I think we need to investigate which of these need
> fixing too (i.e. with s/--/---/ in appropriate places):
> * The pxe/grub etc configs in debian-installer.git
> * Debian-cd
> * Installation guide
I've assigned clones of this bug to these.
> I'm sure that list must be incomplete but it was all I could come up
> with. Sadly, as you might imagine, "--" is not terribly amenable to grep
> or codesearch.d.o.
>
> Ian.
>
> >
> > diff --git a/user-params b/user-params
> > index 53677b5..2d41e05 100755
> > --- a/user-params
> > +++ b/user-params
> > @@ -14,7 +14,7 @@ for item in $(sed -e 's/[^ =]*="[^"]*[ ][^"]*"//g' \
> > # Remove trailing '?' for debconf variables set with '?='
> > var="${var%\?}"
> >
> > - if [ "$item" = "--" ]; then
> > + if [ "$item" = "--" ] || [ "$item" = "---" ]; then
> > inuser=1
> > collect=""
> > elif [ "$inuser" ]; then
> >
> > Ian.
> >
> >
>
>
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1412925641.11505.10.ca...@debian.org
Re: [PATCH V2] d-i hd-media support for armhf
On Wed, 2014-10-01 at 00:47 +0200, Karsten Merker wrote: > +.PHONY: hd-media_dtbs > +hd-media_dtbs: $(TEMP_DTBS) > + mkdir -p $(SOME_DEST)/$(EXTRANAME)dtbs > + set -ex ; for dtb in $(TEMP_DTBS)/*.dtb ; do \ > + tgt=$(SOME_DEST)/$(EXTRANAME)dtbs/$$(basename $$dtb); \ > + cp $$dtb $$tgt ; \ > + update-manifest $$tgt "Device Tree Blob: $$(basename $$dtb)";\ > + done > + cp boot/README.device-tree $(SOME_DEST)/$(EXTRANAME)dtbs/README > + update-manifest $(SOME_DEST)/$(EXTRANAME)dtbs/README "Device Tree > Blobs README" This results in http://d-i.debian.org/daily-images/armhf/daily/hd-media/dtbs/ which I don't think is needed since we already have http://d-i.debian.org/daily-images/armhf/daily/device-tree/ as a common place to publish the dtbs. I think it would be best to put these in a temporary location for the purposes of including in the hd-media tarball only. Or maybe it is possible to depend on the output of the existing device-tree flavour, I've not checked into that possibility. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1413013622.11505.16.ca...@hellion.org.uk
Re: Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs
On Fri, 2014-09-26 at 00:08 +0100, Ben Hutchings wrote:
> On Thu, 2014-09-25 at 23:20 +0100, peter green wrote:
> > Karsten Merker wrote:
> > >> Browse online:
> > >>
> > >> http://anonscm.debian.org/cgit/d-i/base-installer.git/tree/debian/templates-arch
> > >>
> > >> Adding -arm@ and -boot@ for possible comments/insight.
> > >>
> > >
> > > I suppose the reason for MODULES=dep being the default on arm*
> > > might be that some armel systems boot their kernel and initrd
> > > directly from an onboard flash chip with a size of only a few MB,
> > > so an initramfs built with modules=most might be uninstallable on
> > > them due to lack of space.
> > >
> > Which makes sense for armel, many load their boot files from fixed size
> > blocks of flash and flash space is a MAJOR issue (and major thorn in the
> > kernel teams side) and you will generally need a new kernel if you move
> > to a different device anyway.
>
> Another possible reason for using MODULES=dep would be that disk access
> from the boot loader is very slow (this is the case on Google Compute
> Engine for example).
>
> > On the other hand for armhf i'm not sure it makes sense, most armhf
> > systems i'm aware of load their kernels/initrds from filesystems so
> > space is not such and issue and with the new armmp kernels having a
> > modules=most initrd would presumablly allow one to move to different
> > hardware with just swapping out the bootloader.
>
> Assuming that armhf is not constrained by flash partition sizes (we
> certainly don't have any size limit configured for the kernel image yet)
> or very slow I/O, I support using MODULES=most by default.
I agree. I'm not aware of any armhf platforms with size constraints or
cripplingly slow boot time I/O. I think if either of those show up the
answer would be to fix the bootloader to run with caches on, support a
better boot device etc etc.
Unless there are objections I'll make the change in base-installer.
> However, at the moment initramfs-tools won't include PHY drivers even in
> that configuration.
I filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762042 about
this sort of thing on xgene, and today I updated it because arndale is
affected too.
As I say there I'm planning to send a patch to load an appropriate set
of phy drivers when running with modules=most.
That won't solve modules=dep though. The only solution I can think of
right now for that is to extend the existing hidden_dep handling with a
scheme which maps each module to be loaded to a list of other modules
which should be included (e.g. ahci_platform => { a bunch of phy
drivers }). Hardly the most elegant thing in the world, could perhaps be
improved by looking at the set of currently loaded drivers, but that has
pitfalls too.
Ian.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1413035956.11505.22.ca...@hellion.org.uk
Bug#764968: Please add db entry for A20-OLinuXino-LIME
Control: tag -1 +pending On Sun, 2014-10-12 at 21:01 +0200, Christian Kastner wrote: > On 2014-10-12 20:51, Karsten Merker wrote: > > On Sun, Oct 12, 2014 at 06:35:33PM +0200, Christian Kastner wrote: > >> +Machine: Olimex A20-OLinuXino-LIME > >> +Kernel-Flavors: armmp > >> +Boot-Script-Path: /boot/boot.scr > >> +DTB-Id: sun7i-a20-olinuxino-lime.dtb > >> +U-Boot-Script-Name: bootscr.sunxi > >> +Required-Packages: u-boot-tools > >> + > >> Machine: Olimex A20-Olinuxino Micro > >> Kernel-Flavors: armmp armmp-lpae > >> Boot-Script-Path: /boot/boot.scr > > > > The "Kernel-Flavors" entry should be > > > > Kernel-Flavors: armmp armmp-lpae > > > > as the A20 is LPAE-capable, but otherwise this looks ok. > > Updated patch attached. Thanks for checking, Karsten! Applied to flash-kernel.git, thanks guys. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1413148064.11505.66.ca...@hellion.org.uk
Bug#749991: both installer betas suffer from this
On Tue, 2014-10-14 at 17:22 +0200, Hermann Lauer wrote: > On Thu, Oct 02, 2014 at 02:24:45PM +0200, Hermann Lauer wrote: > > both Jessie beta 1 amd64 images (20140316 and 20140802) suffer from this. > > fixed with Jessie beta 2 netboot here. And serial console works with: > > append initrd=debian-installer/amd64/initrd.gz auto priority=critical > url=http://<...>preseed locale=en_US hostname=x domain=x > console=ttyS0,19200n8 -- console=ttyS0,19200n8 The issues with serial consoles are probably/possibly: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007 (hence the need to double up the console= bit) Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1413356889.10417.66.ca...@hellion.org.uk
Bug#766400: installation-reports: [armhf] Netgear ReadyNAS104 report
On Wed, 2014-10-22 at 22:16 +0200, Uwe Kleine-Koenig wrote: > > One of the last messages from the installer is: > > You will need to boot manually with the /boot/vmlinuz kernel on > partition /dev/sda1 and root=/dev/sda1 passed as a kernel argument. Which bootloader does the system have? This could possibly be resolved by adding the system to the flash-kernel database? (nb f-k is no longer only about booting from flash...) Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1414050475.20604.78.ca...@hellion.org.uk
Re: [PATCH V2] d-i hd-media support for armhf
On Sat, 2014-10-11 at 08:47 +0100, Ian Campbell wrote: > On Wed, 2014-10-01 at 00:47 +0200, Karsten Merker wrote: > > +.PHONY: hd-media_dtbs > > +hd-media_dtbs: $(TEMP_DTBS) > > + mkdir -p $(SOME_DEST)/$(EXTRANAME)dtbs > > + set -ex ; for dtb in $(TEMP_DTBS)/*.dtb ; do \ > > + tgt=$(SOME_DEST)/$(EXTRANAME)dtbs/$$(basename $$dtb); \ > > + cp $$dtb $$tgt ; \ > > + update-manifest $$tgt "Device Tree Blob: $$(basename > > $$dtb)";\ > > + done > > + cp boot/README.device-tree $(SOME_DEST)/$(EXTRANAME)dtbs/README > > + update-manifest $(SOME_DEST)/$(EXTRANAME)dtbs/README "Device Tree > > Blobs README" > > This results in > http://d-i.debian.org/daily-images/armhf/daily/hd-media/dtbs/ which I > don't think is needed since we already have > http://d-i.debian.org/daily-images/armhf/daily/device-tree/ as a common > place to publish the dtbs. > > I think it would be best to put these in a temporary location for the > purposes of including in the hd-media tarball only. Or maybe it is > possible to depend on the output of the existing device-tree flavour, > I've not checked into that possibility. How about this patch, it seems to do what I meant here. Ian. commit cca80bb7adae24b525790fd0d9ba6c8c5c6bc370 Author: Ian Campbell Date: Fri Oct 24 21:37:59 2014 +0100 armhf: Don't publish dtbs dir with hd-media Include them in the hd-media.tar.gz but not ion unpacked form diff --git a/build/config/armhf/hd-media.cfg b/build/config/armhf/hd-media.cfg index 31d3583..ec119df 100644 --- a/build/config/armhf/hd-media.cfg +++ b/build/config/armhf/hd-media.cfg @@ -3,28 +3,24 @@ FLAVOUR_SUPPORTED = "" GZIPPED = .gz EXTRANAME = hd-media/ -TARGET = $(KERNEL) $(INITRD) hd-media_dtbs hd-media_bootscript hd-media_tarball +TARGET = $(KERNEL) $(INITRD) hd-media_bootscript hd-media_tarball MANIFEST-INITRD = "Initrd for use on USB memory sticks" MANIFEST-KERNEL = "Kernel for use on USB memory sticks" -.PHONY: hd-media_dtbs -hd-media_dtbs: $(TEMP_DTBS) - mkdir -p $(SOME_DEST)/$(EXTRANAME)dtbs - set -ex ; for dtb in $(TEMP_DTBS)/*.dtb ; do \ - tgt=$(SOME_DEST)/$(EXTRANAME)dtbs/$$(basename $$dtb); \ - cp $$dtb $$tgt ; \ - update-manifest $$tgt "Device Tree Blob: $$(basename $$dtb)";\ - done - cp boot/README.device-tree $(SOME_DEST)/$(EXTRANAME)dtbs/README - update-manifest $(SOME_DEST)/$(EXTRANAME)dtbs/README "Device Tree Blobs README" - .PHONY: hd-media_bootscript hd-media_bootscript: mkimage -T script -A arm -d boot/arm/bootscr.mainline_common $(SOME_DEST)/$(EXTRANAME)boot.scr update-manifest $(SOME_DEST)/$(EXTRANAME)boot.scr "Universal boot script for mainline u-boot (>= v2014.10)" .PHONY: hd-media_tarball -hd-media_tarball: $(KERNEL) $(INITRD) hd-media_dtbs hd-media_bootscript - tar -C $(SOME_DEST)/$(EXTRANAME) -zcf $(TEMP)/hd-media.tar.gz boot.scr initrd.gz vmlinuz dtbs/ +hd-media_tarball: $(KERNEL) $(INITRD) $(TEMP_DTBS) hd-media_bootscript + -rm -rf $(TEMP)/hd-media + mkdir $(TEMP)/hd-media + cp $(KERNEL) $(TEMP)/hd-media/vmlinuz + cp $(INITRD) $(TEMP)/hd-media/initrd.gz + cp $(SOME_DEST)/$(EXTRANAME)boot.scr $(TEMP)/hd-media/boot.scr + cp -r $(TEMP_DTBS) $(TEMP)/hd-media/dtbs/ + cp boot/README.device-tree $(TEMP)/hd-media/dtbs/README + tar -C $(TEMP)/hd-media -zcf $(TEMP)/hd-media.tar.gz boot.scr initrd.gz vmlinuz dtbs/ mv $(TEMP)/hd-media.tar.gz $(SOME_DEST)/$(EXTRANAME) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1414183169.3584.11.ca...@hellion.org.uk
Bug#767052: D-I : Sheevaplug : could not determine kernel flavour
On Tue, 2014-10-28 at 04:08 +0100, drEagle wrote: > The kernel flavour is not detected. > Sheevaplug now use a dtb file and no kernel are installed into the target > system. A dtb shouldn't be necessary for the Sheevaplug, I don't think. Did you manually supply one or did something do that for you? I'm not that familiar with how a Sheevaplug is set up to boot by default. I think that if you install by booting without an fdt (in "board file" mode) then everything should just work. Alternatively if you want to boot in DTB mode (I don't think there is any direct benefit to doing so right now) then you will need to figure out an appropriate stanza for the flash-kernel database. Probably this will be very similar to the existing non-DTB one, except the Machine line should be the contents of /proc/device-tree/model instead of /proc/cpuinfo:hardware and you will probably want a DTB-Id line naming the correct DTB file. It's possible you might be able to combine the DTB and boardfile entires into one (the "Marvell Armada XP GP Board" does this) See flash-kernel's README for more information. You can experiment with entries in /etc/flash-kernel/db instead of editing the main DB. HTH, Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1414525116.3584.29.ca...@hellion.org.uk
Bug#767052: D-I : Sheevaplug : could not determine kernel flavour
On Thu, 2014-10-30 at 15:42 +0100, drEagle wrote: > Hi Ian, > > On 28/10/2014 20:38, Ian Campbell wrote: > > On Tue, 2014-10-28 at 04:08 +0100, drEagle wrote: > >> The kernel flavour is not detected. > >> Sheevaplug now use a dtb file and no kernel are installed into the target > >> system. > > > > A dtb shouldn't be necessary for the Sheevaplug, I don't think. Did you > > manually supply one or did something do that for you? I'm not that > > familiar with how a Sheevaplug is set up to boot by default. > > The tests was done using a patched uboot. Patched how? Just to enable the dtb commands? I'm not sure what the factory firmware was like on a sheevaplug, nor how brickable the thing is. If it's safe to update (or the factory one is really broken) then we could recommend an update, ideally to a u-boot shipped by Debian, in which case we should be able to rely on whichever features it has, such as native fdt support instead of appending. > > I think that if you install by booting without an fdt (in "board file" > > mode) then everything should just work. > > This do not work with latest kernel (d-i for jessie), which require a > fdt for sheeva and some others kirkwood as raidsonic or guruplug. Oh, I hadn't realised that some kirkwood platforms had been fully converted over to DTB already in 3.16. I knew it was an *option* for some (e.g. qnap TS-*), but not that it was mandatory on others. > > Alternatively if you want to boot in DTB mode (I don't think there is > > any direct benefit to doing so right now) then you will need to figure > > out an appropriate stanza for the flash-kernel database. Probably this > > will be very similar to the existing non-DTB one, except the Machine > > line should be the contents of /proc/device-tree/model instead > > of /proc/cpuinfo:hardware and you will probably want a DTB-Id line > > naming the correct DTB file. It's possible you might be able to combine > > the DTB and boardfile entires into one (the "Marvell Armada XP GP Board" > > does this) See flash-kernel's README for more information. You can > > experiment with entries in /etc/flash-kernel/db instead of editing the > > main DB. > > Theses tests was done for jessie support. OK, seems like I've misunderstood/misremembered the transition plan for some kirkwood devices. Please can you provide a suitable stanza for an updated flash-kernel db then. > Before jessie, sheevaplugs were support by the debian kernel and the debian > installer. AFAIK they are today as well, or are intended to be. But we do rely on people who have such hardware to test and report issues (so thanks!) and also to help us fix issues by filling in the blanks for that bit of hardware (e.g. db entries). > Debian installer had also a netconsole and a netboot image which give the > choice of the method of installing by ssh. I don't see a sheevaplug netconsole version in Wheezy or Squeeze either. When did Debian used to supply one? > Is sheevaplugs and derivatives support abandonned by debian ? > I hope not. I don't think so, you've just found a potential/probably bug exposed by an upstream kernel change is all. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1414681291.2064.46.ca...@hellion.org.uk
Bug#767744: flash-kernel: There is no way to specify a custom dtb
On Sun, 2014-11-02 at 12:08 +0100, Uwe Kleine-König wrote: > Package: flash-kernel > Version: 3.28 > Severity: wishlist > > Hello, > > I want to use flash-kernel on a machine that uses a device tree blob that > isn't > included in the kernel package. So flash-kernel's assumption to find > /usr/lib/linux-image-$kvers/$dtb_id is wrong. > > Maybe something like: > > # if dtb_name starts with / assume it's a stand alone file. Otherwise > # pick the one shipped by the linux image. > if expr "$dtb_name" : "/" >/dev/null; then > dtb="$dtb_name" > else > dtb="/usr/lib/linux-image-$kvers/$dtb_name" > fi > > would work? expr isn't a builtin, right? So we don't need to worry about dash vs bash for it and whether the ":" operator is implemented. Another possibility would be to search /etc/flash-kernel/dtbs (perhaps with and without $kvers) before /usr/lib/blah. I suppose you are needing to use flash-kernel's dtb appending mode, otherwise you could just drop the file in /boot. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415037080.1411.7.ca...@hellion.org.uk
Re: [PATCH V2] d-i hd-media support for armhf
On Sun, 2014-11-02 at 15:33 +0100, Karsten Merker wrote:
> On Sat, Nov 01, 2014 at 12:06:55AM -0700, Vagrant Cascadian wrote:
>
> [d-i hd-media support for armhf, boot script]
> > Overall, it appears to be working quite well. I've thought about
> > creating a similar bootscript for the netboot images.
> >
> > > +if test -n "${console}"; then
> > > + setenv bootargs "${bootargs} console=${console}"
> > > +fi
> >
> > It would seem that the console variable isn't consistant across u-boot
> > platforms. On some (sunxi) it sets both the device and the baudrate
> > (i.e. console=ttyS0,115200), but on many other platforms console only
> > sets the device (i.e. console=ttyS0) and linux then reverts to 9600
> > baud. But the u-boot baudrate is often 115200 with u-boot itself, and
> > set in a baudrate variable. It doesn't seem possible to set a sane
> > default...
> >
> > So basically this "generic" boot script only works with platforms where
> > the baudrate is included in the "console" variable (or where the
> > baudrate defaults to 9600, to match linux's default, though I think most
> > of the armhf platforms at least default to 115200). *sigh*
> >
> > Not sure if u-boot's shell has the ability to match contents of
> > variables, so the baudrate could be conditionally added only if not
> > already present.
>
> AFAICS there is no such functionality in u-boot's commandline
> parser. Ian, do you perhaps have an idea how to implement this
> in a u-boot script? Unfortunately the existence of a ${baudrate}
> variable is independent from whether ${console} has the baudrate
> encoded into it or not, so just checking for the existence of
> ${baudrate} does not help in this case.
I'm not thinking of any cunning ideas I'm afraid :-/
Unless console=ttyS0,115200,115200 happens to be safe, but I don't know
that I would suggest relying on that.
This is probably another case where the correct long-game is to drive
some sort of standardisation upstream, we probably aren't the only ones
with this issue.
Ian.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1415036911.1411.5.ca...@debian.org
Bug#767744: flash-kernel: There is no way to specify a custom dtb
On Mon, 2014-11-03 at 19:10 +0100, Cyril Brulebois wrote: > Ian Campbell (2014-11-03): > > On Sun, 2014-11-02 at 12:08 +0100, Uwe Kleine-König wrote: > > > Package: flash-kernel > > > Version: 3.28 > > > Severity: wishlist > > > > > > Hello, > > > > > > I want to use flash-kernel on a machine that uses a device tree blob that > > > isn't > > > included in the kernel package. So flash-kernel's assumption to find > > > /usr/lib/linux-image-$kvers/$dtb_id is wrong. > > > > > > Maybe something like: > > > > > > # if dtb_name starts with / assume it's a stand alone file. Otherwise > > > # pick the one shipped by the linux image. > > > if expr "$dtb_name" : "/" >/dev/null; then > > > dtb="$dtb_name" > > > else > > > dtb="/usr/lib/linux-image-$kvers/$dtb_name" > > > fi > > > > > > would work? > > > > expr isn't a builtin, right? So we don't need to worry about dash vs > > bash for it and whether the ":" operator is implemented. > > Just use case and match on /*? Indeed, that would be best I think. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415094900.11486.4.ca...@hellion.org.uk
cloning 762007, reassign -1 to src:win32-loader ...
clone 762007 -1 reopen -1 reassign -1 src:win32-loader retitle -1 win32-loader: Please use "---" not "--" on installers kernel command line thanks Reassigned a clone as discussed on IRC: (16:31:31) KiBi: ijc: it looks like win32-loader might need an update as well for the -- thingy (16:32:17) KiBi: e.g. s_install.nsi:233 (16:32:22) Sledge: probably, yeah (16:32:26) Sledge: OdyX: ^^^ (16:36:21) OdyX: ah yeah, right. Can someone file a bug ? I have an extra-full week-end. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415292079-4042-bts-...@debian.org
Re: [PATCH V2] d-i hd-media support for armhf
On Fri, 2014-10-24 at 21:39 +0100, Ian Campbell wrote: > On Sat, 2014-10-11 at 08:47 +0100, Ian Campbell wrote: > > On Wed, 2014-10-01 at 00:47 +0200, Karsten Merker wrote: > > > +.PHONY: hd-media_dtbs > > > +hd-media_dtbs: $(TEMP_DTBS) > > > + mkdir -p $(SOME_DEST)/$(EXTRANAME)dtbs > > > + set -ex ; for dtb in $(TEMP_DTBS)/*.dtb ; do \ > > > + tgt=$(SOME_DEST)/$(EXTRANAME)dtbs/$$(basename $$dtb); \ > > > + cp $$dtb $$tgt ; \ > > > + update-manifest $$tgt "Device Tree Blob: $$(basename > > > $$dtb)";\ > > > + done > > > + cp boot/README.device-tree $(SOME_DEST)/$(EXTRANAME)dtbs/README > > > + update-manifest $(SOME_DEST)/$(EXTRANAME)dtbs/README "Device > > > Tree Blobs README" > > > > This results in > > http://d-i.debian.org/daily-images/armhf/daily/hd-media/dtbs/ which I > > don't think is needed since we already have > > http://d-i.debian.org/daily-images/armhf/daily/device-tree/ as a common > > place to publish the dtbs. > > > > I think it would be best to put these in a temporary location for the > > purposes of including in the hd-media tarball only. Or maybe it is > > possible to depend on the output of the existing device-tree flavour, > > I've not checked into that possibility. > > How about this patch, it seems to do what I meant here. FYI I just pushed this, the content of hd-media.tar.gz is identical (modulo a timestamp or two) Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415916593.31613.32.ca...@hellion.org.uk
Bug#770231: Amd64-efi installer becomes unresponsive on x86 bios
On Fri, 2014-11-21 at 15:40 -0500, Samuel Comeau wrote: > On November 21, 2014 03:30:13 PM Steve McIntyre wrote: > > [ Re-adding the CC to the bug report ] > > > > On Thu, Nov 20, 2014 at 10:49:42PM -0500, Samuel Comeau wrote: > > >Hello Steve, > > > > > >The intent of the report was that the installer fails "silently", instead > > >of crashing with human readable output. I seem to recall seeing an > > >installer fail with references to incompatible architecture, but that may > > >be faulty memory. > > Right, OK. I'm not sure about that myself... :-) That answers my > > question, too. How about we re-assign this to the kernel package and > > ask about such a message? > > I thought that since there's the installer running, we could put an > architecture check right there, so when you reach the menu, the installer > would already be aware what it's running on. So when the amd64 kernel tries > to > start, it would correctly assume it's trying to run on compatible hardware, > unless the installer prevents it. I'm not sure how that would tie in with the > other installation methods, however, so it may be best to do as you say and > let kernel deal with that. > > > >I understand from your comment that this behaviour is known, but my > > >pre-bug- report-search didn't turn up any relevant results about "amd64 + > > >installer + (hangs OR stalls OR unresponsive) + x86". The results I get > > >are all about boot time, not installation time, unless I misunderstood > > >something very fundamental. In my understanding, when I reach the > > >installer menu, the boot procedure is complete. > > > > Correct - at that point you're in Linux with d-i running. > > That implies that there is some form of kernel running? Obviously not an > amd64 > kernel, if it shows up fine even on x86. Therefore, I assume the arch > specific > kernel gets booted once the user selects an operation to perform. What is the text of the last menu which you get to before the hang? Is there anything written on the screen at the point of the hang? If it is too much text to transcribe then a digital photo of the screen would be ok too. Which model of Xeon are you running on? If you don't know then by pressing cancel/back at the d-i menu you can get to a menu with an option to drop to a shell and from there run "cat /proc/cpuinfo". I'm most interested in the "model name" field. If you aren't getting to a d-i menu at all then there is probably an indication of the processor model in the BIOS screens somewhere. If you are booting to a proper Debian installer menu (i.e. past the initial bootloader menu) then with an amd64 netinst you must be running something which is at least somewhat amd64 capable and not an i?86 only thing, there is nothing other than an amd64 kernel on such an image AFAIK. Which suggests to me that the hang is happening elsewhere later on, perhaps when loading the driver modules, but is not related directly to the processor architecture. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416652312.6331.4.ca...@hellion.org.uk
Bug#770231: Amd64-efi installer becomes unresponsive on x86 bios
On Mon, 2014-11-24 at 16:26 -0500, Samuel Comeau wrote: > Hello Ian, > > > Well, it appears I have made a mistake about the type of processor > that's in here : Intel(R) Pentium(R) 4 CPU 2.80GHz. I think the P4 had 64-bit support in some variants, but it does sound likely that yours isn't one of them. > I don't have the text of the menu screen for you yet, I would have to > retry installing linux, which I haven't had the time to do yet. I can > at least tell you, however, that the menu I got to was very similar to > this one > http://debian-handbook.info/browse/stable/images/inst-boot.png , OK thanks for clarifying, so you are failing at the bootloader screen and not making it to the installer proper. Given that I think what Steve said regarding not booting amd64 kernels on i386 hardware is probably the most likely theory. I'm not sure why the message about incompatible arch should be AWOL, perhaps related to the bootloader having enabled graphical mode? Does an i386 image work on your system? > apart from the fact that my installer boot menu didn't have 64 bit > anywhere in it. I think (but I'm not 100% sure) that this is expected for a single arch image, IOW if the image is only for amd64 then you just get "Install" etc and not "64 bit install". "Install" will laucn amd64. For dual/multi-arch images then you get both options, one of which launches 32-bit and the other 64-bit. > The hang occurs when I try to select any option. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416913806.32327.8.ca...@hellion.org.uk
Bug#770231: Amd64-efi installer becomes unresponsive on x86 bios
On Tue, 2014-11-25 at 14:31 +, Steve McIntyre wrote: > Ian - am I totally mis-remembering that there used to be a "can't > start on 32-bit " style message in the amd64 kernel? If so then it's a shared delusion, I was sure such a thing existed too. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416926207.32327.30.ca...@hellion.org.uk
Bug#770231: Amd64-efi installer becomes unresponsive on x86 bios
On Tue, 2014-11-25 at 15:42 +0100, Cyril Brulebois wrote: > which is likely what you were after? That's the badger. I wonder if isolinux's use of graphical mode is leaving things such that this very early code is unable to actually output anything. Is there an easy way to disable gfx, or to force it to drop back to dumbest text mode before launching the kernel? Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1416926627.32327.31.ca...@hellion.org.uk
Re: Debian-Installer support for riscv64
On Sun, 2019-06-02 at 22:25 +0200, Karsten Merker wrote: > Another thing that needs to be tackled in d-i is an annoying > property of qemu's riscv64 "virt" machine: The "virt" machine > emulates both a normal serial console (/dev/ttyS0) and a HVC > console (/dev/ttyhvc0). Unfortunately in qemu both share the > same physical console device and systemd starts a getty on both > /dev/ttyS0 and /dev/ttyhvc0 so that we have two getty instances > running on the same physical console which wreks havoc. Can this be fixed on the qemu side? Having two emulated devices appearing on the same host console is going to cause confusion over and over again I think. Is it possible that this behaviour is down to the command line you are giving qemu? e.g. `-nographic` might (completely guessing) end up with this behaviour, whereas the UI would put them on separate virtual consoles. Ian.
Re: Grub, UEFI Secure Boot and netboot - help!
On Mon, 2019-06-10 at 03:37 +0100, Steve McIntyre wrote: > Any other suggestions on what we could do? Let me know what you > think... Is signing an extra, d-i specific, grubnetXX.efi image out of the question? Is the hard coded prefix a single prefix or is there a possibility of searching a list? It's been a long time since I've played with any of this but I have a vague recollection of once upon a time using (or trying to use, maybe I'm remembering a failed experiment) a memdisk (builtin to the grub image) containing an initial config file which then was a bit more flexible about chaining to the next thing. I can't find any evidence of that setup in any of the places I thought it might be related to though :-/ Ian.
Bug#941300: finish-install: write random seed to correct location for chosen init system
On Wed, 2019-10-02 at 08:59 +0800, Paul Wise wrote: > On Tue, 2019-10-01 at 11:55 +0100, Steve McIntyre wrote: > > > Wouldn't it just be easier to write it one location and replace the > > other with a symlink to it? > > Looks like neither the urandom init script nor systemd-random-seed > unlink the file before writing to it, so this could potentially work > unless that changes at some point. Just writing two different seeds > avoids the need to care about what the implementations will do in the > future so I think it is safer. The original report says: > systemd-random-seed.service overrides the urandom init script > but uses a different location for its random seed file If it's going to override/shadow (as opposed to simply working alongside/in parallel) urandom, probably it ought to also be looking at/consuming the urandom seed? Ian.
Re: 8 more packages
On Mon, 2020-01-13 at 21:58 +0100, Geert Stappers wrote: > On Sun, Jan 12, 2020 at 07:51:34PM +0100, Philip Hands wrote: > > My guess would be that installing over WiFi causes 8 packages to > > be installed earlier than happens with a wired install. I could > > imagine that having e.g. wpasupplicant might be deemed a good idea. > > The strange^Winterresting thing was that the ethernet install > listed the number of 1371 packages, WIFI 1363 ... That's what you would expect if Phil's hypothesis about 8 packages getting installed at some earlier phase is correct, since they won't then be installed as part of the bulk install of packages. Ian.
Bug#949626: busybox-static: Please include less and ftpput in busybox-udeb
On Wed, 2020-01-22 at 22:42 +, Witold Baryluk wrote: > > The age of FTP has long passed. > > You think you can fit the scp or ssh then? :D I doubt so. If you have a network to scp over then you can `anna-install` the ssh udebs on the fly first, no need to have them in the initrd. Soon you'll be able to install rsync that way too: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729069 Ian.
Re: Remote Debian installation assistance for newbies using WireGuard VPN
On Wed, 2018-04-25 at 14:50 +0200, Philip Hands wrote: > Of course we then have to work out under what circumstances the user > should trust that person to be connected to their network, the > implications of which one cannot really expect a newbie to fully > grasp. I'm reminded of https://debug-me.branchable.com/ Ian.
Re: Salsa
On Thu, 2018-05-03 at 22:10 +0100, Steve McIntyre wrote: > The outputs from this run > were a surprising amount bigger than my first test repo, as the > following bare clones from each will show: > > tack:/tmp$ du -s test* > 613888 test1-bare.git > 3653432 test2-bare.git > 714336 test2-manual-bare.git > > I've not worked out why yet. Was this with a completely different tool or the same tool with different settings/wrappers? If it was a different tool maybe a `git gc --aggressive` will repack (and thus compact/delta-compress) the bigger one? (my hypothesis is that maybe the first run did it automatically and the second didn't) Ian.
Re: Salsa
On Sun, 2018-05-06 at 01:43 +0100, Steve McIntyre wrote: > OK, so I've tried --aggressive too now, and wow does it make a big > difference. AIUI amongst other things --aggressive forces a full repack of the repo, which optimises the delta compression in the pack files. You could probably achieve most of the effect with `git repack`. It's probably diminishing returns at this point but there are options there to make it spend (lots) more time/memory to make things even smaller. > I've tried using it on the d-i.git and d-i-manual.git > repos and the difference is *huge*: > > # test2, previous results: > $ du -s test* > 613888 test1-bare.git > 3653432 test2-bare.git > 714336 test2-manual-bare.git That's much better ;-) Ian.
Re: Archiving the attic folders from d-i for ports
On Mon, 2018-05-07 at 10:34 +0200, John Paul Adrian Glaubitz wrote: > On 05/07/2018 04:29 AM, Steve McIntyre wrote: > > > I was only talking about the still needed ones. linux-kernel-* > > > is > > > clearly not and I doubt it have any practical value to look at. > > > > My thoughts too. Adrian: Sorry, but I'm *not* just going to import > > all of those dead modules. Actually useful things, maybe... > > I understand. But as a scientist, I prefer archiving sources for > reference According to the mails[0] whatever remain on alioth is going to be archived: > 10.-13.05.18: darcs, bzr and mercurial repositories will be exported > as tarballs and made available readonly from a new archive host, > details on that will follow. >[...] > 31.05.18: All remaining repositories (cvs, svn and git) will be > archived similar to the ones above. So I think there's no reason for the d-i team to also archive them, or move them to salsa. Ian. [0] https://lists.debian.org/debian-devel-announce/2018/04/msg8.html
Re: Archiving the attic folders from d-i for ports
On Mon, 2018-05-07 at 17:01 +0200, John Paul Adrian Glaubitz wrote: > On 05/07/2018 04:59 PM, Ian Campbell wrote: > > According to the mails[0] whatever remain on alioth is going to be > > archived: > > > > > 10.-13.05.18: darcs, bzr and mercurial repositories will be > > > exported > > > as tarballs and made available readonly from a new archive host, > > > details on that will follow. > > > [...] > > > 31.05.18: All remaining repositories (cvs, svn and git) will be > > > archived similar to the ones above. > > > > So I think there's no reason for the d-i team to also archive them, > > or > > move them to salsa. > > Are the archived repositories publicly available? All I know is what was so far said in the quoted text above, which says "details will follow". Ian.
Re: d-i repo at dillon
On Sat, 2018-06-16 at 08:36 +0200, Holger Wansing wrote: > > The original/final lines are a bit strange, though, instead of having: > > > > if $($git foo bar); then … fi > > > > I suppose it should only be: > > > > if $git foo bar; then … fi > > However, with this simplified variant it fails. So I left it as is for now. It seems there is an interesting (and new to me, or at least I'd never fully appreciated the behaviour) corner case of the `if $(foo); then` syntax, which is that if `foo` exits producing no output then its exit code is apparently used for the condition. If `foo` does produce output then the shell will attempt to execute that and use the resulting exit code. These just run true or false and take the output: $ dash -c 'if true ; then echo YES ; else echo NO ; fi' YES $ dash -c 'if false ; then echo YES ; else echo NO ; fi' NO These run true or false, see the output is "" and so use the exit code: $ dash -c 'if $(true) ; then echo YES ; else echo NO ; fi' YES $ dash -c 'if $(false) ; then echo YES ; else echo NO ; fi' NO These run `echo` (which always succeeds) then runs the resulting "true" or "false" and uses the exit code: $ dash -c 'if $(echo true) ; then echo YES ; else echo NO ; fi' YES $ dash -c 'if $(echo false) ; then echo YES ; else echo NO ; fi' NO This runs `echo` (which always succeeds) then tries to run the resulting "foo" and fails because that isn't a command: $ dash -c 'if $(echo bar) ; then echo YES ; else echo NO ; fi' dash: 1: bar: not found NO `git status` outputs nothing when the tree is clean, and I think the `$($git status -s -uno $DI_COPY/packages/po)` case uses that to succeed on a clean tree, however if the tree was dirty you'd get the "not found" stuff for something relating to the output. $ git status -s -uno build/Makefile $ echo $? 0 $ dash -c 'if $(git status -s -uno build/Makefile ) ; then echo CLEAN ; else echo DIRTY ; fi' CLEAN $ echo "FOO" >> build/Makefile $ git status -s -uno build/Makefile M build/Makefile $ echo $? 0 $ dash -c 'if $(git status -s -uno build/Makefile ) ; then echo CLEAN ; else echo DIRTY ; fi' dash: 1: M: not found DIRTY Notice that the original svn version had a `| grep -q ^C` which was checking if any line started with a "C" (for Changed I suppose), produced no output (`-q`) but exited with an error code reflecting the presence of any lines. You could do something similar but you'd need to check for more than M (modified) since git status has a variety of error codes, including (A)dded, (D)eleted, (R)enamed etc. `git status` doesn't seem to have an option which makes the error code reflect the dirtiness. In the past I've used: # Update cache, otherwise files which have an updated # timestamp but no actual changes are marked as changes # because `git diff-index` only uses the `lstat` result and # not the actual file contents. Running `git update-index # --refresh` updates the cache. git update-index -q --refresh if git diff-index --quiet HEAD -- path/to/something ; then clean ; else dirty ; fi (--quiet enable --exit-code which makes the exit status meaningful). For perhaps less git magic you could also just write it as: if [ -z "$(git status -s -uno path/to/something)" ] ; then clean ; else dirty ; fi or inversely: if [ -n "$(git status -s -uno path/to/something)" ] ; then dirty ; else clean ; fi These explicitly check whether the output of the status command was empty (the -z check, meaning clean) or non-empty (the -n check, meaning dirty). Ian.
Re: d-i repo at dillon
On Sat, 2018-06-16 at 10:17 +0100, Ian Campbell wrote:
> On Sat, 2018-06-16 at 08:36 +0200, Holger Wansing wrote:
> > > The original/final lines are a bit strange, though, instead of
> having:
> > >
> > > if $($git foo bar); then … fi
> > >
> > > I suppose it should only be:
> > >
> > > if $git foo bar; then … fi
> >
> > However, with this simplified variant it fails. So I left it as is
> for now.
>
> It seems there is an interesting (and new to me, or at least I'd
> never
> fully appreciated the behaviour) corner case of the `if $(foo); then`
> syntax, which is that if `foo` exits producing no output then its
> exit
> code is apparently used for the condition. If `foo` does produce
> output
> then the shell will attempt to execute that and use the resulting
> exit
> code.
>
> These just run true or false and take the output:
Should be "These just run true or false and use the exit code".
BTW, it's worth mentioning that `true` and `false` here are actually
`/bin/{true,false}` i.e. literal commands which return the appropriate
exit code that the shell `fork`s and `exec`s. There's no shell syntax
magic[*] going on here where `true` and `false` are somehow parsed
specially.
Ian.
[*] technically `true` and `false` might be shell builtins for
performance reasons (and it looks like with `dash` `true` is but
`false` isn't). However logically they can be treated as external
commands without special handling. To be unambiguous you could rerun
all the examples using the explicit /bin/true etc versions directly.
>$ dash -c 'if true ; then echo YES ; else echo NO ; fi'
>YES
>$ dash -c 'if false ; then echo YES ; else echo NO ; fi'
>NO
Ian.
Re: debootstrap/1.0.102 appears to break debuerreotype autopkgtest
On Mon, 2018-06-18 at 08:07 -0700, Tianon Gravi wrote: > IMO, that merge request needs some review and an upload and then this > bug will be fixed properly in debootstrap too. Seems like the RC bug against debootstrap which Paul mentioned should be opened (to be closed by some future upload of debootstrap with this MR merged)then. Otherwise the package can migrate before the required review + merge has happened. Ian.
Re: Bug#915880: lvm2: Dependency on liblz4-1 causes /sbin binaries to depend on /usr/lib libraries
On Tue, 2018-12-11 at 08:27 +0200, Per Lundberg wrote: > Hi Adrian, > > Quoting the page you linked to: > > > This section only applies to systems using a custom kernel, where > /usr is on a separate mount point from /. If you use the kernel > packages provided by Debian, you are unaffected by this issue. > > >From what I can tell in this text, keeping /usr on a separate mount > point _is_ indeed supported (as long as you are using a stock kernel > and a proper initramfs generator) - and as noted in my followup email, > installing Buster on a /usr volume works fine. Also, the Debian > installer provides /usr as an option when partitioning your disk. If > indeed maintaining /usr on a separate partition is completely > unsupported (which you indicate), A separate /usr is supported with a custom kernel if and only if you arrange for it to be mounted by the initramfs, you cannot (any longer) rely on / to contain everything necessary to mount /usr. I think the remainder of the section you partly quoted above makes this clear, if you disagree perhaps you could suggest an improvement to the wording: Mounting of /usr using only tools found in / is no longer supported. This has only worked for a few specific configurations in the past, and now they are explicitly unsupported. This means that for stretch all systems where /usr is a separate partition need to use an initramfs generator that will mount /usr. All initramfs generators in stretch do so. The note you quoted is simply saying that the kernel packages in Debian, together with the initramfs generators, meet this requirement so if you are using those you need not worry about the specifics. I don't know if any of the above applies to Ubuntu (where you've observed an actual failure), so if you have found a case where the initramfs generator is not doing the right thing for that distro you should open a bug with them. Ian.
Re: Bug#915880: lvm2: Dependency on liblz4-1 causes /sbin binaries to depend on /usr/lib libraries
On Wed, 2018-12-12 at 09:04 +0200, Per Lundberg wrote: > Let's leave this closed for now; I might come back later but I'd need > to investigate this more on a clean Ubuntu 18.04 install and > potentially open an issue with them. Given the usrmerge coming up, the > difference between depending on /lib and /usr/lib might be irrelevant > shortly, as far as Debian is concerned. Remember that usrmerge is going to move stuff from /sbin to /usr/sbin etc not vice versa, so without /usr mounted from the initramfs you won't find /sbin/lvm at all i.e. the issue is more pronounced with usrmerge, not less. BTW the initramfs's generated by the tools in Debian have been usrmerged for a long time, and it should be those copies of LVM and its dependencies which are being used anyway. Ian.
Re: [console-setup] udebs declared as Multi-Arch: foreign
On Mon, 2018-12-17 at 01:29 +, Ben Hutchings wrote: > udpkg and the various package retrievers in d-i don't support multi- > arch. Until they do there's probably little point in adding that > information to udebs. It's also not terribly clear what the utility of a multiarchified installer initramfs would actually be. Ian.
Re: [console-setup] udebs declared as Multi-Arch: foreign
On Mon, 2018-12-17 at 15:19 +, Ben Hutchings wrote: > On Mon, 2018-12-17 at 10:29 +0000, Ian Campbell wrote: > > On Mon, 2018-12-17 at 01:29 +, Ben Hutchings wrote: > > > udpkg and the various package retrievers in d-i don't support > > > multi- > > > arch. Until they do there's probably little point in adding that > > > information to udebs. > > > > It's also not terribly clear what the utility of a multiarchified > > installer initramfs would actually be. > > In any case where the installed system will have a 32-bit primary > architecture and 64-bit kernel, either the installer should be multi- > arch or it will need to support cross-install. > > So far we've bodged this by building duplicate 64-bit kernel packages > labelled with the 32-bit architecture. By "kernel packages" do you mean the `foo.udeb` which knows how to select a kernel (I've forgotten the real name) rather than the full `linux-image-*.deb`? Ian.
Re: [console-setup] udebs declared as Multi-Arch: foreign
On Mon, 2018-12-17 at 15:46 +, Ben Hutchings wrote: > I mean both udebs (kernel-image-*.udeb and *-modules-*.udeb) and the > full linux-image-*.deb. Oh, of course! Thanks. Ian.
Re: Multiple console support in d-i
On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote:
> >So far I have done a proof-of-concept hack and demonstrated that
> >running two instances does in fact work nicely without anything
> >obvious breaking. The console selection still needs some work/checking
> >(I've run out of time for that tonight, but it can easily be fished
> >out of the kernel command line args. (or we could get fancier).
>
> Nod. Potentially we might end up of running on multiple
> consoles.
IIRC (and it hasn't changed in the years since I knew this stuff) we
already have this on some of the netconsole install images for
arm{el,hf}, you end up with an installer on serial and one on the ssh
connection. Not an identical situation since I think the second one is
only spawned when you login via ssh, but some sort of precedence I
guess!
Ian.
Re: Multiple console support in d-i
On Tue, 2019-01-22 at 04:31 +, Wookey wrote: > On 2019-01-20 03:02 +, Ben Hutchings wrote: > > Reading /proc/consoles is exactly what you should do. > > Checking this on a booted thunderx machine (with no explicit kernel cmdline > options) it lists > ttyAMA0 > > If I boot with explicit console=tty0 console=ttyAMA0 on the kernel cmdline > then they both appear in /proc/consoles, AMA0 last > > If I boot with explicit console=tty0 on the kernel cmdline > then they both appear in /proc/consoles, AMA0 still last Do the various flags not differ between the different cases? Ian.
Re: Multiple console support in d-i
On Wed, 2019-01-23 at 03:41 +, Wookey wrote:
> You are right. I wasn't taking note of those:
>
> E=enabled
> C=preferred console
> p=used for printk buffer
> a=safe to use when CPU is offline
>
> console=tty0
> tty0 -WU (EC p )4:7
> ttyAMA0 -W- (E p a) 204:64
>
> console=ttyAMA0
> tty0 -WU (E p )4:7
> ttyAMA0 -W- (EC p a) 204:64
>
> console=tty0 console=ttyAMA0
> tty0 -WU (E p )4:7
> ttyAMA0 -W- (E p a) 204:64
>
> Any idea how we should choose a D-I primary console when none of them
> is marked 'preferred'? Or should D-i do away with the concept and try
> to treat them all equally (which is a slightly more intrusive
> change).
>
> Currently I use the one marked 'C' or the last one if none.
I wonder if the lack of a 'C' in the final entry is considered a bug?
Looking at the kernel code I see:
fs/proc/consoles.c: { CON_CONSDEV, 'C' },
where CON_CONSDEV is:
include/linux/console.h:#define CON_CONSDEV (2) /* Last on the command
line */
So it being lacking on ttyAMA0 in that case seems wrong.
Even if the bug were fixed it seems sensible to deal with this case,
last one (with sufficient other flags set) seems like as good as
anything...
Ian.
Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool
(just the list, other cc'd dropped) On Mon, 2021-04-12 at 19:35 +0200, Samuel Thibault wrote: > Petter Reinholdtsen, le lun. 12 avril 2021 07:34:38 +0200, a ecrit: > > Sad to hear the patch has been ignored for several years. > > Please do not confuse "ignore" with "terribly understaffed". I wonder if there is anything which a 3rd party could be found to do via the Freexian project thing[0] which would reduce the overall burden and free up some of the limited time contributors (of which I am long lapsed :-() have? e.g. automate some time consuming manual work, setup automated testing infra, that sort of thing? Ian. [0] https://salsa.debian.org/freexian-team/project-funding
Bug#736373: using this patch with salsa & openqa
On Wed, 2021-05-19 at 00:03 +0200, Philip Hands wrote: Hi Ian, Thanks for the patch. It's proven very useful while seting up pipelines on salsa that can be run when a udeb's git repo is pushed, such that a mini.iso is produced that will make use of a repository containing that udeb. While getting that to work, I noticed that your patch does not deal well with the repos that aptly produces because they do not include a Packages.xz, which means that when the Packages.xz is found in the main repo, it stops searching the devel repo. That being the case, I've re-jigged things a bit, as seen here: https://salsa.debian.org/philh/net-retriever/-/compare/master...extra-udeb-repo?w=1 (BTW I intend to tidy up the commits there tomorrow, as they include some false starts at present, so probably best to wait until I've done that before using anything out of that branch) Glad it was useful, I'd completely forgotten I'd even written that patch! My knowledge of this side of things is pretty stale, but FWIW I didn't see anything untoward in your updated diff. Cheers, Ian.
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 (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-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1432543421.5748.163.ca...@debian.org
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-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1432653550.14664.138.ca...@debian.org
Re: UEFI PXE step by step instructions?
On Tue, 2015-05-26 at 09:30 +, Andrew M.A. Cater wrote: > I can't find any references for how to PXE boot UEFI: I find lots of > posts complaining that pxelinux.0 is not compatible with UEFI and not > much more. I've struggled a bit with this recently for work and am still figuring some stuff out. AFAICT network boot is not a generally well solved problem in the UEFI world. There does seem to be a pxelinux.efi in the world, but I was using ARM so I've not tried it. It seems that some folks (e.g. Ubuntu and the product team at work, so not a huge sample set) prefer to use grub.efi in any case, even on x86. I ended up building a grub.efi to use in place of pxelinux.0, with something like: grub-mkimage -O "$platform" \ -o pxegrub-$arch.efi -p "$grubpfx" \ search configfile normal efinet tftp net where $platform is the grub platform name (x86_64-efi, arm64-efi etc), $arch is the Debian arch, and $grubpfx is a path (relative to tftproot) which contains a grub/grub.cfg which in turn contains: set stage1=yes configfile /grub.cfg-'$net_default_mac' IOW it just loads a new config file based on the mac address of the device used to pxe (a bit like how pxelinux finds pxelinux.cfg). Adjust paths to suit etc. To use this you need to arrange for the DHCP next-binary option to point to the pxegrub-$arch.efi. I did this by raising a ticket with IT people, YMMV :-) I saw various things online like https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-netboot-pxe-config-efi.html which seem to try and configure a sane default based on who is asking. I don't think we bothered, we just put it in the per-machine stanza. http://lists.xen.org/archives/html/xen-devel/2015-05/msg03087.html is the encoding of the setup stages of this into our test system, I doubt that'll be very useful for you though, I've tried to reproduce the pertinent bits above. HTH at least a little, Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1432655009.14664.149.ca...@debian.org
Re: UEFI PXE step by step instructions?
On Tue, 2015-05-26 at 16:43 +0100, Ian Campbell wrote: > On Tue, 2015-05-26 at 09:30 +, Andrew M.A. Cater wrote: > > I can't find any references for how to PXE boot UEFI: I find lots of > > posts complaining that pxelinux.0 is not compatible with UEFI and not > > much more. > > I've struggled a bit with this recently for work and am still figuring [...] Perhaps I'm over complicating things for your use case and all you really need to do is arrange for the appropriate ./debian-installer/.../bootnetFOO.efi (from the per-arch netboot.tar.gz e.g. [0]) to be next-file for the system in question, along with unpacking that netboot.tar.gz at the right place. Ian. [0] http://ftp.debian.org/debian/dists/jessie/main/installer-amd64/current/images/netboot/netboot.tar.gz -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1432657235.5748.176.ca...@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-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1433004604.5748.241.ca...@debian.org
https:// based git clone from alioth not pulling latest code
TL;DR: git-update-server-info hook on d-i/debian-installer.git seems to
have failed once in the past, doing another dummy push has resolved the
issue.
Longer:
A "git clone
https://alioth.debian.org/anonscm/git/d-i/debian-installer.git";
is producing a master branch with tip commit:
commit 852aede05821aad12dfde0f1611462fad8893e5b
Author: Ian Campbell
Date: Tue May 26 17:39:56 2015 +0100
Adjust build to handle DTBs in subdirectories on arm64 (Closes:
#786882).
Whereas "git clone git://alioth.debian.org/d-i/debian-installer.git" is
producing a tip of:
commit 911f238cab0926e61a6113133c59d58f9571a6d1
Author: Cyril Brulebois
Date: Wed May 27 15:01:09 2015 +0200
Bump linux kernel version from 4.0.0-1 to 4.0.0-2
Which is one newer and is what we actually want to get.
Since the d-i nightlies have switch to https (security++) the are
therefore not picking up the latest code (which happens to be a fix for
build breakage in this case).
AIUI this is usually down to a lack of git-update-server-info on push.
In moszumanska:/srv/git.debian.org/git/d-i/debian-installer.git I saw
hooks/post-update which seems like it should have done the right thing.
So I did:
git push origin HEAD:refs/heads/ijc/testing
git push origin +:refs/heads/ijc/testing
(i.e. made then nuked a branch) which seems to have been enough to make
server update run and https clones now seem to see the right thing
again.
So I suppose there was some sort of transient issue when Kibi pushed
911f238cab.
Ian.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1433230466.5748.299.ca...@debian.org
Re: https:// based git clone from alioth not pulling latest code
On Tue, 2015-06-02 at 17:53 +0200, Cyril Brulebois wrote: [...] > This is entirely my fault, ISTR having pushed using “git push” or “git > push origin”, noticed the many-lines warning about pushing without > parameters, and hit C-c. The push had already happened, as well as IRC > notifications, but I guess this has lead to a missing update-server-info > run… > > Sorry about that. No worries, I'm just glad its not some awful infrastructure heisenbug or something ;-) Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1433260750.15036.338.ca...@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-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1433669254.3342.40.ca...@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-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1433670182.3342.44.ca...@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-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1433670602.3342.46.ca...@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-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1433748639.3342.51.ca...@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-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1433885164.3342.55.ca...@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-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1433922067.3342.56.ca...@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-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1433923648.3342.67.ca...@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-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1433924333.3342.69.ca...@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 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-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1434392215.3342.93.ca...@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 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 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' <
Re: U-Boot, d-i and selecting the console device
On Sun, 2015-06-21 at 19:01 +0200, Karsten Merker wrote: > > > What about adding support in debian-installer to dsisplay on both the > > serial console and framebuffer? > > My memory on that topic is unfortunately a bit shady, but IIRC > this was proposed some time ago already and was dismissed due to > technical problems, but I cannot remember any details. IIRC the network-console images (used on e.g. headless qnap systems) run one instance on serial (in case you have a cable) and another on the ssh login session, each beginning (again IIRC) with a menu saying "Start on this one". Doing something similar for fb + serial doesn't seem totally infeasible. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1435347248.17598.56.ca...@hellion.org.uk
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-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1435649774.17598.102.ca...@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-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1435650776.17598.106.ca...@debian.org
Bug#789798: [RFR] New grub-installer-template
On Tue, 2015-06-30 at 10:28 +0100, Philip Hands wrote: > Ian Campbell 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' < 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-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1435658139.21469.60.ca...@debian.org
