Re: Bug#977245: openssh-server: Kernel error after big rsync or scp
Control: reassign -1 linux On Sat, Dec 12, 2020 at 09:53:23PM -0500, Gabe wrote: > After attempting to scp or rsync a directory with many large-ish files > (20-600M) to a remote host, the remote machine will crash. This hasn't > happened > with smaller file transfers; only when the directory contains gigabytes of > data, after about 3GB have been copied. I tried once to scp a similar ammount > of data from a different client to the same machine, with the same result. The > commands used were: > > scp -r ./localdirectory jgmanilla@remotehost:~/ > rsync -avP ./localdirectory jgmanilla@remotehost:~/ > > If you happened to be logged into an ssh session, you may get the following > message before the system goes down: > > Message from syslogd@localhost at Dec 12 16:22:24 ... >kernel:[ 406.101940] Internal error: Oops: 9604 [#1] SMP > > Message from syslogd@localhost at Dec 12 16:22:24 ... >kernel:[ 406.130105] Code: b9402a62 f9405e63 8b020014 dac00e81 > (f8626814) > > Expected outcome was for scp and rsync to complete their file transfers > with no errors. > > The hardware of the remote machine was a RockPro64. > The client operating systems tested were Gentoo and Arch linux. In general kernel oopses are kernel bugs, not userspace bugs, so reassigning to linux. I expect that the full contents of the oops message from syslog would be helpful to the kernel maintainers. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: last preparations for switching to production Secure Boot key
On Mon, Feb 25, 2019 at 08:13:22PM +0100, Ansgar wrote: > I added support for listing `trusted_certs`[1] as proposed by Ben > Hutchings. This means the `files.json` structure *must* list the > sha256sum of certificates the signed binaries will trust (this can be an > empty list in case no hard-coded certificates are trusted). Do I understand correctly that this ought to be empty in the case of grub2, since it does all its signature checking via shim? If so, done: https://salsa.debian.org/grub-team/grub/commit/89c1529cd82f106dbb9a4b17bae03e828ec349b6 > I would like to implement one additional change. Currently files.json > looks like this: [...] > This is not extendable; therefore I would like to move everything below a > top-level `packages` key, i.e. the file would look like this instead: [...] > This would allow adding additional top-level keys later should the need > arise. (I'll prepare the archive-side changes for this later today.) I'm happy to do this, though presumably it's a flag day? > Could all maintainers (for fwupd, fwupdate, grub2, linux) please ack one > last time that their packages are ready for switching to the production > key? And prepare an upload with the changes described above and ready > to use the production key? I don't know of any blockers from the grub2 side. Once the archive has the "packages" key changes, I can prepare an upload - I was planning to make one this week anyway. Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#882380: initramfs-tools: Update-initramfs can take an unnecessarily long time if other disk activity is ongoing
On Wed, Nov 22, 2017 at 01:05:00AM +0200, Jukka Tastula wrote: > After generating an initrd update-initramfs calls sync unconditinally. This > can take a very long time to return if other disk activity, like perhaps a > long backup job, is running simultaneously. Suggest only syncing the > filesystem the initrd is actually placed on instead. I think this is a good idea, and it would also avoid upgrade problems such as https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1667512 in the case of things like stuck NFS mounts. To avoid backport surprises, I would suggest adding a dependency on coreutils (>= 8.24), which introduced the feature of sync(1) being used here. I've put all this in a merge request: https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/6 -- Colin Watson [cjwat...@debian.org]
Re: Bug#849923: openssh-server: no login possible after upgrade on x32
clone 849923 -1
reassign -1 linux
retitle -1 linux: x32 __vdso_clock_gettime falls back to x86-64 syscall
thanks
On Tue, Jan 03, 2017 at 02:31:35PM +0100, Thorsten Glaser wrote:
> On Mon, 2 Jan 2017, Aurelien Jarno wrote:
> > Looking at the issue, it actually appears in __vdso_clock_gettime, which
> > is provided by the kernel. This code handle the simple cases (REALTIME,
> > MONOTONIC, REALTIME_COARSE and _MONOTONIC_COARSE) and fallbacks to
> > the syscall in otherwise, CLOCK_BOOTTIME in the case of sshd.
>
> Ouch – and the kernel probably thinks it’s getting away with this as
> the kernel architecture is amd64…
>
> Can you please forward this to someone at the kernel side (either Debian
> or upstream) who can have a look? In the meantime, I’ll point this issue
> out in #debian-x32 on IRC, so the other porters can also look.
I've cloned a kernel bug for this with this message.
> > On 2017-01-02 17:49, Colin Watson wrote:
>
> > > sshd's seccomp sandbox is denying a clock_gettime call. But it's more
>
> Probably a stupid idea, but a short-term stopgap: can we disable seccomp
> on x32 for now? That needs:
Here's a better stopgap that lets us keep the sandbox enabled:
https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=e346421ca6852fbf9f95cf0e764ecc345e5ce21d
> • in debian/rules:
> +confflags += --host=${DEB_HOST_GNU_TYPE}
> This sets $host to x86_64-pc-linux-gnux32 instead of the
> auto-detected x86_64-pc-linux-gnu (which is amd64)
Unnecessary: the default is --build=x86_64-linux-gnux32, and --host
shouldn't be passed when not cross-compiling.
You're probably being misled by config.guess's default, but that's
already overridden appropriately by dpkg/debhelper.
Cheers,
--
Colin Watson [cjwat...@debian.org]
Re: Plan of action for Secure Boot support
On Wed, Jan 08, 2014 at 08:31:11AM +0100, Florian Weimer wrote: Furthermore, we need to store the keys for all EV certificates (both the certificate used for submission, and the certificate embedded in the shim) in devices that meet at least FIPS 140 Level 2. Such devices that are affordable, support secure, remote operation, and are compatible with free software environments are difficult to find. (But perhaps we can find a DD who agrees to keep the keys in his or her home and manually signs our kernels, using Windows if necessary.) We (Canonical) have been trying to get this requirement made a bit more sane; we keep our SB root certificate split up among a number of shareholders using gfshare, which we believe should be functionally adequate for this. Steve Langasek may know where this sits. I wonder why Microsoft no longer wants to sign GPLv3 code (such as GRUB 2). It could be due to plans to make Secure Boot mandatory eventually. Right now, it is possible to comply with the GPLv3 license requirements because users can switch off Secure Boot, either at the BIOS level or through the MokManager loophole. This does not affect us because we rarely ship hardware with Debian pre-installed, and if we do, we can make use of the general GPLv3 opt-out clause. But it would affect some of our users. Not that I'm very impressed with Microsoft's reasoning here, but in practice we wouldn't want to get GRUB signed by Microsoft anyway; their signing process is far too cumbersome for anything but a loader that we try not to change very often. Their guidelines permit chaining to GPLv3 code via shim, so this part of it should not be a problem. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2014010830.ga20...@riva.ucam.org
Bug#649399: initramfs-tools: please mark Multi-Arch: foreign
Package: initramfs-tools
Version: 0.99
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch precise
Hi,
It would be useful for initramfs-tools to be marked Multi-Arch:
foreign, to indicate that it can satisfy dependencies of packages of
other architectures. Although Debian's dpkg doesn't yet do anything
special with this, it's safe to add this tag in advance of package
manager support.
In Ubuntu, this is an early step in being able to crossgrade from i386
to amd64, because we don't have an -amd64 kernel flavour on i386 and (of
course) our kernel packages depend on initramfs-tools. While Debian
does have an -amd64 flavour on i386, it still wouldn't hurt to add this
tag.
If you're wondering why this tag is needed on an Architecture: all
package, see the multiarch specification:
https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages
diff --git a/debian/control b/debian/control
index 75bf493..8ca8827 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Vcs-Git: git://git.debian.org/git/kernel/initramfs-tools.git
Package: initramfs-tools
Architecture: all
+Multi-Arch: foreign
Recommends: busybox (= 1:1.01-3) | busybox-initramfs
Depends: klibc-utils (= 1.5.23-2~), cpio, module-init-tools, udev, findutils
(= 4.2.24), ${misc:Depends}
Suggests: bash-completion
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/2020174109.gg3...@riva.dynamic.greenend.org.uk
Re: Renaming linux-2.6 source package, keeping bugs
On Wed, Aug 31, 2011 at 01:39:20PM +0100, Ben Hutchings wrote: Since Linux 3.x is a continuation of the 2.6.x series and not a major change, there was no need to create a new source package for it. However, we should now rename the source package to 'linux'. Currently, most of our bugs are assigned to 'linux-2.6' or 'src:linux-2.6' so that version-tracking works across binary package name changes. But if we rename the source package as well, these bugs will presumably be seen to apply only to versions before the name change, or only after. How can we avoid this? The good news is that I don't think this should require fundamental redesign work in order to work gracefully. The bad news is that I think it is going to require some work. The format used for version records should permit a source package to change its name, as long as you preserve the old information in the changelog. For instance, the version file for linux-2.6 currently starts: linux-2.6/3.0.0-3 linux-2.6/3.0.0-2 linux-2.6/3.0.0-1 ... so it could become: linux/3.0.0-4 linux-2.6/3.0.0-3 linux-2.6/3.0.0-2 linux-2.6/3.0.0-1 So, I think what you need is for the bugs to be reassigned to linux or src:linux, but also keep the old version tracking information which indicates that the bug was found in (say) linux-2.6/3.0.0-1. debbugs will know that linux/3.0.0-4 is descended from linux-2.6/3.0.0-1 and so things should keep on working. A normal reassign would discard the version tracking information and you'd have to reapply it afterwards, which would be tedious and error-prone. Perhaps we need to implement a form of reassign that doesn't discard version tracking information, or perhaps we should simply do this by hacking the database in bulk. We might need some work to make pkgreport.cgi?src=linuxdist=stable work gracefully. What I think ought to happen is that it should take the version record for linux and realise that it is descended from a source package called linux-2.6 that's still in stable, and look up the appropriate version for that; but I don't recall implementing anything that clever and I suspect that this does not yet work. We'll also need to consider what happens for users of stable who'll continue to report bugs and expect reportbug to be able to show them listings and so forth. Given the number of bugs involved, perhaps we need to teach debbugs that linux-2.6 should be considered as an alias for linux for the purposes of queries and of input to submit@ and control@. Ben, do you have any constraints on the timeline for this that we should know about? Don, what do you think about all this? I think it's tractable, but it feels like a pretty solid weekend's work to me. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110831131316.gb5...@riva.dynamic.greenend.org.uk
Bug#592519: Bug#627677: alternative initramfs compressor
On Tue, May 24, 2011 at 05:41:44PM +0200, intrigeri wrote: Colin Watson wrote (23 May 2011 14:47:18 GMT) : + # We probably ought to use COMPRESS= in a temporary file in + # /etc/initramfs-tools/conf.d/ instead, but it's hard to + # pass options that way. If this is your only reason to decompress / recompress the ramdisks (implicitly depending on those being compressed using gzip in the first place), wouldn't it be better to make initramfs-tools support a COMPRESS_OPTIONS option + indeed use its conf.d/ to set COMPRESS=, rather than adding the same options to live-build? It probably would, which is why I added a comment; but live-build will need it at least for a while anyway, to support older distributions. (And there isn't much difference in code size.) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592519 has been filed for a while requesting the change you suggest. I've CCed that bug to indicate the link. -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110524163851.ge23...@riva.ucam.org
Re: Dropping unversioned kernel links/copies; adding linux-version command
On Sun, Apr 10, 2011 at 04:02:36PM +0100, Ben Hutchings wrote: On Sun, 2011-04-10 at 15:32 +0100, Ben Hutchings wrote: On Sun, 2011-04-10 at 14:15 +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 01.04.2011 14:04, Ben Hutchings wrote: There isn't an official spec. However the source and unit tests for the DebianLinux Perl module (added to linux-base to support this command) explain the rules I came up with. I don't feel that this is enough. I wanted something that we could agree on, so this could be pulled upstream and eventually also become guideline for other distros. Also having a spec has a benefic effect of clearness and it would also serve as guideline for choosing the version names for uploads. Then *you* can write a spec. Don't tell me what extra work I should be doing. I don't think Vladimir did any more than what you did; you could just as easily be interpreted as telling us to make a change to GRUB (at some level, whether upstream or in Debian). But, more realistically, both of you are essentially offering bug reports. Why not just keep the conversation at that level rather than getting offended and calling things demands? It seems like it'd be easier for everyone. It seems entirely reasonable for an upstream maintainer to seek something that we can agree on upstream rather than something that's Debian-specific. For the avoidance of doubt, this still applies: If there are any remaining reasons to continue using the unversioned links, or additional features you think linux-version should provide, please let us know. Just for clarity, GRUB does not use the unversioned links. Since nobody else seems to want to do it, I'll attempt to write a spec, then, and maybe people can find time to review and discuss it. Here's a mostly English description of the rules that the DebianLinux Perl module uses: 1) Split the version number into a series of components (using greedy matching) each of which is either a string of digits, a hyphen followed by zero or more non-digits, or a string of non-hyphen non-digit characters. 2) For each component, apply each of the following comparisons in sequence, stopping at the first unequal comparison: 1) If a component is -rc or -trunk, then it indicates a pre-release. Pre-releases sort before non-pre-releases. 2) End-of-string sorts before non-end-of-string. 3) If both sides are numeric, compare numerically. Otherwise, compare according to ASCII order. 3) If all components compare equal, the versions are equal. Upstream GRUB currently compares version numbers using 'sort -n'. Debian GRUB currently transforms anything matching /[._-](pre|rc|test|git|old|trunk)/ into ~$1, and then compares using 'dpkg --compare-versions'. We should definitely improve GRUB's sorting algorithm; 'sort -n' is obviously over-simplistic (consider 2.6.9 vs. 2.6.10 - the -n option isn't enough to compare each component numerically). The Debian patch largely makes it work fine in practice but there's been the odd glitch. While I could patch it in Debian to use linux-version instead, I'd much rather have something we can agree on upstream, and clearly a Debian-specific command won't cut it there. The above algorithm seems simple enough; I can probably find time to propose a strawman patch to grub-mkconfig_lib for that at some point. The main thing that I'm unsure about in DebianLinux's algorithm is the pre-release handling. Debian GRUB has several more ways in which pre-releases have been named, as mentioned above, and while they may not be used right now I'm pretty sure that we added them because they were used in the past. Is there any reason not to add those extra names for pre-releases to DebianLinux? Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110424212133.gp31...@riva.ucam.org
Bug#619670: initramfs-tools: make robust against libraries only runtime-linkable due to /etc/ld.so.conf*
Package: initramfs-tools
Version: 0.98.8
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch natty
We had a rather obscure Ubuntu bug
(https://bugs.launchpad.net/bugs/728611) which presented as Plymouth not
being able to display text at boot time, which of course is nasty in
cases where the user needs to answer a prompt in order for boot to
complete. This turned out to be restricted to configurations where
Plymouth is built into the initramfs, so I chased this down.
The problem is that /lib/plymouth/label.so now transitively links to
libGL, which (on Ubuntu, at least) lives in /usr/lib/mesa/libGL.so.1 or
some other subdirectory of /usr/lib depending on the GL implementation
in use (fglrx, nvidia, etc.). This directory isn't on the linker's
default search path; instead, it relies on /etc/ld.so.cache having been
built appropriately from a configuration including
/etc/ld.so.conf.d/GL.conf, which is managed by update-alternatives. The
thing that's going wrong here is that /usr/lib/mesa/libGL.so.1 is copied
into the initramfs, but it isn't on the linker's search path so
/lib/plymouth/label.so fails to load.
I looked at fixing this by copying in /etc/ld.so.conf* and running
ldconfig, but this turned out to be very difficult due to the way
mkinitramfs symlinks libraries during initramfs creation, and I ended up
giving this up as infeasible for the time being. I think it's better to
have copy_exec check whether the target directory name is only on the
linker search path by virtue of /etc/ld.so.conf*, and if so, install to
/lib or /usr/lib as appropriate instead.
I don't know whether you'll want to take this patch exactly, or refine
it, or do something else entirely; but I've tried to make it relatively
safe and it may be worth it for robustness even if you aren't running
into this problem in Debian right now.
* If copy_exec finds libraries to copy which are only accessible to the
runtime linker by virtue of being listed in /etc/ld.so.conf*, then
install those libraries to /lib or /usr/lib as appropriate instead
(LP: #728611).
=== modified file 'hook-functions'
--- hook-functions 2011-02-09 18:05:28 +
+++ hook-functions 2011-03-26 00:44:38 +
@@ -151,6 +151,21 @@ copy_exec() {
libname=$(basename ${x})
dirname=$(dirname ${x})
+ # Avoid installing to directories which require ld.so.conf
+ # in order to work. (Running ldconfig over the initramfs
+ # would be better, but the way we symlink libraries during
+ # creation stymies that.)
+ if grep -qsx ${dirname} /etc/ld.so.conf /etc/ld.so.conf.d/*;
then
+ case ${dirname} in
+ /usr/lib/*)
+ dirname=/usr/lib
+ ;;
+ /lib/*)
+ dirname=/lib
+ ;;
+ esac
+ fi
+
# FIXME inst_lib
mkdir -p ${DESTDIR}/${dirname}
if [ ! -e ${DESTDIR}/${dirname}/${libname} ]; then
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110326011258.ge9...@riva.ucam.org
Bug#605090: linux-2.6: [RFC] Add a grsec featureset to Debian kernels
On Fri, Dec 03, 2010 at 06:01:47PM +0100, Yves-Alexis Perez wrote: On dim., 2010-11-28 at 10:44 +0100, Yves-Alexis Perez wrote: On sam., 2010-11-27 at 23:56 +, Ben Hutchings wrote: These gids are in the 'dynamically assigned' range and must not be configured into the kernel; see Debian policy §9.2. On this, I'm not sure (but will ask base-passwd maintainers for advice). The gids are configured in KConfig, but can be changed dynamically using sysctl (though that means before procpcs is run the gid is still the static one). It'd be nice to have the same gids on every system, but I'm not sure it's really indispensable. Ok, after talking a bit with Brad Spengler it's a bit hard to make the -proc user runtime-configurable because it'd mean either chown()ing the whole /proc tree after running the sysctl, or something like that. A boot parameter could be used too, but all in all, there are no real nice way to achieve that. So I've requested from base-passwd maintainers the allocation of 5 gids in the 6-64999 range, and I'm waiting for their comment. I let Yves-Alexis know by private e-mail, but, for the public record, I allocated these gids as requested. http://bzr.debian.org/scm/loggerhead/users/cjwatson/base-passwd/trunk/revision/155 -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101204184821.ga18...@riva.ucam.org
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Wed, Aug 25, 2010 at 05:44:32AM +0100, Ben Hutchings wrote: On Tue, 2010-08-24 at 16:55 +0100, Colin Watson wrote: Actually, what I want is a consistent way to disable bootloader invocation for all bootloaders, without necessarily requiring the bootloader package not to be installed (since that's sometimes extremely awkward to arrange). Exactly where this goes I can't say I mind. If the result is an extension to the bootloader/kernel policy that needs to be implemented in each bootloader package, that would be fine too. [...] OK, so something like this: Boot loader packages must be installable on the filesystem in a disabled state where they will not write to the boot sector or other non-filesystem storage. While a boot loader is disabled, any kernel and initramfs hooks it includes must do nothing except (optionally) printing a warning that the boot loader is disabled, and must exit successfully. This is a good start, but it doesn't specify *how* boot loader packages are to be disabled. I think that this needs to be consistent across boot loaders. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100828083541.gr12...@riva.ucam.org
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Sat, Aug 28, 2010 at 02:47:56PM +0100, Ben Hutchings wrote: On Sat, 2010-08-28 at 09:35 +0100, Colin Watson wrote: This is a good start, but it doesn't specify *how* boot loader packages are to be disabled. I think that this needs to be consistent across boot loaders. That would be good, but it is already a problem you have to deal with in creating a live distribution (e.g. you don't want an invocation of 'lilo' without arguments to install on some random disk chosen at build time). I believe it is out of scope for this policy. For what it's worth, I think the basic answer is 'don't create a configuration file'. However, elilo will do that on installation by default, so you need to set debconf variable elilo/runme to false. Speaking as the grub2 maintainer, this is not particularly helpful there as the packaging creates a configuration file on installation if requested based on debconf interaction. Of course I can invent some way to change this but I would like that to be consistent with other boot loaders - that being part of the point of this report! -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100828140039.gs12...@riva.ucam.org
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
Package: initramfs-tools Version: 0.98 Severity: wishlist User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu maverick In the case where one is building an image and part of the image build involves running update-initramfs, it would be useful to have a single guaranteed way to disable installing any bootloader. Individual bootloader hooks in /etc/initramfs-tools/post-update.d/ can do this, but it would be better to have something central. Should this be an environment variable or perhaps a configuration file entry? (This was originally filed by Loïc Minier as https://bugs.launchpad.net/bugs/623375.) Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100824132505.gc21...@riva.ucam.org
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, Aug 24, 2010 at 02:45:44PM +0100, Ben Hutchings wrote: On Tue, 2010-08-24 at 14:25 +0100, Colin Watson wrote: In the case where one is building an image and part of the image build involves running update-initramfs, it would be useful to have a single guaranteed way to disable installing any bootloader. Individual bootloader hooks in /etc/initramfs-tools/post-update.d/ can do this, Minus the -tools; it's supposed to be shared with any other initramfs builders. Oops, yes. but it would be better to have something central. Should this be an environment variable or perhaps a configuration file entry? So far as I can see, the only reason to override post-update hooks is that one is cross-building an initramfs. In that case update-initramfs is still used for updating the host's initramfs and should continue to invoke the hooks when doing that. So this should be a command-line option and not a configuration option. Consider building a filesystem image inside a chroot which one is about to build into a live filesystem image with mksquashfs or something. In the event that it contains flash-kernel, then the flash-kernel hook (once such a thing exists; in the meantime, the hardcoded flash-kernel code in run_bootloader) will write to the host system's flash memory. (Take another similar example if you disagree with the precise details of this one; LILO may well have similar properties.) In this case, changing update-initramfs' command line is likely to be most inconvenient, as it will be called from postinst scripts and the like. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100824135404.gd21...@riva.ucam.org
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, Aug 24, 2010 at 04:08:47PM +0100, Ben Hutchings wrote: On Tue, 2010-08-24 at 16:55 +0200, Michael Prokop wrote: * Ben Hutchings b...@decadent.org.uk [Tue Aug 24, 2010 at 03:45:36PM +0100]: If you insist on installing such a package in the live system then it needs to support a safe configuration where it won't do anything until the user configures it to. It doesn't matter whether it's invoked by the kernel, initramfs-tools, or anything else. It *must* require user configuration. Jepp. But isn't this (possibility for user configuration) exactly what Colin is requesting? No, he was asking for a way to disable hook invocation (which is something of a blunt tool). Actually, what I want is a consistent way to disable bootloader invocation for all bootloaders, without necessarily requiring the bootloader package not to be installed (since that's sometimes extremely awkward to arrange). Exactly where this goes I can't say I mind. If the result is an extension to the bootloader/kernel policy that needs to be implemented in each bootloader package, that would be fine too. I'm for example shipping lilo and grub with the live system (so the binaries as well as its documentation is available to the user), but nowadays the build process fails due to errors like: run-parts: /etc/initramfs/post-update.d//lilo exited with return code 1 [...] run-parts: /etc/kernel/postinst.d/zz-lilo exited with return code 1 So the IMHO open question is what's a proper way to disable such stuff on request? Report a bug on lilo; I suppose it should warn but still 'succeed' if /etc/lilo.conf is missing. elilo should do the same. This is my bug and I can fix it. :-) No idea about zipl but I doubt you care about s390 live media. What I specifically do not want is for top-level client programs to have to keep track of the different ways to ensure that each individual bootloader is disabled. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100824155518.go12...@riva.ucam.org
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, Jun 28, 2010 at 03:02:35AM +0100, Ben Hutchings wrote: 1. Packages for boot loaders that need to be updated whenever the files they load are modified (i.e. those that store a block list) must install hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which will be called on installation/upgrade and removal of kernel packages, respectively. It seems to me (particularly from the fact that you upgraded a grub2 bug report about this to important - GRUB 2 does not store block lists for kernels) that this is not limited to boot loaders that store block lists for the files they load: it also affects boot loaders that need to be updated whenever the *list* of files they load is modified. Can you confirm that my understanding is correct? 2. Packages for boot loaders that need to be updated whenever the files they load are modified must also install hook scripts in /etc/mkinitramfs/post-update.d. Initramfs builders must call these scripts using run-parts after they create, update or delete an initramfs. The arguments given to these hook scripts are the kernel ABI version and the absolute path to the initramfs image. Does the same apply here, or not? This is going to be quite a lot of calls to update-grub if so, although at least it's quite a bit faster now than it used to be ... 3. Initramfs builders must complete their work before returning from the kernel postinst hook script. [initramfs-tools currently uses a trigger to defer this because it can also be invoked twice, but this means it also has to know how to update specific boot loaders.] Is an initramfs guaranteed to be built before any of the boot loader hooks are executed? It seems like a waste of time calling boot loader hooks otherwise. (This may be implied by your design, but it was a little bit implicit if so.) 4. During a kernel package installation, upgrade or removal, various boot loader hooks may be invoked (in this order): a. A postinst_hook or postrm_hook command set by the user or the installer in /etc/kernel-img.conf b. A hook script in /etc/mkinitramfs/post-update.d c. A hook script in /etc/kernel/postinst.d or .../postrm.d To avoid unnecessary updates, the hooks invoked at step a and b may check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and do nothing in this case. [Is this sensible or is it too 'clever'?] Sensible, I think. There's no point running update-grub three times. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100628221906.ga28...@master.debian.org
Re: Processed: reassign 586148 to src:grub2
reassign 586148 grub-pc forcemerge 586056 586148 thanks On Wed, Jun 16, 2010 at 09:09:06PM +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: reassign 586148 src:grub2 Bug #586148 [linux-2.6] linux-image-2.6.34-1-amd64: Fails to install while running 'update-grub': Invalid parameter, 2.6.34-1-amd64 Bug reassigned from package 'linux-2.6' to 'src:grub2'. Bug No longer marked as found in versions 2.6.34-1~experimental.2. This is #586056, fixed in grub2 1.98+20100614-2. Sorry for the inconvenience. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100616215153.gi12...@riva.ucam.org
Bug#585897: initramfs-tools: allow multiple break points
Package: initramfs-tools
Version: 0.96.1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch maverick
This patch is a rebased version of one from Evan Dandrea (CCed), and
allows specifying multiple break points using a comma delimiter. This
is sometimes convenient when debugging the initramfs. I added some
brief documentation.
diff --git a/initramfs-tools.8 b/initramfs-tools.8
index fd00429..7d95709 100644
--- a/initramfs-tools.8
+++ b/initramfs-tools.8
@@ -124,6 +124,7 @@ spawns a shell in the initramfs image at chosen run-time
The default is premount without any arg.
Beware that if both panic and break are present,
initramfs will not spawn any shells but reboot instead.
+Multiple break points may be given, separated by commas.
.TP
\fB\fI netconsole
diff --git a/scripts/functions b/scripts/functions
index 685642e..89451c7 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -55,7 +55,7 @@ panic()
maybe_break()
{
- if [ ${break:-} = $1 ]; then
+ if echo ${break:-} | egrep -q (,|^)$1(,|$); then
panic Spawning shell within the initramfs
fi
}
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100614175906.gs21...@riva.ucam.org
Bug#365128: Seen here also..
On Mon, Dec 22, 2008 at 06:04:36PM +0100, Moritz Muehlenhoff wrote: Romain Beauxis wrote: Unfortunately, I do not have the hardware anymore.. Colin, do you still own the hardware? I'm afraid it's been non-functional (in a refuses to power up kind of way) for a while, and I haven't had a chance to figure out what's wrong with it. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Beta1 missing decisions and possible timeline
On Fri, Feb 01, 2008 at 09:51:07PM -0500, Joey Hess wrote: It's far to early to switch d-i to 2.6.24, especially since it drops support for most of /proc/acpi, including the parts used by laptop-detect. I suspect you already know this, but for the record, that's not an intrinsic property of 2.6.24; enabling CONFIG_ACPI_PROCFS_POWER again will restore compatibility. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447153: /usr/bin/scp: Fails to notice write errors
On Mon, Nov 12, 2007 at 08:13:42PM +0100, Michal Suchanek wrote: On 12/11/2007, Colin Watson [EMAIL PROTECTED] wrote: To openssh-unix-dev: does anyone think this is worth a workaround? The ftruncate seems rather unnecessary if we've already written out the required number of bytes anyway. I've attached a patch which only does it if that isn't the case (although I have some trouble seeing how we could ever get to the ftruncate without either writing the required number of bytes or encountering a write error). If people think it's a good idea I'll file it in Bugzilla. I do not know the scp code so I might be missing something. However, truncating the file might be necessary when there is already a file, and it was originally longer. Whoops! You're quite right; I blame the jetlag. (Though, since current portable CVS checks whether the file exists before trying to ftruncate it, simply changing '!exists || S_ISREG(stb.st_mode)' to 'exists S_ISREG(stb.st_mode) (new file shorter than old file)' would be another possibility; I can't see why you would want to truncate if it didn't previously exist, and the only way you can run into this bug if you're shortening an existing file is if you're copying over the top of an existing sparse file, which is even more of a crazy corner case than this already is. It looks like a bug either in the kernel or in ftruncate documentation. It is certainly true that the write error should get reported at some point if it occurs, and a filesystem that chooses to not return it on write() should save the errors for close(). However, using ftruncate() on the file does, in some sense, successfully extend the file to the desired length. It looks like such mixing of calls was not expected by the fs driver, and may not be well defined in general. I understand your point, and I spent a little while pondering it before sending my mail. I think that if the write syscall doesn't actually write the bytes out to the filesystem then that's its own problem. If the write returns a non-zero number of bytes, ftruncate should behave in all cases *as if* those bytes have been written to the filesystem, even if they haven't actually quite been written yet. POSIX is pretty consistent in this; implementation details of buffering shouldn't be exposed except where they're explicitly defined to be exposed. (However, we should be having this debate on the linux-cifs-client list, not openssh-unix-dev ...) I would suggest closing the file, and if it needs truncating, reopen and truncate it (or do some voodoo with duplicated fds if possible). Something like that would be another reasonable workaround, yes. Truncating only if the file already exists and the new one is shorter seems simpler to me, but I'm not all that bothered about the exact approach. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447153: /usr/bin/scp: Fails to notice write errors
On Tue, Nov 13, 2007 at 12:02:25AM +0100, Peter Stuge wrote: On Mon, Nov 12, 2007 at 06:33:54PM +, Colin Watson wrote: To openssh-unix-dev: does anyone think this is worth a workaround? Gut feeling is that it should be fixed wherever the problem is. Yeah, that's why I sent my mail to the CIFS list as well. Kernels won't get upgraded instantly even if it gets fixed right away though, so OpenSSH might want to regard it as a portability fix ... The ftruncate seems rather unnecessary if we've already written out the required number of bytes anyway. Not neccessarily, we may be overwriting a larger file with the same name. Indeed; see the other part of this thread. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401384: fixed in mkvmlinuz 28
found 401384 29 thanks On Fri, Dec 15, 2006 at 11:17:03PM +, Sven Luther wrote: mkvmlinuz (28) unstable; urgency=low . * Added support for 2.6.19 kernels. * Added portuguese translation. (Closes: #401384) pt.po doesn't actually appear to be in the tarball (I'm looking at mkvmlinuz_29.tar.gz); did you maybe forget to 'svn add' it? Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374185: mkvmlinuz: syntax errors in script
On Wed, Jul 12, 2006 at 10:42:38PM +0200, Bastian Blank wrote: reopen 374185 unreproducible severity 374185 important thanks On Wed, Jul 12, 2006 at 09:50:53AM +0100, Colin Watson wrote: This part of the report is still valid no matter whether you're using dash or bash. In bash, I get: /usr/sbin/mkvmlinuz: 61: arith: syntax error: OPTIND-1 | $ cat test.sh | shift $((OPTIND-1)) | $ bash -x test.sh | + shift 0 Oh, I do apologise, it turned out that my /bin/sh was dash after all so I got confused. Using non-$-prefixed variables inside arithmetic expansion was a bit of shell syntax [1] that I wasn't aware of. Sven: it was OPTIND = $OPTIND I was talking about, not the added spaces. It doesn't seem unreasonable to change mkvmlinuz to work around this dash bug (linked to by Gerrit) for now, though. Personally (and I suppose it's a matter of taste) I find it clearer to $-prefix variables even inside arithmetic expansions. [1] http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_04 Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378089: initramfs-tools: create /etc/initramfs-tools/conf.d in preinst before writing to it
Package: initramfs-tools
Version: 0.68b
Severity: important
Tags: patch
The .deb's filesystem archive hasn't yet been unpacked when the preinst
runs, so you aren't allowed to depend upon directories shipped in the
.deb existing at that point. Patch attached.
It also occurs to me that this bug may have produced
/etc/initramfs-tools as a regular file, due to this incautious code:
cp /etc/mkinitrd/modules /etc/initramfs-tools
You should append a trailing slash when copying to directories to defend
against this; my patch also does this.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
diff -ru initramfs-tools-0.68b.orig/debian/initramfs-tools.preinst
initramfs-tools-0.68b/debian/initramfs-tools.preinst
--- initramfs-tools-0.68b.orig/debian/initramfs-tools.preinst 2006-07-07
10:51:01.0 +0100
+++ initramfs-tools-0.68b/debian/initramfs-tools.preinst2006-07-13
09:34:15.0 +0100
@@ -5,6 +5,8 @@
case $1 in
configure)
if [ -n $2 ]; then
+ mkdir -p /etc/initramfs-tools/conf.d
+
# First time install. Can we autodetect the RESUME partition?
RESUME=$(tail -n $(($(wc -l /proc/swaps | awk ' { print $1 } ')
- 1)) /proc/swaps | sort -rk3 | head -n 1 | awk ' { print $1 } ')
@@ -18,7 +20,7 @@
# Add initrd-tools modules, while trying to minimize prompting
if [ -e /etc/mkinitrd/modules ]; then
- cp /etc/mkinitrd/modules /etc/initramfs-tools
+ cp /etc/mkinitrd/modules /etc/initramfs-tools/
sed -i \
-e 's/\/etc\/mkinitrd\/modules: Kernel modules to
load for initrd./List of modules that you want to include in your initramfs./g'
\
-e 's/mkinitrd/update-initramfs/g' \
Bug#374185: mkvmlinuz: syntax errors in script
reopen 374185 thanks On Sat, Jun 17, 2006 at 08:15:29PM +0200, Wouter Verhelst wrote: --- mkvmlinuz.orig2006-06-17 20:03:05.0 +0200 +++ /usr/sbin/mkvmlinuz 2006-06-17 20:13:40.0 +0200 @@ -60,7 +60,7 @@ esac # use non-option arguments as release version and kernel image file if needed -shift $((OPTIND-1)) +shift $(( $OPTIND - 1 )) if test -z $release -a -n $1; then release=$1 fi This part of the report is still valid no matter whether you're using dash or bash. In bash, I get: /usr/sbin/mkvmlinuz: 61: arith: syntax error: OPTIND-1 Please apply this part of Wouter's patch. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365978: Uploader wanted ...
On Mon, May 08, 2006 at 09:37:35PM +0200, Sven Luther wrote: I have fixed this bug in svn, but cannot upload due to not having access to my gpg key until thursday. It would be nice if someone could upload it. It needs someone with access to a powerpc build machine though. Colin or Bastian are obvious choices. Sure, I can do this (although I can't tag it in svn). Is svn://svn.debian.org/svn/kernel/dists/trunk/utils/mkvmlinuz/mkvmlinuz the correct URL? Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365978: Uploader wanted ...
On Tue, May 09, 2006 at 09:03:37PM +0200, Sven Luther wrote: On Tue, May 09, 2006 at 09:48:17AM +0100, Colin Watson wrote: Sure, I can do this (although I can't tag it in svn). Is svn://svn.debian.org/svn/kernel/dists/trunk/utils/mkvmlinuz/mkvmlinuz the correct URL? Yes it seems correct (well, if you can check it out it is ok, if not there is a typo i missed at first glance). Once i see the upload, i will tag it, i have control of my ssh key here. OK, uploaded. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365978: mkvmlinuz: doesn't clean up temporary directory
Package: mkvmlinuz Version: 20 Severity: minor mkvmlinuz doesn't clean up its temporary working directory; the line at the end of the script that would normally do this is commented out. I appreciate that this might sometimes be useful for debugging, but could this please be controlled by an option or an environment variable rather than being the default behaviour? (I noticed this when my 512MB /tmp filled up after a few d-i daily builds.) Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365128: linux-image-2.6.16-1-powerpc: oops while running two X servers
cairhien kernel: Call Trace: Apr 21 07:43:48 cairhien kernel: [C0ABBF20] [C0130F80] radeon_set_backlight_enable+0xa8/0x758 (unreliable) Apr 21 07:43:48 cairhien kernel: [C0ABBF40] [C00215E0] backlight_callback+0x8c/0x154 Apr 21 07:43:48 cairhien kernel: [C0ABBF60] [C0040594] run_workqueue+0xa4/0x108 Apr 21 07:43:48 cairhien kernel: [C0ABBF70] [C00407B4] worker_thread+0xec/0x138 Apr 21 07:43:48 cairhien kernel: [C0ABBFC0] [C004466C] kthread+0xd4/0x110 Apr 21 07:43:48 cairhien kernel: [C0ABBFF0] [C0011174] kernel_thread+0x44/0x60 Apr 21 07:43:48 cairhien kernel: Instruction dump: Apr 21 07:43:48 cairhien kernel: 409e0010 3d20c029 3b892540 480c 3d20c029 3b892500 387f0a20 3ba0 Apr 21 07:43:48 cairhien kernel: 4bf082cd 813f0358 38090e40 7c00042c 0c00 4c00012c 5400067e 3861 lspci / lspci -n output: :00:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 AGP :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 0001:10:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 PCI 0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) 0001:10:13.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller 0001:10:17.0 ff00: Apple Computer Inc. KeyLargo/Intrepid Mac I/O 0001:10:18.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB 0001:10:19.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB 0001:10:1a.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB 0001:10:1b.0 USB Controller: NEC Corporation USB (rev 43) 0001:10:1b.1 USB Controller: NEC Corporation USB (rev 43) 0001:10:1b.2 USB Controller: NEC Corporation USB 2.0 (rev 04) 0001:11:00.0 Network controller: Intersil Corporation Intersil ISL3890 [Prism GT/Prism Duette] (rev 01) 0002:24:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 Internal PCI 0002:24:0d.0 ff00: Apple Computer Inc. UniNorth/Intrepid ATA/100 0002:24:0e.0 FireWire (IEEE 1394): Apple Computer Inc. UniNorth 2 FireWire (rev 81) 0002:24:0f.0 : Apple Computer Inc. UniNorth 2 GMAC (Sun GEM) (rev ff) :00:0b.0 0600: 106b:0034 :00:10.0 0300: 1002:4e50 0001:10:0b.0 0600: 106b:0035 0001:10:12.0 0280: 14e4:4320 (rev 03) 0001:10:13.0 0607: 104c:ac56 0001:10:17.0 ff00: 106b:003e 0001:10:18.0 0c03: 106b:003f 0001:10:19.0 0c03: 106b:003f 0001:10:1a.0 0c03: 106b:003f 0001:10:1b.0 0c03: 1033:0035 (rev 43) 0001:10:1b.1 0c03: 1033:0035 (rev 43) 0001:10:1b.2 0c03: 1033:00e0 (rev 04) 0001:11:00.0 0280: 1260:3890 (rev 01) 0002:24:0b.0 0600: 106b:0036 0002:24:0d.0 ff00: 106b:003b 0002:24:0e.0 0c00: 106b:0031 (rev 81) 0002:24:0f.0 : 106b:0032 (rev ff) Let me know if there's anything else you need. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#364996: linux-kernel-di-powerpc-2.6: please add apus subarch, apus is currently kind-of using the non-working 2.4.27 stuff still
On Thu, Apr 27, 2006 at 09:51:18AM +0200, Sven Luther wrote: Package: linux-kernel-di-powerpc-2.6 Version: 1.14 Severity: important As said, please add an apus flavour also, in order to be able to get ride of the 2.4.27 apus flavour in d-i, which i am not sure is working anymore, given the state of 2.4.27 in etch/sid. I'd be happy to, but there's no linux-image-2.6.* package for apus yet. Looking at the kernel trunk in svn, perhaps apus needs to be added to flavours: in arch/powerpc/defines? Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#364996: linux-kernel-di-powerpc-2.6: please add apus subarch, apus is currently kind-of using the non-working 2.4.27 stuff still
On Thu, Apr 27, 2006 at 03:04:31PM +0200, Sven Luther wrote: On Thu, Apr 27, 2006 at 02:58:56PM +0200, Bastian Blank wrote: On Thu, Apr 27, 2006 at 01:49:56PM +0100, Colin Watson wrote: I'd be happy to, but there's no linux-image-2.6.* package for apus yet. Looking at the kernel trunk in svn, perhaps apus needs to be added to flavours: in arch/powerpc/defines? No. APUS is marked as broken upstream since a long time. So what ? Why do you think we have had an apus patch in until 2.6.15. I need to look over the apus patch, and port it to 2.6.16, didn't have time to do this yet though, help is welcome. prep is also broken now anyway, and needs fixing. The 2.6.15-2.6.16 migration clearly did bring a lot of trouble and work. That said, only 2.6.15 is in testing for now, so i wonder the wisdom of building d-i images based on 2.6.16. The daily d-i builds are based on unstable, not testing; if we didn't do that it would be much more difficult to qualify installer packages in unstable for inclusion into testing. Essentially we'd just end up with a broken testing before we realised the problems. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge upgrade - linux, grub conflict
On Mon, Apr 17, 2006 at 11:38:54AM +0200, Bastian Blank wrote: On Sun, Apr 16, 2006 at 09:59:55PM -0700, Steve Langasek wrote: On Mon, Apr 17, 2006 at 12:29:04AM +0200, Bastian Blank wrote: For sarge updates of the linux kernels, grub needs to be updated before linux-image*. Can this be forced by an conflict with older versions? A dependency is not appropriate. Can you give more detail on why grub needs to be updated first? I haven't heard anything about this incompatibilty, and would like to understand it before endorsing a versioned conflict; there's a very good chance that a versioned conflict with grub would force removal, not upgrade, of the bootloader. kernel-package 10 uses debconf for the user communication. This includes the pre and post scripts specified in /etc/kernel-img.conf. update-grub from grub older than 0.97-3 writes informations to stdout, which is coupled to debconf and makes it fail. Surely sarge kernel updates should be using the kernel-package in sarge, namely 8.135. If there are changes needed from later versions of kernel-package, they should be backported. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#359164: [powerpc64] d-i fails, base-installer/initramfs/no-generator
On Mon, Mar 27, 2006 at 04:43:12PM +0200, Sven Luther wrote: On Mon, Mar 27, 2006 at 02:23:47AM +0200, Frans Pop wrote: This is not an initramfs-tools problem, but the result of powerpc daily d-i builds, for which Sven himself is responsible, failing for the last few days. I didn't touch the buildd since more than a week, so it is clear that (again) the d-i team broke the daily builds and don't take the responsability to fix them. Bashing on your porter is fine, but then don't expect them to fix stuff at your whim, and do the job yourself. I hereby officially announce that i won't continue to do the ungratefull job of powerpc d-i porting, i hear the d-i team has plenty of folk to take my place, so they should fix this. I've set up http://people.debian.org/~cjwatson/d-i/images/; the images there are untested, and I haven't yet cronned the build (I probably need to get my Pegasos going again and move it there, rather than trying to do it on my laptop), but I'll try to get that sorted out sometime this week. If you'd like me to take this job over permanently, I'm prepared to do so. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Graphical installer - invitation to get involved
On Sat, Dec 03, 2005 at 03:26:30PM +0100, Sven Luther wrote: On Sat, Dec 03, 2005 at 12:05:25PM -0200, Otavio Salvador wrote: No. Current uplash is in userspace. I work on Splashy that's another alternative and it works well. We'll probably move it from experimental to sid soon. Oh, then it was the x86/vesa only thingy ? usplash works fine on x86/vga16fb, x86/vesafb, and powerpc/offb at least. It just uses bogl (like d-i) so it should be straightforward to port nearly anywhere. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Graphical installer - invitation to get involved
On Sat, Dec 03, 2005 at 06:35:33PM +0100, Frans Pop wrote: On Saturday 03 December 2005 18:18, Colin Watson wrote: usplash works fine on x86/vga16fb, x86/vesafb, and powerpc/offb at least. It just uses bogl (like d-i) so it should be straightforward to port nearly anywhere. What happens on sercon installations? It only activates if you put 'splash' on the kernel command line; we've set up *-installer to avoid that if debian-installer/framebuffer is false. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Supporting 2.6.14 kernels in base-installer
On Mon, Nov 14, 2005 at 04:15:36PM -0500, Joey Hess wrote: Jonas Smedegaard wrote: I don't understand what temporary hardcoding of root partition actually means. Yaird looks at /etc/fstab for the root partion. d-i currently does this before installing mkinitrd-tools: # Temporarily hardcode the root partition. rootpart_devfs=$(mount | grep on /target | cut -d' ' -f1) rootpartfs=$(mount | grep on /target | cut -d' ' -f5) rootpart=$(mapdevfs $rootpart_devfs) if [ -f $mkinitrdconf ]; then sed -e s#^ROOT=.*#ROOT='$rootpart $rootpartfs'# $mkinitrdconf $mkinitrdconf.new mv $mkinitrdconf.new $mkinitrdconf else echo ROOT='$rootpart $rootpartfs' $mkinitrdconf fi Appacently Colin has already checked that initramfs-tools doesn't need such a hack, Right; Jeff Bailey has been very clear to me that it can work it out based on what it's told by the bootloader. Some lilo modifications may be needed at some point to pass the root filesystem as a device name rather than in lilo's hex-encoded major/minor form (which I'm told will eventually break due to kernel changes, and probably doesn't work so well for wacky block devices even now), either by changing lilo directly to do that or just by making lilo-installer override it by adding root= to the kernel command line in append=. initramfs-tools does handle lilo's current syntax for the moment, though. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what happened to vesafb support in 2.6.13-1?
On Wed, Oct 12, 2005 at 02:35:39PM +0200, Maximilian Attems wrote: On Wed, Oct 12, 2005 at 03:31:18PM +0900, Horms wrote: On Sun, Oct 09, 2005 at 06:00:55PM +0200, Maximilian Attems wrote: the old legacy modular vesafb patch got dropped. and it seems it was overlooked to set them to yes. I think I might have made that change, and at the very least I remember discussing it. I think that the idea was that it has actually been superceeded by another module. However if this isn't the case, I guess setting it to yes is a good idea. Does anyone know what this might break? well the d-i guys should get a notice: currently vesa failed by default so they dropped into vga16, which is known not to work on a range of laptops. On some laptops, only vga16fb works. On others, only vesafb works. The reason we try both is so that you can have vga16fb by default (which has fairly good coverage, albeit not perfect) and try vesafb if you know the right vga=MODE argument to give the kernel. Matthew Garrett tells me that only vga16fb supports suspend/resume. as background info the old half-baken vesa modular patch conflicts with upstream fixes. hch, waldi and i decided that to be a good time to drop it. Unless the hardware support of one or other framebuffer driver has been radically improved, or unless there's something else I'm misunderstanding, I think we still need modular vesafb? Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.13, experimental and 2.6.14-rc ...
On Thu, Oct 06, 2005 at 01:09:59PM +0200, Sven Luther wrote: On Thu, Oct 06, 2005 at 06:45:13PM +0900, Horms wrote: I am, right at this moment, building 2.6.13-1.experimental.1, and This should be 2.6.13-0.experimental.1, which would be lower than 2.6.13-1 which we would upload to unstable. Don't forget to make sure you include the .orig tarball though, as i don't think it is included in 0.experimental.1 by default. That ought to be 2.6.13-0experimental1, otherwise various bits of the archive maintenance software will treat it as a binary-only NMU in some ways and get confused. I've made that mistake before ... -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315654: devfs is being removed NOW
On Sat, Jul 30, 2005 at 03:42:19PM +0200, Christoph Hellwig wrote: On Sat, Jul 30, 2005 at 08:22:31PM +1000, Russell Coker wrote: The 2.6.13 rc kernels have devfs removed. Debian won't support 2.6.13 until this problem is fixed. Debian works just fine without devfs once installed, thanks. Please reassign to whatever d-i component relies on devfs to pull in the Ubunutu changes. No, there is no need for that. I committed all the relevant changes from Ubuntu to d-i some time ago, with the exception of one small change to IIRC lilo-installer that's waiting for a newer busybox release with 'readlink -f' support. It can be enabled whenever d-i switches to 2.6.13. Please do not reassign this bug, as initrd-tools really *does* need fixing. (There's no fix for this bug in Ubuntu yet either.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
On Tue, Jul 26, 2005 at 03:26:04PM +0200, Goswin von Brederlow wrote: The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n and kernel-image packages without any regards to linux-kernel-di. They will become out of sync and end up without source - GPL violation. Last I checked, dak was being reeducated so that it could be told about udebs it needed to keep around due to them being in initrd builds. The same approach could be used fairly easily to keep kernel source around until the corresponding udebs have been rebuilt. The main problem with moving udebs into the kernel build process, I think, is that the installer team needs to be able to change their structure relatively frequently; for example, the exact balance of modules in various udebs affects whether it's possible to build installer floppies and other media with space restrictions. Historically, having the udebs be controlled by the d-i team made sense. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with = 48mb RAM
On Tue, Jul 26, 2005 at 12:45:48AM +0100, Luke Kenneth Casson Leighton wrote: On Mon, Jul 25, 2005 at 03:51:22PM -0700, Matt Taggart wrote: It would probably be a good idea to record what ought to work in any given release and maybe have an ongoing idea what it should be. The answer might be architecture specific? ISTR either the d-i team or apt/dpkg/aptitude trying to get sarge systems with 32mb working towards the end of the release. if you really want to try that out, without messing with older hardware, try usin XEN. No need to mess with older hardware *or* Xen. Use the mem=32M (etc.) kernel parameter. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290329: testing on PowerMac
FWIW, MODULES=dep works fine for me on my PowerBook. I think this change is probably worth it - we've had a number of issues in the past with large initrds on powerpc. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306355: linux-image-2.6.10-5-k7-smp: fails to boot on udev system
On Tue, Apr 26, 2005 at 03:22:49AM +0300, Pasi Savolainen wrote: Package: linux-image-2.6.10-5-k7-smp Version: 2.6.10-34 Severity: important This appears to be a bug report against an Ubuntu kernel. Please report those to Ubuntu, not Debian. Is there anything in particular that misled you into reporting this bug to Debian? If so, perhaps we could fix it. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297794: kernel-image-2.4.27-powerpc: postinst almost completely missing, breaks installer
Package: kernel-image-2.4.27-powerpc Version: 2.4.27-3 Severity: critical The complete contents of kernel-image-2.4.27-powerpc.postinst are now as follows: #!/bin/sh set -e # Automatically added by dh_installmodules if [ $1 = configure ] [ -x /sbin/update-modules ]; then update-modules /dev/null fi # End automatically added section When inserting this packages into a test image, the /vmlinux symlink is naturally never created, and the installation fails. Please fix this immediately, preferably by reverting to the previous well-tested postinst from kernel-package. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with kernel on SATA hosts - RC?
On Wed, Dec 01, 2004 at 03:27:56PM +0100, Richard Atterer wrote: On Wed, Dec 01, 2004 at 03:06:17AM -0800, Steve Langasek wrote: On Wed, Dec 01, 2004 at 12:01:29PM +0100, Richard Atterer wrote: Obviously, you cannot load the SATA modules if you need the SATA code to access the hard disc. Of course you can, that's what initial ramdisks are for. Initially, I also thought that, but I have been unable to get things to work using the standard Debian kernel packages. After installing sarge, I uninstalled grub and installed lilo (just a personal preference). Everything continued to work. I then installed kernel-image-2.6.8-1-686 2.6.8-10. (Actually, I tried kernel-image-2.6.8-1-386 first, replacing the previous, working setup - doh!) After that, a reboot resulted in lilo loading the kernel, the kernel starting up, but panicking after a short while. I have verified that lilo.conf is set up correctly, including the right initrd=... setting. The error messages output by the kernel are as follows: pivot_root: No such file or directory /sbin/init: Cannot open /dev/console: no such file or directory Kernel panic: Attempted to kill init! That sounds like a bug in initrd-tools. SATA modules really do work in initrds; I have a machine set up this way right in front of me, which works out of the box. It would be a regression to jam them back into the kernel monolithic-style (for one, it would probably make it impossible to put the kernel on a floppy). Do these messages this apply to the /dev inside the initrd?? FWIW, the machine does not use udev or devfs. Those messages indicate that the init in the initrd can't figure out how to mount your real root partition. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#272139: /sys/block names are mangled with '!' in current 2.6 kernels, not '.'
Package: initrd-tools
Version: 0.1.74
Severity: important
Devices such as /dev/cciss/c0d0p1 used to have their names mangled in
/sys/block with '.' in place of '/', producing paths like
/sys/block/cciss.c0d0/cciss.c0d0p1/dev. However, current kernels use '!'
rather than '.' as the mangling character, so you get
/sys/block/cciss!c0d0/cciss!c0d0p1/dev. See
http://mail.nl.linux.org/linux-mm/2003-12/msg00087.html for some related
comments, fixing another part of the kernel to cope with this.
The upshot is that initrds generated by initrd-tools fail to figure out
how to mount root filesystems on CCISS devices.
/usr/share/initrd-tools/init copes with the old naming, like this:
IFS=/
set -f
set +f ${root#/dev/}
IFS=.
root=$*
unset IFS
try_name $root return
It's probably best for us to try both. The following patch (actually
against 0.1.70 rather than 0.1.74, but should still apply) works for me:
http://www.no-name-yet.com/patches/initrd-tools.sys-block.diff
Cheers,
--
Colin Watson [EMAIL PROTECTED]
Bug#272139: /sys/block names are mangled with '!' in current 2.6 kernels, not '.'
On Sat, Sep 18, 2004 at 10:25:32AM +1000, Herbert Xu wrote: Martin Michlmayr [EMAIL PROTECTED] wrote: + for separator in . !; do You should try the new separator first, i.e., `!' and then `.'. Otherwise this'll break once people start putting dots in the names. Good call. -- Colin Watson [EMAIL PROTECTED]
Bug#271899: Bug#272139: /sys/block names are mangled with '!' in current 2.6 kernels, not '.'
On Fri, Sep 17, 2004 at 08:07:15PM +0100, Martin Michlmayr wrote: severity 271899 important merge 271899 272139 tags 272139 + pending thanks * Colin Watson [EMAIL PROTECTED] [2004-09-17 19:12]: It's probably best for us to try both. The following patch (actually Thanks, this is much nicer than the patch in 271899 which only copes with the new way. Ah, sorry about the duplicate, I had a look but didn't notice that bug. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: status of d-i 2.4.27/2.6.8 kernel transition
On Sat, Sep 11, 2004 at 06:25:58PM +0200, Thibaut VARENE wrote: On Fri, 10 Sep 2004 09:22:57 -0400 Joey Hess [EMAIL PROTECTED] wrote: archlinux-kernel-di build/configrootskel base-installer hppa2.4.25 [3] 2.4.25 [3] 2.4.20 [7] 2.4.26 [10] [3] hppa far out of date [7] Obviously this is only a fallback, but 2.4.20?! [EMAIL PROTECTED] ~]$ apt-cache search kernel-image-2.4 | grep 32-smp kernel-image-2.4.25-32-smp - Linux kernel image for version 2.4.25 on 32-bit PA-RISC SMP. kernel-image-2.4.26-32-smp - Linux kernel image for version 2.4.26 on 32-bit PA-RISC SMP. kernel-image-2.4.27-32-smp - Linux kernel image for version 2.4.27 on 32-bit PA-RISC SMP. I've grepped 32bit SMP to show only one flavour of each version. I just don't understand WTH are you complaining about hppa being far out of date. I've been releasing each new version in a timely fashion every time I could. Joey is referring to the udebs produced by linux-kernel-di-hppa in the debian-installer repository, not the standard kernel-image debs. You can tell this by the way the column was headed linux-kernel-di. Now if d-i needs special work of mine to sync with kernel updates, I'd better be taught about it. It does. There are plenty of examples in the d-i repository. -- Colin Watson [EMAIL PROTECTED]
Re: Instead of the amd64 GR: rudimentary amd64 support for sarge, need sponsor.
On Tue, Aug 03, 2004 at 12:21:14PM -0400, Daniel Jacobowitz wrote: I don't know how we would want to build it; given the freeze it is probably too late to build it from the GCC source package, unless we want to build it from the gcc-3.4 source package (which presumably is not part of base and thus not frozen). Matthias, how do you feel about that? libgcc1 is produced from the gcc-3.4 source package on many architectures, so it is frozen. It'll have to go through t-p-u. -- Colin Watson [EMAIL PROTECTED]
Bug#249205: [getty-info@mail.nwmagic.net: Re: [syntaxis@gmx.co.uk: Bug#249205: gettyps: no right to modify]]
tags 249205 stable thanks On Mon, May 24, 2004 at 07:55:00PM +1000, Herbert Xu wrote: Date: Tue, 18 May 2004 08:08:48 -0700 From: Christine Jamison [EMAIL PROTECTED] Organization: SPECTRA Software, Inc. To: Herbert Xu [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: Bug#249205: gettyps: no right to modify] Dear Herbert: As the official maintainer of getty_ps (as listed on ibiblio.org), hereinafter referred to as GETTY_GIRL, I do hereby grant the maimtainer(s) of getty_ps on Debian Linux permission to make any and all changes he or she deems necessary or appropriate, as long as GETTY_GIRL gets a copy of said changes. E-mailing a copy of changed sources, or a diff of the same, is the preferred method of transmitting said copy of changes. This permission will remain in effect until explicitly revoked by GETTY_GIRL. Does this meet with your approval? Andrew, You haven't responded; is this sufficient to downgrade the bug? Presumably adding the note to debian/copyright would be nice, but not legally required (nor required by policy, since this isn't in main). I'm also tagging the bug to note that gettyps isn't in testing or unstable. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: 2.4 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
On Wed, Jun 30, 2004 at 10:51:22AM +0200, Sven Luther wrote: Well, nobody seemed to care or comment on this, so let's take this to a wider audience. Christoph has recently told me that he doesn't care about 2.4, and even benh has mentioned to me that 2.4 support for powerpc will be going away in the near term (well, not the eact words, but you get my meaning). And i guess that Jens also is only interested on 2.6 kernels, even though he is comaintainer of the 2.4 kernels too. So, i am seriously considering dropping all 2.4 powerpc kernels, and going with 2.6 only, and would like to get feedback both from debian-kernel as well as debian-powerpc, feedback i didn't get in the past. While generally I think defaulting to 2.6 would be a good idea, I'd really prefer not to drop 2.4 (as in remove the packages) just yet. It's worth noting that no release candidate version of d-i has yet had working support for 2.6 on powerpc (test candidate 1 would have done but ran into a busybox-cvs bug, so it's likely that neither TC2 nor RC1 will have either), although daily builds have had it for some time and in my experience work well. Ah, and i am seriously considering dropping support for apus from the kernels (and thus debian-installer). Amen! -- Colin Watson [EMAIL PROTECTED]
Re: [Prism54-devel] BE in stock kernel
On Wed, May 26, 2004 at 11:34:46AM -0400, Clint Adams wrote: I suggest changing the Maintainer of the kernel pseudo-package to [EMAIL PROTECTED] That's fine by me, but the file of pseudo-package maintainers is maintained by ftpmaster. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Debian kernel maintainter takeover
On Sat, May 22, 2004 at 01:22:16AM -0500, Adam Majer wrote: Nathanael Nerode wrote: Adam Majer wrote: As to the non-free binary blobs, these are to be moved to non-free. There should be an automatic 'non-free removal patches' (not part of the actual debian source). To follow the X Strike Force model (which seems to work) I suggest a 'prune-non-free' script, which should be shipped in the debian/ directory of the source package .diff for convenience. This script would convert an upstream source tree to a 'debian-clean' source tree. I don't think we can do that. The source to the package has to be free. The patches to remove non-free things and put them in non-free need to applied to the vanilla kernel to make a Debian kernel source (orig.tar.gz) and a non-free blob source. Of course. That doesn't stop you putting the scripts that remove non-free things somewhere in the Debian diff for convenience and cooperation, though. See doc-linux. -- Colin Watson [EMAIL PROTECTED]
