4:24 p.m.
I'm working on a local change to the initrd used by PXE for Fedora 20.
The standard version works great for me. As an experiment, I ran these
commands.
# ls -l initrd.img
-rw-r--r--. 1 root root 34631660 Dec 12 2013 initrd.img
# mkdir newrd; cd newrd
# unxz <../initrd.img | cpio -i
# find . | cpio -o -c | xz >../initrd2.img
The resulting initrd2.img has exactly the same size as the original file
but the contents are not in the same sequence. That is, "cpio -t" on the
two files shows the same number of files but not in the same order. I've
also tried creating the new file with this command.
# unxz <../initrd.img | cpio -it | cpio -o -c | xz >../initrd2.img
This results in a new file with the contents in the same order as the
original.
But when I put initrd2.img in place of initrd.img and try to PXE boot,
the boot fails with the message, "Kernel panic - not syncing: VFS:
Unable to mount root fs on unknown-block(2,0)". There may be more
details before that message but they roll off my screen too quickly.
What am I doing wrong?
--
Dave Close
2:58 p.m.
. (dot) usually in these cases are whatever preferred named
sub-directory that you extracted it in to start with.
On Sun, Oct 12, 2014 at 2:48 PM, jd1008 <jd1008(a)gmail.com> wrote:
On 10/12/2014 01:39 PM, CLOSE Dave wrote:
>
> find . | cpio -oc | xz --check=crc32 --lzma2=dict=1MiB >../initrd2.img
So . (dot) is /boot/grub2 ??
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
2:39 p.m.
I wrote:
Eventually, I want to modify the initrd. But first I want to find a
working procedure to create the revised version. So, without changing
anything, I'm trying to recreate the initrd. If I can't get an
unmodified version to work, I probably have no hope for a modified one.
My current command sequence is,
# mkdir newrd; cd newrd
# unxz <../initrd.img | cpio -im
# unxz <../initrd.img | cpio -it | cpio -oc | xz >../initrd2.img
The result is slightly smaller than the original. lsinitrd shows both
images to have exactly the same content in the same sequence but with
different timestamps on directories and links.
Without changing the PXE instructions, either the kernel or the append
lines, I move the new file on top of the original and try to PXE boot.
That's when it fails. It does appear to find the root as several screens
worth of messages fly by. The last few I see make reference to sda and
sdb (the target has two disks). But I can't read fast enough to see the
last messages before the kernel panic (which fills the screen).
Well, I've found a procedure that can successfully create a new initrd.
It was suggested that I use the xz_wrap.sh script included with the
kernel. That script is probably used for the initramfs associated with
the real kernel but doesn't appear to be used for the PXE kernel and
initrd. Using it didn't work but did point me to the various xz options
which might be relevant. I also found some clues reviewing the output of
"xv -lvv" on the standard initrd. Here is the procedure which works.
find . | cpio -oc | xz --check=crc32 --lzma2=dict=1MiB >../initrd2.img
Probably the most critical part of that is the crc32. xz defaults to
crc64 but I'm told that the kernel doesn't include the code for that.
--
Dave Close, Thales Avionics, Irvine California USA.
cell +1 949 394 2124, dave.close(a)us.thalesgroup.com
"If a cluttered desk is a sign of a cluttered mind,
of what then is an empty desk?" --Albert Einstein
5:07 p.m.
And the machine pxeboots successfully with the original unmodified initrd?
You could get a serial crossover cable get enhanced console logging
that way, I have used serial before, just not on normal home type
machines.
You could also make only tiny modifications of the initird (ie adding
the sleeps to the linuxrc and/or init script so can see the output --
depending on which this initrd uses).
On Sat, Oct 11, 2014 at 4:48 PM, CLOSE Dave
<Dave.Close(a)us.thalesgroup.com> wrote:
Roger Heflin wrote:
> it is failing to find the root device.
>
> If the root device is initrd then that should be found, since you
> are modifing the initrd you may add a few more commands to it.
> ...
> if the root device is elsewhere it is not finding that.
Eventually, I want to modify the initrd. But first I want to find a
working procedure to create the revised version. So, without changing
anything, I'm trying to recreate the initrd. If I can't get an
unmodified version to work, I probably have no hope for a modified one.
My current command sequence is,
# mkdir newrd; cd newrd
# unxz <../initrd.img | cpio -im
# unxz <../initrd.img | cpio -it | cpio -oc | xz >../initrd2.img
The result is slightly smaller than the original. lsinitrd shows both
images to have exactly the same content in the same sequence but with
different timestamps on directories and links.
Without changing the PXE instructions, either the kernel or the append
lines, I move the new file on top of the original and try to PXE boot.
That's when it fails. It does appear to find the root as several screens
worth of messages fly by. The last few I see make reference to sda and
sdb (the target has two disks). But I can't read fast enough to see the
last messages before the kernel panic (which fills the screen).
--
Dave Close
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
4:48 p.m.
Roger Heflin wrote:
it is failing to find the root device.
If the root device is initrd then that should be found, since you
are modifing the initrd you may add a few more commands to it.
...
if the root device is elsewhere it is not finding that.
Eventually, I want to modify the initrd. But first I want to find a
working procedure to create the revised version. So, without changing
anything, I'm trying to recreate the initrd. If I can't get an
unmodified version to work, I probably have no hope for a modified one.
My current command sequence is,
# mkdir newrd; cd newrd
# unxz <../initrd.img | cpio -im
# unxz <../initrd.img | cpio -it | cpio -oc | xz >../initrd2.img
The result is slightly smaller than the original. lsinitrd shows both
images to have exactly the same content in the same sequence but with
different timestamps on directories and links.
Without changing the PXE instructions, either the kernel or the append
lines, I move the new file on top of the original and try to PXE boot.
That's when it fails. It does appear to find the root as several screens
worth of messages fly by. The last few I see make reference to sda and
sdb (the target has two disks). But I can't read fast enough to see the
last messages before the kernel panic (which fills the screen).
--
Dave Close
4:33 p.m.
it is failing to find the root device.
If the root device is initrd then that should be found, since you are
modifing the initrd you may add a few more commands to it.
sleep 10 (ash should have a sleep command) and a few more echo's so
you can confirm if the initrd is running or not.
if the root device is elsewhere it is not finding that.
On Sat, Oct 11, 2014 at 3:43 PM, CLOSE Dave
<Dave.Close(a)us.thalesgroup.com> wrote:
Roger Heflin wrote:
> note step 3.4: -H newc is important.
> find . | cpio -o -H newc | gzip > ../initrd.img
Yes, it is. But -c means exactly the same thing.
--
Dave Close, Thales Avionics, Irvine California USA.
cell +1 949 394 2124, dave.close(a)us.thalesgroup.com
"If a cluttered desk is a sign of a cluttered mind,
of what then is an empty desk?" --Albert Einstein
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
3:43 p.m.
Roger Heflin wrote:
note step 3.4: -H newc is important.
find . | cpio -o -H newc | gzip > ../initrd.img
Yes, it is. But -c means exactly the same thing.
--
Dave Close, Thales Avionics, Irvine California USA.
cell +1 949 394 2124, dave.close(a)us.thalesgroup.com
"If a cluttered desk is a sign of a cluttered mind,
of what then is an empty desk?" --Albert Einstein
3:40 p.m.
This page:
http://www.thewireframecommunity.com/node/14
note step 3.4: -H newc is important.
find . | cpio -o -H newc | gzip > ../initrd.img
On Sat, Oct 11, 2014 at 3:29 PM, CLOSE Dave
<Dave.Close(a)us.thalesgroup.com> wrote:
Heinz Diehl wrote:
> You could use dracut to recreate your initramfs?
> Works flawlessly (here as a test, with an old kernel):
While I am not familiar with dracut, I've looked at it a bit. I don't
see a way to use it to modify an existing initrd, only to create a new
one based on the running system. That's not my objective. I just want to
make a small modification to the Fedora-supplied PXE initrd. Please
recall that this initrd is not installed anywhere, nor is its associated
kernel. Both are used only by anaconda during PXE boot.
Using lsinitrd on the original initrd, which works, and on my recreated
one, which doesn't work, generates identical output except for the time
stamps on the files. Are those significant?
--
Dave Close
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
3:29 p.m.
Heinz Diehl wrote:
You could use dracut to recreate your initramfs?
Works flawlessly (here as a test, with an old kernel):
While I am not familiar with dracut, I've looked at it a bit. I don't
see a way to use it to modify an existing initrd, only to create a new
one based on the running system. That's not my objective. I just want to
make a small modification to the Fedora-supplied PXE initrd. Please
recall that this initrd is not installed anywhere, nor is its associated
kernel. Both are used only by anaconda during PXE boot.
Using lsinitrd on the original initrd, which works, and on my recreated
one, which doesn't work, generates identical output except for the time
stamps on the files. Are those significant?
--
Dave Close
2:03 a.m.
On 10.10.2014, CLOSE Dave wrote:
What am I doing wrong?
You could use dracut to recreate your initramfs?
Works flawlessly (here as a test, with an old kernel):
[root@kiera boot]# dracut -v -f initramfs-3.16.3-rc1.img
I: *** Including module: i18n ***
I: *** Including module: drm ***
I: *** Including module: plymouth ***
I: *** Including module: kernel-modules ***
I: *** Including module: resume ***
I: *** Including module: rootfs-block ***
I: *** Including module: terminfo ***
I: *** Including module: udev-rules ***
I: *** Including module: biosdevname ***
I: *** Including module: systemd ***
I: *** Including module: usrmount ***
I: *** Including module: base ***
I: *** Including module: fs-lib ***
I: *** Including module: shutdown ***
I: *** Including modules done ***
I: *** Installing kernel module dependencies and firmware ***
I: *** Installing kernel module dependencies and firmware done ***
I: *** Resolving executable dependencies ***
I: *** Resolving executable dependencies done***
I: *** Pre-linking files ***
I: *** Pre-linking files done ***
I: *** Hardlinking files ***
I: *** Hardlinking files done ***
I: *** Stripping files ***
I: *** Stripping files done ***
I: *** Creating image file ***
I: *** Creating image file done ***
I: Wrote /boot/initramfs-3.16.3-rc1.img:
I: -rw------- 1 root root 9672264 Oct 11 08:59
/boot/initramfs-3.16.3-rc1.img
3493
days inactive
3495
days old
10 comments
4 participants
participants (4)
-
CLOSE Dave -
Heinz Diehl -
JD -
Roger Heflin