I have been using a some proven steps to create my own Oracle Linux 6uX ISO images with a custom kickstart script for a long time. What i basically do is mount the iso-image using hdiutil, copy the contents to a working folder, make the modifications and create an iso using makeiso (cdrutils).
Details have been described here; http://www.reddipped.com/2015/12/virtualbox-soa-bpm-osb-bam-33-minutes/
I just made my first attempts to create a custom Oracle Linux 7u2 ISO images, but miserably failed till now.
First opening the image using hdiutil gives and 'hdiutil: attach failed - no mountable file systems'. Instead i used Keka to extract the contents of the iso.
Modified the contents of the extracted iso-image;
Removing /isolinux/boot.cat,
Adding a new ks-bd.ks
Adding a menu item to the isolinux.cfg to be able to start installation using the kickstart file
label linux_basicserver_silent\
menu label ^Install basic server silent\
menu default\
kernel vmlinuz\
append initrd=initrd.img ks=cdrom:\/ks-bd.ks\
Then created an iso again;
## Make isolinux.bin writable
chmod u+w V100082-01U/isolinux/isolinux.bin
# Build the V100082-01Uiso
cdrtools/cdrtools-*/mkisofs/OBJ/i386-darwin-clang/mkisofs -r -J -T -o V100082-01U.iso -b isolinux/isolinux.bin \
-c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -R \
-m TRANS.TBL -v -V Oracle\ Linux\ 7.2 ./V100082-01U
After mounting the iso image and selecting the 'linux_basicserver_silent' installation option the installation seems to stall on the message 'Starting automated install'
When selecting a standard interactive installation in the installation menu the installation also freezes with the latest step 'Reached target Basic System'
After some minutes the same error 'dracut-initqueue timeout' is repeatedly shown .
Any hints how to fix this?
-- Update 10/27/2016 --
When comparing the orignal iso with the created iso using mkisofs there are no substantial differences, i think..
Original
./isoinfo -d -i V100082-01.iso
CD-ROM is in ISO 9660 format
System id: LINUX
Volume id: OL-7.2 Server.x86_64
Volume set id:
Publisher id:
Data preparer id:
Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 2178717
El Torito VD version 1 found, boot catalog is in sector 701
Joliet with UCS level 3 found.
SUSP signatures version 1 found
Rock Ridge signatures version 1 found
Rock Ridge id 'RRIP_1991A'
Eltorito validation header:
Hid 1
Arch 0 (x86)
ID ''
Cksum AA 55 OK
Key 55 AA
Eltorito defaultboot header:
Bootid 88 (bootable)
Boot media 0 (No Emulation Boot)
Load segment 0
Sys type 0
Nsect 4
Bootoff EFE 3838
Rebuild
./isoinfo -d -i V100082-01U.iso
CD-ROM is in ISO 9660 format
System id: Mac OS X
Volume id: Oracle Linux 7.2
Volume set id:
Publisher id:
Data preparer id:
Application id: MKISOFS ISO9660/HFS/UDF FILESYSTEM BUILDER & CDRECORD CD/DVD/BluRay CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 2251903
El Torito VD version 1 found, boot catalog is in sector 718
Joliet with UCS level 3 found.
SUSP signatures version 1 found
Rock Ridge signatures version 1 found
Rock Ridge id 'RRIP_1991A'
Eltorito validation header:
Hid 1
Arch 0 (x86)
ID ''
Cksum AA 55 OK
Key 55 AA
Eltorito defaultboot header:
Bootid 88 (bootable)
Boot media 0 (No Emulation Boot)
Load segment 0
Sys type 0
Nsect 4
Bootoff 2CF 719
Instead of using 7zip, use the cdrtool utility isoinfo to extract the original iso image.
mkdir V100082-01U
cd V100082-01U
isoinfo -R -X -i ../V100082-01.iso
Then modify the image and rebuild using mkisofs
## Make isolinux.bin writable
chmod u+w work/isolinux/isolinux.bin
# Build the V100082-01Uiso
cdrtools/cdrtools-*/mkisofs/OBJ/i386-darwin-clang/mkisofs -r -J -T -o V100082-01U2.iso -b isolinux/isolinux.bin \
-c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -R -sysid LINUX \
-m TRANS.TBL -v -V OL-7.2\ Server.x86_64 ./work
Related
Using Python 3.9.2 on Linux I try to find major and minor device numbers of a block device, e.g. /dev/sda.
For result checking I first note the expected result using shell utils:
$ ls -ltr /dev/sda
brw-rw---- 1 root disk 8, 0 Mar 15 13:34 /dev/sda
major-----^ ^----minor
$ stat -c%t:%T /dev/sda
8:0
But then in python3:
python3 -c "import os ; print( os.major(os.stat('/dev/sda').st_dev) )"
0
python3 -c "import os ; print( os.minor(os.stat('/dev/sda').st_dev) )"
5
Major is 0 and minor is 5 according to python...?
The subject of many (if not all) questions similar to mine, is getting the major/minor numbers for some directory that resides on e.g. /dev/sda2. That somehow does get me the expected results:
python3 -c "import os ; print( os.major(os.stat('/etc').st_dev) )"
8
Can't find my mistake. How can I get, using python, the major and minor numbers of a block device file like /dev/sda?
You want os.stat("/dev/sda").st_rdev.
I'm quite new to embedded systems and I'm playing around with ARM on qemu. So I've run into problem booting linux kernel image from an emulated SD on versatile express with cpu cortex-a9.
I prepared everything in the following order: first, I've built the kernel with vexpress_defconfig using appropriate ARM toolchain. Then I've built u-boot with vexpress_ca9x4_defconfig. Everything went just fine. The linux kernel source I took is at version 4.13 (latest stable from git). U-boot version is 2017.09-00100. Then I prepared an SD image:
dd if=/dev/zero of=sd.img bs=4096 count=4096
mkfs.vfat sd.img
mount sd.img /mnt/tmp -o loop,rw
cp kernel/arch/arm/boot/zImage /mnt/tmp
umount /mnt/tmp
Next I try to run qemu as follows:
qemu-system-arm -machine vexpress-a9 -cpu cortex-a9 -m 128M -dtb kernel/arch/arm/boot/dts/vexpress-v2p-ca9.dtb -kernel uboot/u-boot -sd sd.img -nographic
U-boot loads successfully and gives me command prompt. And SD is really there and attached:
=> mmcinfo
Device: MMC
Manufacturer ID: aa
OEM: 5859
Name: QEMU!
Tran Speed: 25000000
Rd Block Len: 512
SD version 1.0
High Capacity: No
Capacity: 16 MiB
Bus Width: 1-bit
Erase Group Size: 512 Bytes
I attempt to load compressed image from SD into memory and boot it:
fatload mmc 0:0 0x4000000 zImage
and everything looks ok
=> fatload mmc 0:0 0x4000000 zImage
reading zImage
3378968 bytes read in 1004 ms (3.2 MiB/s)
but then I want to boot the kernel and get an error:
=> bootz 0x4000000
Bad Linux ARM zImage magic!
I also tried U-boot images, crafted with u-boot's mkimage, like in this example:
uboot/tools/mkimage -A arm -C none -O linux -T kernel -d kernel/arch/arm/boot/Image -a 0x00010000 -e 0x00010000 uImage
also trying out -C gzip on zImage and different load/entry addresses, to no avail. The images were copied to sd.img. When I fatload the image and check it with iminfo, whichever options I try, I constantly get error:
=> iminfo 0x4000000
## Checking Image at 04000000 ...
Unknown image format!
I'm totally confused and this problem drives me nuts, while information on this subject in Internet is rather scarce. Please, hint me what I'm doing wrong and redirect into right direction.
qemu in use is QEMU emulator version 2.9.0.
I've scoured the presentations and documentation for verified u-boot and have several questions. I'll try to walk any users through where I am as I suspect I am not the only one who is having some slight difficulty understanding the process for verified u-boot.
I have a compiled zImage that has a working external DTB for use without verification. It boots and works (let's call this normal-board.dts)
Secondly, I have u-boot compiled with the following config entries:
CONFIG_ARM=y
CONFIG_ARCH_AT91=y
CONFIG_TARGET_AT91SAM9260EK=y
CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9G20,SYS_USE_DATAFLASH_CS1"
CONFIG_SYS_PROMPT="#> "
# CONFIG_CMD_BDI is not set
CONFIG_CMD_IMI=y
# CONFIG_CMD_IMLS is not set
# CONFIG_CMD_LOADS is not set
# CONFIG_CMD_FPGA is not set
# CONFIG_CMD_SOURCE is not set
CONFIG_CMD_SETEXPR=y
CONFIG_DEFAULT_DEVICE_TREE="myboard"
CONFIG_CMD_MMC=y
CONFIG_CMD_FAT=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_RSA=y
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_OF_CONTROL=y
My board has a partition scheme similar to:
... boot strap, uboot and env
0xD00084000 (zImage)
0xD0020AA00 (normal-board.dtb)
The rootfs is on NAND (external to this chip)
The device can be booted in a standard configuration using a command such as:
cp.b 0xD0084000 0x22000000 0x186A00;cp.b 0xD020AA00 0x28000000 0x61A8;bootm 0x22000000 - 0x28000000
At this point, I've recompiled u-boot, but the nomenclature is a bit confusing as there are several elements.
FIT Control DTS (I assume that this is one used by u-boot and needs to be in its own partition)
FIT DTB (the same DTB more or less as the non-FIT one (normal-board.dtb), but with FIT magic somewhere in it)
FIT kernel image (I assume that some magic gets added to the zImage here too?)
Having seen that there is a uboot control FIT FDT, will this need its own partition? and will the FIT DTB be the same as the working kernel DTB (just flash this instead of the non-FIT one)???
Next, given this script I started hashing out from various documentation and slides, we can see that u-boot.{dts,dtb} is the control FDT, and the ITS file is the one with the fit (I assume that its the same as normal-board.dts, BUT has a FIT node added).
Eg. u-boot.dts
/dts-v1/;
/ {
model = "Keys";
compatible = "myboard";
signature {
dev_key {
required = "conf";
algo = "sha1,rsa2048";
key-name-hint = "dev_key";
};
};
};
Now the example DTS for myboard WITH THE FIT section:
/dts-v1/;
/ {
description = "Linux kernel2";
#address-cells = <1>;
images {
kernel#1 {
description = "Linux kernel";
data = /incbin/("../linux/arch/arm/boot/zImage");
arch = "arm";
os = "linux";
type = "kernel_noload";
compression = "none";
load = <0x80080000>;
entry = <0x80080000>;
kernel-version = <1>;
hash#1 {
algo = "sha1";
};
};
};
configurations {
default = "conf#1";
conf#1 {
description = "Boot Linux kernel";
kernel = "kernel#1";
signature#1 {
algo = "sha1, rsa2048 ";
key-name-hint = "dev_key";
sign-images = "kernel";
};
};
};
};
However, what the heck is fitImage (see below script - this is from the examples)? is it zImage? I couldn't find any documentation describing its first mention - what it is where it comes from etc... or is it an output generated by the reference from within the ITS for an incbin?
#!/bin/bash
key_dir=/tmp/keys
key_name=dev_key
FIT_IMG="fitImage"
rm -rf ${key_dir}
mkdir ${key_dir}
MKIMG="/home/dev/lede/staging_dir/host/bin/mkimage"
DTC="/usr/bin/dtc"
#Generate a private signing key (RSA2048):
openssl genrsa -F4 -out \
"${key_dir}"/"${key_name}".key 2048
# Generate a public key:
openssl req -batch -new -x509 \
-key "${key_dir}"/"${key_name}".key \
-out "${key_dir}"/"${key_name}".crt
# Control FDT (u-boot.dts) - hits uboot to have keys etc...
CTRL_FDT="u-boot.dts"
# FIT image ITS - describes the node
FIT_ITS="fit-image.its"
#Assemble control FDT for U-Boot with space for public key:
$DTC -p 0x1000 $CTRL_FDT -O dtb -o u-boot.dtb
# Generate fitImage with space for signature:
$MKIMG -D "-I dts -O dtb -p 2000" \
-f f$FIT_ITS $FIT_IMG
# Sign fitImage and add public key into u-boot.dtb:
$MKIMG -D "-I dts -O dtb -p 2000" -F \
-k "${key dir}" -K u-boot.dtb -r $FIT_IMG
# Signing subsequent fitImage:
$MKIMG -D "-I dts -O dtb -p 2000" \
-k "${key dir}" -f $FIT_ITS -r $FIT_IMG
Iminfo gets me this far:
#> iminfo
## Checking Image at 20000000 ...
FIT image found
FIT description: Configuration to load a Basic Kernel
Image 0 (linux_kernel#1)
Description: Linux zImage
Type: Kernel Image
Compression: uncompressed
Data Start: 0x200000dc
Data Size: 1465544 Bytes = 1.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x20000000
Entry Point: 0x20008000
Hash node: 'hash#1'
Hash algo: sha256
Hash value: bf1d62a9ac777310746c443f2500cf197967f1e7c9cb56ff5c33206670e12d8f
Hash len: 32
Image 1 (fdt#1)
Description: FDT blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x20165ea4
Data Size: 21681 Bytes = 21.2 KiB
Architecture: ARM
Hash node: 'hash#1'
Hash algo: sha256
Hash value: c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
Hash len: 32
Default Configuration: 'config#1'
Configuration 0 (config#1)
Description: Plain Linux
Kernel: linux_kernel#1
FDT: fdt#1
## Checking hash(es) for FIT Image at 20000000 ...
Hash(es) for Image 0 (linux_kernel#1): sha256+
Hash(es) for Image 1 (fdt#1): sha256+
The zImage is prepared (and this is likely the wrong way)
mkimage -A arm -O linux -C none -T kernel -a 0x22000000 -e 0x22008000 -n linux-4.4.36 \
-d $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage-nDTB
Even along the lines of the following (I seem to get this, what do I do for addresses - is the reallocation part of the issue? such as the fdt_high variables?)
#> bootm 0x23000000
## Current stack ends at 0x23f119b8 * kernel: cmdline image address = 0x23000000
## Loading kernel from FIT Image at 23000000 ...
No configuration specified, trying default...
Found default configuration: 'config#1'
Using 'config#1' configuration
Trying 'linux_kernel#1' kernel subimage
Description: Linux zImage
Type: Kernel Image
Compression: uncompressed
Data Start: 0x230000dc
Data Size: 1465544 Bytes = 1.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x23000000
Entry Point: 0x23000000
Hash node: 'hash#1'
Hash algo: sha256
Hash value: bb397db1ec90ec8526c6d215c9ded2a1357a258c2145f97fda9898e810e847d7
Hash len: 32
Verifying Hash Integrity ... sha256+ OK
kernel data at 0x230000dc, len = 0x00165cc8 (1465544)
* ramdisk: using config 'config#1' from image at 0x23000000
* ramdisk: no 'ramdisk' in config
* fdt: using config 'config#1' from image at 0x23000000
## Checking for 'FDT'/'FDT Image' at 23000000
## Loading fdt from FIT Image at 23000000 ...
Using 'config#1' configuration
Trying 'fdt#1' fdt subimage
Description: FDT blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x23165ea4
Data Size: 21681 Bytes = 21.2 KiB
Architecture: ARM
Hash node: 'hash#1'
Hash algo: sha256
Hash value: c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
Hash len: 32
Verifying Hash Integrity ... sha256+ OK
Can't get 'load' property from FIT 0x23000000, node: offset 1465916, name fdt#1 (FDT_ERR_NOTFOUND)
Booting using the fdt blob at 0x23165ea4
of_flat_tree at 0x23165ea4 size 0x000054b1
Initial value for argc=3
Final value for argc=3
Loading Kernel Image ... OK
CACHE: Misaligned operation at range [23000000, 23165cc8]
kernel loaded at 0x23000000, end = 0x23165cc8
images.os.start = 0x23000000, images.os.end = 0x2316c911
images.os.load = 0x23000000, load_end = 0x23165cc8
ERROR: new format image overwritten - must RESET the board to recover
So, there's a lot in the above question, and I'll try and answer a few things which should help clear things up:
The U-Boot binary needs to contain the pubkey. So in this case, the "myboard" device tree you've listed is where that needs to end up. It is within the binary and not a separate partition in flash.
The next thing is that the FIT image is a container with lets say different ways to open it. The fitImage contains zImage and normal-board.dtb and logic so that you can say that each of these pieces needs to be signed by a particular public key. So in this case, instead of a flash partition for the zImage and another for normal-board.dtb you have a single partition for fitImage to reside in. It is the output from providing the "its" file to mkimage. This is similar to how "uImage" is the output from providing "zImage" to mkimage.
After alot of man-hours studying, reading, and trying - I created a full blog article about how verified uboot works, and how DTBs (both forms) come together when building the final images.
This article can be found here
However, the key things to note are indeed what Tom said and here are a few more (after quoting my article):
There are two kinds of DTBs (the kernel & uboot DTBS)
There is a file called an ITS - this describes the FIT image to be built
You will need an asynchronous key pair
You will need a version of mkimage that supports verified uboot/DTBs
Your bootloader will need support Verified uboot enabled
Uboot and the Linux kernel need to know about DTBs
Even though you sign your images, a copy of the public key and other cryptographic info will be needed in the final bootloader
It was a fun process :)
I have virtual image of a FreeBSD system and when I mount it I don't see the /etc/ directory and other files, instead is a big loader.gz on the filesystem, that I believe that is extracted during the boot process. I decompressed the loader.gz with gzip and I got it:
$ file loader
loader: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped
Using grep I'm able to confirm that the files that I need to edit are inside, however I don't know how to edit it. I tried to mount it without success. How can I modify the contents of loader.gz and use it again?
Can you please give me an example?
I have a Linux system and a Mac to install tools and this FreeBSD image.
Please, help me.
The loader program is generally the last stage of the kernel bootstrapping process.
A recent image should have another signature. e.g. for a memory stick image;
> file tmp/FreeBSD-10.0-RELEASE-amd64-memstick.img
tmp/FreeBSD-10.0-RELEASE-amd64-memstick.img: Unix Fast File system
[v1] (little-endian), last mounted on ,
last written at Fri Jan 17 00:24:02 2014,
clean flag 1, number of blocks 681040, number of data blocks 679047,
number of cylinder groups 13, block size 8192, fragment size 1024,
minimum percentage of free blocks 8, rotational delay 0ms,
disk rotational speed 60rps, TIME optimization
Mounting an image on FreeBSD:
# mdconfig -a -t vnode -f tmp/FreeBSD-10.0-RELEASE-amd64-memstick.img -u 1
# mount /dev/md1a /mnt/root/
(Linux has the same capability, I just don't remember what its called.)
This image contains loader in the boot/ directory:
# ls /mnt/root/
.cshrc ERRATA.TXT README.TXT boot/ lib/ proc/ sys#
.profile HARDWARE.HTM RELNOTES.HTM dev/ libexec/ rescue/ tmp/
COPYRIGHT HARDWARE.TXT RELNOTES.TXT docbook.css media/ root/ usr/
ERRATA.HTM README.HTM bin/ etc/ mnt/ sbin/ var/
# ls /mnt/root/boot/
beastie.4th check-password.4th gptzfsboot menu.4th support.4th
boot color.4th kernel/ menu.rc userboot.so
boot0 defaults/ loader* menusets.4th version.4th
boot0sio delay.4th loader.4th modules/ zfs/
boot1 device.hints loader.help pmbr zfsboot
boot2 firmware/ loader.rc pxeboot zfsloader*
brand.4th frames.4th mbr screen.4th
cdboot gptboot menu-commands.4th shortcuts.4th
On my FreeBSD 10 system, loader has another signature;
/boot/loader: FreeBSD/i386 demand paged executable
I need a shell command that would return an sg device size for me.
I am searching for it over the Internet for almost two hours without any success.
I can do it by writing a program but there has to be a way to get it through a command! I simply cannot find it!
Unfortunatelly, on the dell server I work, sg_inq, and sginfo return Dell's PERC information, and not the device I try to get the information of.
I tried to use the smartctl but it returns a static (and not true) infomation about the device (SSD,) for the number of bytes it returns divided by 512 shows bigger number of sectors that I can access (sic!)
Any [shell command] hint would be greatly appreciated!
I am putting an answer here for anyone looking for it.
The ultimate way to either write own program or use smartctl (http://sourceforge.net/projects/smartmontools/files/smartmontools/6.0/) and call the following command:
#>./smartctl -a /dev/sdc
smartctl 6.0 2012-10-10 r3643 [x86_64-linux-2.6.18-274.18.1.el5] (local build)
Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org
Vendor: DELL
Product: PERC H710P
Revision: 3.13
User Capacity: 179,443,728,384 bytes [179 GB]
Logical block size: 512 bytes
Logical Unit id: --------------------------------
Serial number: --------------------------------
Device type: disk
Local Time is: Tue Sep 24 17:54:13 2013 EDT
Device does not support SMART
Error Counter logging not supported
Device does not support Self Test logging
use #fdisk -l /dev/sg2
or # parted -l /dev/sg2