Hello Matt,
Matthew Richards wrote:
I suppose that having a Stage0 solution would indeed be more elegant than an updates.img solution. I'm guessing that you would not have to rebuild a Stage0 image very often but would have to re-generate an updates.img patch any time you moved to a new version of Anaconda.
It's not that elegant, just working around limitations of anaconda.
I'm curious about this "some kind of detection with two ks.cfgs" that you refer to. It sounds like you are implying that this is done via a custom patch to Anaconda? I can't help wondering if Anaconda is flexible enough to allow this sort of thing without a custom patch by, say, placing 2 ks= options in the bootloader config - but that would probably result in either an error or only one of the ks.cfg files being parsed . . . sorry, just thinking as I type.
The patch in Bugzilla (#) exactly does make this possible. With this patch, a ks= option allows more than one ks.cfg. However, it's just an other workaround for missing functionality. I still don't know what the best way would be to implement this correctly in anaconda/kickstart.
It is a bit of a challenge to guess what you are getting at with my limited Linux app development knowledge, but I imagine you are proposing to:
(1) Build a new initrd.img containing only the resources needed for your basic environment and the tasks that you need to perform ( I have little idea what this would contain but I suppose I could find out from Anaconda-Init source and its dependencies, or from LSB, or from Linux From Scratch or something similar).
These are not the references I would suggest. It's probably far more easy to look into a standard /boot/initrd-$(uname -r).img. They are now in cpio.gz format, extract it like: mkdir /tmp/my-initrd cd /tmp/my-initrd gunzip /boot/initrd-$(uname -r).img | cpio -id
The script init is the starting point and can be extended/replaced. It might be adviseable to include a busybox or something like it ;)
(2) Write a new Stage0-Anaconda-Init based on Stage1 Anaconda-Init, that will run your tasks and then finish by loading Stage1 initrd.img and running /sbin/loader?
No, don't write a stage0-anaconda-init. It is more like "stage0 bootstraps anaconda". In the init you would do a minimal setup of the system (like a standard initrd.img) and some extras:
* detect the install target (search for /dev/sda,sdb,...) * detect the install source (search for/dev/sda,sdb,http,nfs,...) * create a tmp-directory * extract the original initrd.img which includes the loader * sed ks.cfg and save it in the same tmp-directory * exec chroot tmp-directory /bin/loader
Note that the loader parses /proc/cmdline, therefore you can set ks=file:///tmp/ks.cfg as boot option.
How's that for a guess?
Close, but don't think too complicated. Only try to do the minimal things needed. Everything what the proposed stage0 does can easily be written in shell-scripts.
Good luck, Niels
Niels de Vos wrote:
gunzip /boot/initrd-$(uname -r).img | cpio -id
I think gzip complains about that, but this is fine because it doesn't see the .img suffix.
gunzip </boot/initrd-$(uname -r).img | cpio -id
Hi Neils,
I had a look into your suggestion of customising a standard /boot/initrd-$(uname -r).img in order to create the Stage0 image.
I could not see a simple method of building a custom Stage0 image that would work on unknown scsi hardware without, for example, including many SCSI drivers and a method of detecting the hardware and insmoding the appropriate driver. Any suggestions?
Also, have you tried bootstrapping the loader before (exec chroot tmp-directory /bin/loader)? When I did this I received a complaint about the 'term' variable not being set?
You mentioned a Bugzilla patch that makes it possible to specify more than one ks.cfg file. Do you know the Bugzilla number for this please, I would like to take a look (btw, I did do a quick scan of RH Bugzilla but couldn't find the relevantbug report)?
Regards, Matt
----------------------- Original Message -----------------------
From: Niels de Vos niels.devos@wincor-nixdorf.com To: Matthew Richards Matthew.Richards@contentkeeper.com Cc: anaconda-devel-list@redhat.com Date: Wed, 24 Sep 2008 19:42:45 +0200 Subject: Re: Can the install method be contained within a kickstart file that is referenced via a %include option
Hello Matt,
Matthew Richards wrote:
I suppose that having a Stage0 solution would indeed be more elegant than an updates.img solution. I'm guessing that you would not have to rebuild a Stage0 image very often but would have to re-generate an updates.img patch any time you moved to a new version of Anaconda.
It's not that elegant, just working around limitations of anaconda.
I'm curious about this "some kind of detection with two ks.cfgs" that you refer to. It sounds like you are implying that this is done via a custom patch to Anaconda? I can't help wondering if Anaconda is flexible enough to allow this sort of thing without a custom patch by, say, placing 2 ks= options in the bootloader config - but that would probably result in either an error or only one of the ks.cfg files being parsed . . . sorry, just thinking as I type.
The patch in Bugzilla (#) exactly does make this possible. With this patch, a ks= option allows more than one ks.cfg. However, it's just an other workaround for missing functionality. I still don't know what the best way would be to implement this correctly in anaconda/kickstart.
It is a bit of a challenge to guess what you are getting at with my limited Linux app development knowledge, but I imagine you are proposing to:
(1) Build a new initrd.img containing only the resources needed for your basic environment and the tasks that you need to perform ( I have little idea what this would contain but I suppose I could find out from Anaconda-Init source and its dependencies, or from LSB, or from Linux From Scratch or something similar).
These are not the references I would suggest. It's probably far more easy to look into a standard /boot/initrd-$(uname -r).img. They are now in cpio.gz format, extract it like: mkdir /tmp/my-initrd cd /tmp/my-initrd gunzip /boot/initrd-$(uname -r).img | cpio -id
The script init is the starting point and can be extended/replaced. It might be adviseable to include a busybox or something like it ;)
(2) Write a new Stage0-Anaconda-Init based on Stage1 Anaconda-Init, that will run your tasks and then finish by loading Stage1 initrd.img and running /sbin/loader?
No, don't write a stage0-anaconda-init. It is more like "stage0 bootstraps anaconda". In the init you would do a minimal setup of the system (like a standard initrd.img) and some extras:
* detect the install target (search for /dev/sda,sdb,...) * detect the install source (search for/dev/sda,sdb,http,nfs,...) * create a tmp-directory * extract the original initrd.img which includes the loader * sed ks.cfg and save it in the same tmp-directory * exec chroot tmp-directory /bin/loader
Note that the loader parses /proc/cmdline, therefore you can set ks=file:///tmp/ks.cfg as boot option.
How's that for a guess?
Close, but don't think too complicated. Only try to do the minimal things needed. Everything what the proposed stage0 does can easily be written in shell-scripts.
Good luck, Niels
Hello Matt,
I'm back in the office again and have access to mail and subversion :)
Attached .tgz contains a slightly adjusted stage0-creation the way we use it. The used distribution is Fedora Core 4, but with some small changes it should work on RHEL/CentOS-5 (I'll be working on that later).
Any comments, ideas are very welcome!
Matthew Richards wrote:
I could not see a simple method of building a custom Stage0 image that would work on unknown scsi hardware without, for example, including many SCSI drivers and a method of detecting the hardware and insmoding the appropriate driver. Any suggestions?
No, we also include a lot of drivers for all (our) known hardware.
Also, have you tried bootstrapping the loader before (exec chroot tmp-directory /bin/loader)? When I did this I received a complaint about the 'term' variable not being set?
Never noticed/seen this...
You mentioned a Bugzilla patch that makes it possible to specify more than one ks.cfg file. Do you know the Bugzilla number for this please, I would like to take a look (btw, I did do a quick scan of RH Bugzilla but couldn't find the relevantbug report)?
212146 or https://bugzilla.redhat.com/show_bug.cgi?id=212146
Cheers, Niels
Regards, Matt
----------------------- Original Message -----------------------
From: Niels de Vos niels.devos@wincor-nixdorf.com To: Matthew Richards Matthew.Richards@contentkeeper.com Cc: anaconda-devel-list@redhat.com Date: Wed, 24 Sep 2008 19:42:45 +0200 Subject: Re: Can the install method be contained within a kickstart file that is referenced via a %include option
Hello Matt,
Matthew Richards wrote:
I suppose that having a Stage0 solution would indeed be more elegant than an updates.img solution. I'm guessing that you would not have to rebuild a Stage0 image very often but would have to re-generate an updates.img patch any time you moved to a new version of Anaconda.
It's not that elegant, just working around limitations of anaconda.
I'm curious about this "some kind of detection with two ks.cfgs" that you refer to. It sounds like you are implying that this is done via a custom patch to Anaconda? I can't help wondering if Anaconda is flexible enough to allow this sort of thing without a custom patch by, say, placing 2 ks= options in the bootloader config - but that would probably result in either an error or only one of the ks.cfg files being parsed . . . sorry, just thinking as I type.
The patch in Bugzilla (#) exactly does make this possible. With this patch, a ks= option allows more than one ks.cfg. However, it's just an other workaround for missing functionality. I still don't know what the best way would be to implement this correctly in anaconda/kickstart.
It is a bit of a challenge to guess what you are getting at with my limited Linux app development knowledge, but I imagine you are proposing to:
(1) Build a new initrd.img containing only the resources needed for your basic environment and the tasks that you need to perform ( I have little idea what this would contain but I suppose I could find out from Anaconda-Init source and its dependencies, or from LSB, or from Linux From Scratch or something similar).
These are not the references I would suggest. It's probably far more easy to look into a standard /boot/initrd-$(uname -r).img. They are now in cpio.gz format, extract it like: mkdir /tmp/my-initrd cd /tmp/my-initrd gunzip /boot/initrd-$(uname -r).img | cpio -id
The script init is the starting point and can be extended/replaced. It might be adviseable to include a busybox or something like it ;)
(2) Write a new Stage0-Anaconda-Init based on Stage1 Anaconda-Init, that will run your tasks and then finish by loading Stage1 initrd.img and running /sbin/loader?
No, don't write a stage0-anaconda-init. It is more like "stage0 bootstraps anaconda". In the init you would do a minimal setup of the system (like a standard initrd.img) and some extras:
- detect the install target (search for /dev/sda,sdb,...)
- detect the install source (search for/dev/sda,sdb,http,nfs,...)
- create a tmp-directory
- extract the original initrd.img which includes the loader
- sed ks.cfg and save it in the same tmp-directory
- exec chroot tmp-directory /bin/loader
Note that the loader parses /proc/cmdline, therefore you can set ks=file:///tmp/ks.cfg as boot option.
How's that for a guess?
Close, but don't think too complicated. Only try to do the minimal things needed. Everything what the proposed stage0 does can easily be written in shell-scripts.
Good luck, Niels
Hi Niels,
Firstly let me say thanks for persisting with this issue and for sharing your work. Secondly, sorry for the long delay in my response, I have been focused on other parts of my project to the exclusion of pretty much all else.
I would like to take a look at your stage0-creation but never received the attachment... I think my email client screwed it up because it appears as a block of garbled text at the end of your email.
I did manage to spend some more time on the issue of automatic USB drive identification before my attention was diverted. I was lucky enough to have a friend who is also a developer go over the anaconda code with me.
We think that you may be able to make Anaconda-11.1.2.113 (RHEL/CentOS 5.2) support a HDD install method where the HDD is identified by its file system label. To do this we think you would need to add some code to the Anaconda loader that would allow it to convert a file system label to a device name when mounting.
The idea we had was to borrow some code from e2label that would allow us to read the label in from the file system super block. Then all we would need to do is add a little logic to go through the devices visible to the kernel that would likely be a USB drive and read their f/s labels until we found a match then pass that device name back for mounting in the normal manner.
After a quick look at the later versions of Anaconda I think they are doing something similar to this anyway. Although, the differences between 11.1.2.11 and the latest one a vast so it's hard for me to be sure.
Of course the problem with doing this is that you have to update the changes every time you move to a new version of Anaconda, but hopefully that would not go on for too long before the version that natively supports mounting by f/s label came along and then you could abandon the updates.
All the best,, Matt
----------------------- Original Message -----------------------
From: Niels de Vos niels.devos@wincor-nixdorf.com To: Matthew Richards Matthew.Richards@contentkeeper.com Cc: anaconda-devel-list@redhat.com Date: Tue, 21 Oct 2008 14:41:54 +0200 Subject: [stage0] 100% automated kickstart from usb-stick
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6137EDB4BE904B14E7E09BE Content-Type: multipart/mixed; boundary="------------000508070203010902040208"
This is a multi-part message in MIME format. --------------000508070203010902040208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Matt,
I'm back in the office again and have access to mail and subversion :)
Attached .tgz contains a slightly adjusted stage0-creation the way we use it. The used distribution is Fedora Core 4, but with some small changes it should work on RHEL/CentOS-5 (I'll be working on that later).
Any comments, ideas are very welcome!
Matthew Richards wrote:
I could not see a simple method of building a custom Stage0 image that would work on unknown scsi hardware without, for example, including many SCSI drivers and a method of detecting the hardware and insmoding the appropriate driver. Any suggestions?
No, we also include a lot of drivers for all (our) known hardware.
Also, have you tried bootstrapping the loader before (exec chroot tmp-directory /bin/loader)? When I did this I received a complaint about the 'term' variable not being set?
Never noticed/seen this...
You mentioned a Bugzilla patch that makes it possible to specify more than one ks.cfg file. Do you know the Bugzilla number for this please, I would like to take a look (btw, I did do a quick scan of RH Bugzilla but couldn't find the relevantbug report)?
212146 or https://bugzilla.redhat.com/show_bug.cgi?id=3D212146
Cheers, Niels
Regards, Matt =20 =20 =20 ----------------------- Original Message ----------------------- =20 From: Niels de Vos niels.devos@wincor-nixdorf.com To: Matthew Richards Matthew.Richards@contentkeeper.com Cc: anaconda-devel-list@redhat.com Date: Wed, 24 Sep 2008 19:42:45 +0200 Subject: Re: Can the install method be contained within a kickstart fil=
e that is referenced via a %include option
=20 Hello Matt, =20 Matthew Richards wrote:
I suppose that having a Stage0 solution would indeed be more elegant than an updates.img solution. I'm guessing that you would not have to rebuild a Stage0 image very often but would have to re-generate an updates.img patch any time you moved to a new version of Anaconda.
=20 It's not that elegant, just working around limitations of anaconda. =20 =20
I'm curious about this "some kind of detection with two ks.cfgs" that you refer to. It sounds like you are implying that this is done via a custom patch to Anaconda? I can't help wondering if Anaconda is flexible enough to allow this sort of thing without a custom patch by, say, placing 2 ks=3D options in the bootloader config - but that would probably result in either an error or only one of the ks.cfg files being parsed . . . sorry, just thinking as I type.
=20 The patch in Bugzilla (#) exactly does make this possible. With this patch, a ks=3D option allows more than one ks.cfg. However, it's just an other workaround for missing functionality. I still don't know what =
the best way would be to implement this correctly in anaconda/kickstart=
=2E
=20 =20
It is a bit of a challenge to guess what you are getting at with my limited Linux app development knowledge, but I imagine you are proposing to:
(1) Build a new initrd.img containing only the resources needed for your basic environment and the tasks that you need to perform ( I have little idea what this would contain but I suppose I could find out from Anaconda-Init source and its dependencies, or from LSB, or from Linux From Scratch or something similar).
=20 These are not the references I would suggest. It's probably far more=20 easy to look into a standard /boot/initrd-$(uname -r).img. They are now=
=20
in cpio.gz format, extract it like: mkdir /tmp/my-initrd cd /tmp/my-initrd gunzip /boot/initrd-$(uname -r).img | cpio -id =20 The script init is the starting point and can be extended/replaced. It =
might be adviseable to include a busybox or something like it ;) =20
(2) Write a new Stage0-Anaconda-Init based on Stage1 Anaconda-Init, that will run your tasks and then finish by loading Stage1 initrd.img and running /sbin/loader?
=20 No, don't write a stage0-anaconda-init. It is more like "stage0=20 bootstraps anaconda". In the init you would do a minimal setup of the=20 system (like a standard initrd.img) and some extras: =20
- detect the install target (search for /dev/sda,sdb,...)
- detect the install source (search for/dev/sda,sdb,http,nfs,...)
- create a tmp-directory
- extract the original initrd.img which includes the loader
- sed ks.cfg and save it in the same tmp-directory
- exec chroot tmp-directory /bin/loader
=20 Note that the loader parses /proc/cmdline, therefore you can set=20 ks=3Dfile:///tmp/ks.cfg as boot option. =20 =20
How's that for a guess?
=20 Close, but don't think too complicated. Only try to do the minimal=20 things needed. Everything what the proposed stage0 does can easily be=20 written in shell-scripts. =20 Good luck, Niels =20 =20
--------------enigF6137EDB4BE904B14E7E09BE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc"
--------------enigF6137EDB4BE904B14E7E09BE--
anaconda-devel@lists.stg.fedoraproject.org