Bug 983925 - fedup appends uncompressed cpio archives to compressed image
fedup appends uncompressed cpio archives to compressed image
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: fedup (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Will Woods
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-12 05:53 EDT by James Le Cuirot
Modified: 2013-07-12 18:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-12 16:02:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Le Cuirot 2013-07-12 05:53:45 EDT
I am trying to upgrade from F18 to F19 with fedup 0.7.3.4.fc18.

Many people are reporting problems when trying to use fedup with software RAID systems. Some suggested adding /etc/mdadm.conf to the image so I tried to do this myself.

I found that it is no longer compressed with gzip, but xz. However, when I tried to decompress it, it would fail at 99%. I checked the end of the image file and found two uncompressed cpio archives.

One already contained /etc/mdadm.conf. The other contained /usr/lib/dracut/hooks/pre-pivot/99-keep-initramfs.sh, as found in /etc/fedup/update.img.d. These are both appended by fedup.

I'm not an expert on initramfs but I don't think appending uncompressed archives to the end of a compressed archive is going to work. fedup certainly didn't boot up for me and I could see no sign of /etc/mdadm.conf. lsinitrd doesn't show it either.

I suppose the image needs to be downloaded, decompressed, appended to, and then recompressed. It is easy to see the uncompressed files at the end, just view /boot/initramfs-fedup.img with less and hit the end key.
Comment 1 Will Woods 2013-07-12 16:02:27 EDT
No, it works fine. The kernel initramfs code specifically allows for concatenated images. 

Try it and see. Boot with 'rd.break'; you'll see that the appended files are present in the initramfs.
Comment 2 James Le Cuirot 2013-07-12 18:03:53 EDT
Turns out I was hitting bug #970580. Sorry for the noise and thanks for the info.

Note You need to log in before you can comment on or make changes to this bug.