| Issue 1: | kona hardwires /dev/loop0 | |
| 1 person starred this issue and may be notified of changes. | Back to list |
Kona assumes /dev/loop0.
My /dev/loop0 was in use and here is what happened kona proceeded but didn't write anything to the resulting image file.
mrhankey /usr/share/kona > sudo create_yum_image -i scrub -r scrub bash vim kernel grub grubby bash -q 1G
creating /tftpboot/images/scrub.img of size 1G
Formatting '/tftpboot/images/scrub.img', fmt=raw size=1073741824
Checking that no-one is using this disk right now ...
BLKRRPART: Invalid argument
OK
Disk /dev/loop0: cannot get geometry
Disk /dev/loop0: 130 cylinders, 255 heads, 63 sectors/track
sfdisk: ERROR: sector 0 does not have an msdos signature
/dev/loop0: unrecognized partition table type
Old situation:
No partitions found
New situation:
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/loop0p1 * 0+ 129 130- 1044193+ 83 Linux
/dev/loop0p2 0 - 0 0 0 Empty
/dev/loop0p3 0 - 0 0 0 Empty
/dev/loop0p4 0 - 0 0 0 Empty
Successfully wrote the new partition table
Re-reading the partition table ...
BLKRRPART: Invalid argument
If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)
Disk /dev/loop0: cannot get geometry
Loaded plugins: auto-update-debuginfo, etckeeper, refresh-packagekit, rhnplugin
This system is not registered with RHN.
...
zlib.x86_64 0:1.2.3-27.el6
Complete!
GNU GRUB version 0.97 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename.]
grub> device (hd0) /tftpboot/images/scrub.img
grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 27 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+27 p (hd0,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
Done.
grub> quit
Usage:
losetup loop_device give info
losetup -a | --all list all used
losetup -d | --detach <loopdev> [<loopdev> ...] delete
losetup -f | --find find unused
losetup -c | --set-capacity <loopdev> resize
losetup -j | --associated <file> [-o <num>] list all associated with <file>
losetup [ options ] {-f|--find|loopdev} <file> setup
Options:
-e | --encryption <type> enable data encryption with specified <name/num>
-h | --help this help
-o | --offset <num> start at offset <num> into file
--sizelimit <num> loop limited to only <num> bytes of the file
-p | --pass-fd <num> read passphrase from file descriptor <num>
-r | --read-only setup read-only loop device
--show print device name (with -f <file>)
-v | --verbose verbose mode
qemu image is located at /tftpboot/images/scrub.img
Aug 10, 2012
#1
garlick....@gmail.com
Aug 10, 2012
Never mind, I guess I wasn't using /dev/loop0 the first try after all. Sorry - Please mark this bug invalid.
Aug 10, 2012
The last part is odd, it should look like this grub> device (hd0) /tftpboot/images/scrub.img grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 27 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+27 p (hd0,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded Done. grub> quit qemu image is located at /tftpboot/images/scrub.img Is the image any good?
Aug 10, 2012
Yes the image appears to be good.
So if I'm reading this right, the only difference is the losetup usage message?
This must be coming from the losetup -d at the end of /etc/sysconfig/kona::image_clean_Up(), maybe because ${loopy} is empty,
which means maybe the losetup -j above it fails to find an associated loop device with the image file?
Aug 10, 2012
I will read through and see if there is place that I could have unmounted it earlier, or I wonder if more then one loop device was attached to the file. I should put in a check to make sure I get the loop device when running losetup -f too. I will see if sfdisk -q will help quiet down some of the warnings when partitioning the image.
Aug 10, 2012
I'll handle this one.
Status:
Accepted
Owner: trentdho...@gmail.com
Oct 16, 2012
(No comment was entered for this change.)
Status:
Invalid
|