8 May
2016
8 May
'16
6:38 p.m.
I have a number of bootable USB sticks, all 32 bit. These work fine on
all my boxes, and work quite well with the one box that will actually
_boot_ USB3.
I would like to do a 64 bit variant of this and just tweaked an existing
system to fit onto a 16 G USB stick. This starts off booting and then
times out because it can't find the root device.
Delving around in the minimalist emergency environment shows that the
USB device is indeed not present - blkid shows all the other devices.
The normal boot uses UUID identifiers and non-EFI.
The kernel in the initramfs has all the USB drivers builtin.
Btw - is there an easy way to unpick initramfs - I found I needed to lop
off the uncompressed leading cpio to get at the gzipped cpio filesystem
that followed?
Any suggestions? Please.
9 May
9 May
1:32 p.m.
Allan Duncan via luv-main
<luv-main(a)luv.asn.au> writes:
I have a number of bootable USB sticks, all 32 bit.
These work fine
on all my boxes, and work quite well with the one box that will
actually _boot_ USB3.
I would like to do a 64 bit variant of this and just tweaked an
existing system to fit onto a 16 G USB stick. This starts off booting
and then times out because it can't find the root device.
Delving around in the minimalist emergency environment shows that the
USB device is indeed not present - blkid shows all the other devices.
The normal boot uses UUID identifiers and non-EFI.
The kernel in the initramfs has all the USB drivers builtin.
Btw - is there an easy way to unpick initramfs - I found I needed to
lop off the uncompressed leading cpio to get at the gzipped cpio
filesystem that followed?
First of all we need to know what distro this is.
Debian (initramfs-tools) & Fedora (dracut) ramdisks work very
differently. I've never seen the "lop off" part you describe on Debian.
(I negligible experience with other ramdisks.)
8:35 p.m.
On 09/05/16 13:32, Trent W. Buck via luv-main wrote:
Allan Duncan via luv-main
<luv-main(a)luv.asn.au> writes:
Fedora. The first 12K or so is a two byte file "early_cpio" ("1\n")
and a file structure "kernel/x86/microcode/AuthenticAMD.bin"
The were wrapped with the usual cpio Header and Trailer.
Immediately after the Trailer is the gzip "1f8b" magic number, and
gunzip gave a file that I could use cpio to extract a fully populated
filesystem with which to boot.
The whole point of this exercise was to confirm the USB modules were in
fact built in.
In the distant past when I pulled apart the old format initrd there was
no prolog, just straight into the gzip.
I just went off chasing something about cpio in the kernel docos and found
Documentation/x86/early-microcode.txt
which talks about the above structure in reference to initrd, so it
isn't very shiny new nor Fedora specific.
Still doesn't explain why my 32 bit sticks boot. It doesn't help that I
can't remember how I created the first of them.
I have a number of bootable USB sticks, all 32
bit. These work fine
on all my boxes, and work quite well with the one box that will
actually _boot_ USB3.
I would like to do a 64 bit variant of this and just tweaked an
existing system to fit onto a 16 G USB stick. This starts off booting
and then times out because it can't find the root device.
Delving around in the minimalist emergency environment shows that the
USB device is indeed not present - blkid shows all the other devices.
The normal boot uses UUID identifiers and non-EFI.
The kernel in the initramfs has all the USB drivers builtin.
Btw - is there an easy way to unpick initramfs - I found I needed to
lop off the uncompressed leading cpio to get at the gzipped cpio
filesystem that followed?
First of all we need to know what distro this is.
Debian (initramfs-tools) & Fedora (dracut) ramdisks work very
differently. I've never seen the "lop off" part you describe on Debian.
(I negligible experience with other ramdisks.)
2517
days inactive
2518
days old
2 comments
2 participants
participants (2)
-
Allan Duncan -
trentbuck＠gmail.com