Your message dated Thu, 15 Dec 2016 23:13:03 +0000 with message-id <1481843583.2651.4.camel@decadent.org.uk> and subject line Re: initramfs-tools: Add command to unpack initramfs has caused the Debian Bug report #807457, regarding please give a tool (or document how to) unpacking an initramfs with microcode prepended to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 807457: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807457 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: please give a tool (or document how to) unpacking an initramfs with microcode prepended
- From: Marc Haber <mh+debian-packages@zugschlus.de>
- Date: Thu, 06 Oct 2016 08:48:01 +0200
- Message-id: <147573648110.32395.10508358340103605577.reportbug@fan.zugschlus.de>
Package: initramfs-tools Version: 0.125 Severity: wishlist Hi, the new method of prepending a CPU microcode fix to the initramfs is a nuisance when debugging an initramfs. Having to peddle with dd and guessing (?) the correct offset in a situation where only a tiny part of the system might be available or one is working from a rescue system is not nice. Please consider providing a tool which can unpack an initrmamfs with a single call of the tool even if CPU microcode is prepended. Thanks! Greetings Marc
--- End Message ---
--- Begin Message ---
- To: 807457-done@bugs.debian.org
- Subject: Re: initramfs-tools: Add command to unpack initramfs
- From: Ben Hutchings <ben@decadent.org.uk>
- Date: Thu, 15 Dec 2016 23:13:03 +0000
- Message-id: <1481843583.2651.4.camel@decadent.org.uk>
- In-reply-to: <20160210041816.GA18527@kevinolos>
- References: <20150626235359.GA7601@goofy.local> <1449631391.2824.128.camel@decadent.org.uk> <20160210041816.GA18527@kevinolos>
Version: 0.126 On Tue, 9 Feb 2016 20:18:16 -0800 Kevin Locke <kevin@kevinlocke.name> wrote: > On Wed, 2015-12-09 at 03:23 +0000, Ben Hutchings wrote: > > Rather than duplicating code, please combine this with lsinitramfs > > (checking $0 to determine which command was invoked) or move the common > > code into a shell library. > > I've taken a slightly different tact and implemented uninitramfs as a > thin wrapper for cpio. It is designed as a drop-in replacement for > cpio wherever an initramfs may be present, and passes through all > options unmodified. With this, I changed lsinitramfs to call > uninitramfs instead of cpio. > > See what you think. I didn't like the way it passed all options through to cpio: - It's inconsistent with the other commands - It makes it difficult to implement any additional options - cpio's default of unpacking into the current directory is dangerous So I made the initramfs file and output directory arguments, and added sensible options to cpio. The --verbose option can be passed through, and if there are other important ones we can add those later. > P.S. I named it "uninitramfs" instead of "unmkinitramfs" since it > does not depend on mkinitramfs specifically, and it seemed to fit with > "lsinitramfs" and the "initramfs" format. But if you would prefer > "unmkinitramfs", I can change it. But it is meant to work with the initramfs images that mkinitramfs creates and doesn't support arbitrary concatenations of maybe- compressed cpio archives. So, unmkinitramfs it is. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa.Attachment: signature.asc
Description: This is a digitally signed message part
--- End Message ---