Running livecd-creator (latest git version) having all repo lines in ks
without mirrorlist gives me this error:
Traceback (most recent call last):
File "/usr/bin/livecd-creator", line 1120, in <module>
File "/usr/bin/livecd-creator", line 1097, in main
File "/usr/bin/livecd-creator", line 319, in parse
for cmd_name, cmd_url in self.repos:
ValueError: too many values to unpack
The repo lines in ks are:
repo --name=livna --baseurl=http://rpm.livna.org/fedora/7/i386/
repo --name=local --baseurl=file:///var/www/html
The attached patch solves the problem.
I am aware of the replacement directory; however, when plugging a different
baseurl into the repo line of the kickstart, I have not figured out how to
determine the correct name of the repo.
I am unable to use revisor because I wish to install a package that does not
have a RPM. To do so, I must use the --shell flag with the livecd-creator
command so that I can have the chrooted environment in which to do this.
The version of Revisor of I have does not have this feature.
Can you or anyone else provide me with a sample copy of either your
kickstart file for livecd-creator OR what you are putting in the repo line
OR what you are entering on the command line (in case you are specifying
your repos that way)?
Dale, this isn't exactly an answer, but a tool to deal with part of
what you're running into.
You can pop those paths into a browser to check them and (often)
figure out what's wrong. For instance:
I copied the part through 'fedora' into my browser and started
clicking down. It turns out 'development' is empty _but_ there's a
development directory several levels up that (if memory serves) has
In something slightly closer to an answer, Revisor works quite nicely
with everything I've thrown at it kickstart-wise (well... except that
I can't use the -package syntax to delete an optional package from a
group **grumble**). Several of the defaults work quite well.
regards, Tim Wood
On the Fedora LiveCD wiki's wishlist, is 'persistance' -
* Persistence; e.g. the ability to save livecd changes (e.g. installed
software) to a USB stick instead of tmpfs
* LiveCD content + persistence all on a 1GB USB stick image
While I have plenty of ideas for this, and have vague memories of seeing other
distributions do it, I'd like to get a feel for what the fedora community
actually wants. I.e. lets design this feature. How should it work from the end
Also, there are a bazillion distros and livecds out there, if you happen to know
of any that do this in a way that you like, please mention them.
After executing the command u suggested here is the result.
[root@localhost Desktop]# yum localinstall gcc-3.2-1.i386.rpm
Loading "installonlyn" plugin
Setting up Local Package Process
Examining gcc-3.2-1.i386.rpm: gcc - 2:3.2-1.i386
Marking gcc-3.2-1.i386.rpm to be installed
Could not retrieve mirrorlist http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f7&arch... error was
[Errno 4] IOError: <urlopen error (-3, 'Temporary failure in name resolution')>
Error: Cannot open/read repomd.xml file for repository: updates
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
i have install fedora 7live cd on my hard drive.However i am tring to
install gcc 3.2 rpm file
i used tihs commnad
yum install *****.rpm
However i get an error during install that yum can access a sayin that i need to acess a url ( fedora.mirror... the url was somthin glike that)to update..and i did not set up any network options
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
I have used the livecd to install fedora on a HP DL360
dual 800Mhz processor raid enabled 1U rack mount
server with 768M RAM. I have tried this 3 times, the
last choosing all defaults for disk partitioning, and
I get the same result each time. It seems to be
complaining about 'Volume group "VolGroup00" not
found', then it goes into kernel panic. The installer
is very pretty, but there is little I can go on to
diagnose this problem. This is an install directly to
the hardware - no Xen, no vmware etc. Any help would
Here is standard error from running liveinst:
[fedora@localhost ~]$ liveinst &
[fedora@localhost ~]$ FATAL: Module md not found.
[fedora@localhost ~]$ Probing for video card: ATI
Technologies Inc 3D Rage IIC 215IIC [Mach64 GT IIC]
Starting graphical installation...
Couldn't find rules file (xfree86)
Here is output from the console at boot time
Booting 'Fedora (2.6.21-1.3194.fc7)'
Filesystem type is ext2fs, partition type 0x83
kernel /vmlinux-2.6.21-1.3194.fc7 no root=LABEL=/ rhgb
[Linux-bzImage, setup=0x1e00, size=0x1c9dd4]
[Linux-initrd @ 0x2fca8000, 0x343303 bytes ]
Uncompressing Linux. . . Ok, booting the kernel.
ACPI: Resource is not an IRQ entry
agpgart: unable to determine aperture size.
agpgart: unable to determine aperture size.
Red Hat nash version 6.0.9 starting
Reading all physical volumes. This may take a
No volume groups found
Volume group "VolGroup00" not found
Unable to access resume device
mount: could not find filesystem '/dev/root'
setuproot: moving /dev failed: No such file or
setuproot: error mounting /proc: No such file or
setuproot: error mounting /sys: No such file or
switchroot: mount failed: No such file or directory
Kernel panic - not syncing: Attempted to kill init!
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
In the name of release-early-release-often, here is an untested patch to
livecd-tools mayflower script, which I believe adds support for rebootless
A proof of concept rebootless installer should hopefully be forthcoming in a day
or so, and an anaconda based one in a week or so.
Note, that the prior patch I had, was actually missing a --force flag on the
mdadm build command. But don't worry, mdadm is out of the picture since it's
--grow feature wouldn't work for me. This patch is far superior, and is a
successful implementation of the theoretical workaround #4.
I leave it as an excercise for the reader how to perform a rebootless
installation manually ;)
At the bottom of this lengthy RFC is a patch to livecd-tools mayflower
script which adds the interesting ability to install the livecd system to
hard disk, in a way that doesn't require a reboot after installation.
Given the proof-of-concept nature of this small patch/hack, I just want to
get some feedback from the community before really going all out, and
adding support to anaconda to be the installation front-end. For now, you
would have to perform the installation steps (outlined below) manually.
Concept: Rebootless Installer via LiveCD(/DVD/USB/PXE/...)
The basic 'trick' is to use raid1 style mechanisms to live-migrate the
root filesystem from the install media, to the desitination drive.
Note, that I'm not looking for a debate as to whether or not this would
be a useful default installer for fedora. Rather I think that it would
*definitely* be a nice checkbox option for people to add to their own
customized fedora-derived spins.
In 2001 I created an unpublished livecd spin tool for Mandrake. The
resulting images (optionally) possessed the interesting feature that
during the initrd boot sequence, all hard drives would be scanned for
mountable partitions. If a partition was found with suitable free space
(e.g. windows C drive(vfat)), the initrd would copy the livecd to an
image file there, and use it instead of the cd drive. (and optionally
setting up loadlin/lilo for future usage sans livecd). But this wasn't
as useful as what I'm currently talking about, because the installed
system would still be a mix of read-only and tmpfs filesystems, and you
would have to wait for the cd to copy before seeing anything. (of
course I did have X+mozilla+xmms in 135MB...)
Then, as I discovered a couple days ago, in 2003, Goswin Brederlow more or
less outlined the attached method.
I haven't yet pinged him, so I don't know if debix is the 'modern' version
of the proof of concept iso he referred to there.
http://debix.alioth.debian.org/ (stale since 2004?)
Then, when I first started getting involved with fedora-livecd-list,
someone, I think a redhat employee, mentioned that I might be able to
do that iso-caching-to-disk thing mentioned above using raid1 mirror tricks.
I.e. in initrd, set up the image from iso as a 1-disk raid1 array, and use
it as the root fs. Then after boot, use space on hard disk as a hot-added
2nd disk for the array, and after the raid sync finishes, hot-remove the
cdrom based device, so that the cd can be ejected.
It wasn't long after this that I managed to re-outline what Goswin had
outlined years earlier
The mechanism I've implemented in the attached patch is really dirt simple.
- mdadm is added to the initramfs
- after normal creation of the device mapper root filesystem, /dev/md7 is
created as a raid1 with a single device- the normal /dev/mapper/live-rw
root device. Note, I opted with a metadataless device, so that
on subsequent boots there is no raid1 involved (? I may have an incomplete
understanding of my options that led to this choice ?)
- the root filesystem (sysroot) is then mounted from /dev/md7 instead of
Current Rebootless Installation Procedure
- once booted into the live environment, choose your destination device.
(for this exampe, I'll assume /dev/sda1)
- add the device to the raid.
mdadm /dev/md7 --add /dev/sda1
mdadm /dev/md7 --grow --raid-disks=2
- wait for the resync to finish (watch /proc/mdstat)
- remove the original devices from the raid
mdadm /dev/md7 --fail /dev/mapper/live-rw
mdadm /dev/md7 --remove /dev/mapper/live-rw
mdadm /dev/md7 --grow --raid-disks=1 // (perhaps redundant)
dmsetup remove live-rw
losetup -d /dev/loop121
losetup -d /dev/loop120
losetup -d /dev/loop119
- now you should be able to eject the livecd
- install and configure grub in the usual way, with the assumption that
the root device on subsquent boots will be /dev/sda1 as normal, and not
the current /dev/md7.
- now grow the filesystem - CRASH/BURN/DIE... segway to...
Current Problem With Less Than Fully Satisfying Workaround
The current problem with the attached patch is that it is not possible
to resize the small livecd ext3 filesystem to the maximum size of the
destination partition _before_ rebooting. (after reboot, no sweat, as
the raid1 layer is gone)
Specifically, when I tried
mdadm /dev/md7 --grow --size=max
/proc/mdstat showed the number of blocks go from 3.5G to 0, though
strangely the system did not fall over dead.
And when I tried
mdadm /dev/md7 --grow --size=[ just a bit bigger than mdstat reports ]
mdadm: Cannot set device size for /dev/md7: No space left on device
Now, googling yielded someone with a similar message for raid5 which
turned out to be a legitimate bug. My next step will be to post to the
linux-raid mailinglist and see what they say. From my perusing of the
userspace and kernel code, I have a hunch that I may just be trying for a
feature that hasn't been implemented, and hasn't been adequetly documented
as such. Perhaps my choice of raid1 options is at issue. But, there are
of course many different ways to try and accomplish the same thing, so...
Create the original livecd ext3 fsimage on a huge (say 777G) sparse file,
but only make the filesytem size be the normal container size (~3G).
(or alternately, in initramfs, create a device mapper device that is a
linear addition of the original fsimage, and a huge device mapper zero
Then, instead of setting /dev/sda1 as the other half of the mirror, create
another devicemapper device which is the linear addition of it and a huge
device mapper zero device.
Because there is now no need to grow the raid1, you are golden, and can
resize the ext3 fs to the max size of sda1.
CONS: The main con here is that the installation process will require the
zero-ing out of all the unused parts of sda1, AND a whole lot of null work
as the raid syncs the tailing imaginary parts of the devices. Admittedly
the latter is pretty fast, though if you want to support installing to a
750G disk, you'll need to make the containers 777G and suffer quite a bit
of time waiting for the md driver to finish doing a whole lot of nothing.
Theoritical Workaround #2
Like WA#1, but instead of the other half of the raid1 being a linear
addition of the _entire_ destination device and a big zero device, make
it a linear addition of the _beggining_(size of livecd fsimage) of the
destination device, and a big zero device.
But, to make it work, make that be a multipath md device. Then after
the faster raid1 sync finishes, create a new fake device that includes
all of the destination device, and add it to the multipath, take out
the other, and bingo. I haven't tried this yet to see if it will work.
Theoretical Workaround #3
Hack the md raid1 driver so that you can force the sync to believe it is
done after reaching a certain point. Together with WA#1, this would
achieve relatively best-case overall performance. I've looked into the
md sysfs interface, and there doesn't yet appear to be a way to accomplish
Theoretical Workaround #4
Understand the device mapper mirror target, which lacks
http://web.glandium.org/blog/?p=141 is the best documentation I've found
so far. Though I did run accross a Goswin post somewhere where he claimed
that it was really simple (cough cough).
Or perhaps redo everything with pvmove (which I haven't researched much),
and/or logical volumes as requirements.
Or perhaps this request for comments will yield some other sort of answer.
Note, this is against mayflower from livecd-tools-009-1.fc7, and you will
also need to add raid1 to the MODULES list in livecd-creator where it
generates mayflower.conf on the fly.
> # dmc/jdog-ri-poch
> cp /sbin/mdadm sbin
< ln -s /dev/mapper/live-rw /dev/root
> ## dmc/jdog-ri-poch
> #ln -s /dev/mapper/live-rw /dev/root
> # create broken mirror
> # and hope it doesn't cause another 7 years of bush in the whitehouse :(
> modprobe raid1
> mdadm --build /dev/md7 --level=1 --raid-devices=1 /dev/mapper/live-rw
> ln -s /dev/md7 /dev/root
> ## dmc/jdog-ri-poch
> # mount the broken mirror instead of the live-rw
> #mount -n -t ext3 /dev/mapper/live-rw /sysroot
> mount -n -t ext3 /dev/md7 /sysroot
> cat<<JDRIEOF> /sysroot/usr/sbin/rliveinst
> /sbin/mdadm /dev/md7 --add \\\$1 ; while ( grep -q recovery /proc/mdstat ); d\
o sleep 7; done; /sbin/mdadm /dev/md7 --fail /dev/mapper/live-rw ; /sbin/mdadm\
/dev/md7 --remove /dev/mapper/live-rw
> # todo: configure and install grub and run mkinitrd, and free loop devices
> chmod +x /sysroot/usr/sbin/rliveinst
< mount -n -t ext3 /dev/mapper/live-rw /sysroot