Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
sanboot:ubuntu_iscsi [2009/04/30 07:31] commander1024 |
sanboot:ubuntu_iscsi [2010/08/16 20:55] (current) cinquero |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Ubuntu 9.04 (jaunty jackalope) ====== | + | ====== Ubuntu 9.04 (Jaunty Jackalope) and 9.10 (Karmic Koala) ====== |
| (this howto is based on the Debian Etch iSCSI howto with some major changes) | (this howto is based on the Debian Etch iSCSI howto with some major changes) | ||
| ===== Introduction ===== | ===== Introduction ===== | ||
| - | This howto shows how to make an existing installation of a recent *buntu (ubuntu, kubuntu, edubuntu, xubuntu and so on) bootable over the network using iSCSI. I will be using the great gpxe to boot the OS over the network later and a dhcp (v3) Server to easily propagate settings to the gpxe client. | + | This howto shows how to make an existing installation of a recent *buntu (ubuntu, kubuntu, edubuntu, xubuntu and so on) bootable over the network using iSCSI. |
| + | |||
| + | I will be using the great gpxe to boot the OS over the network later and a dhcp (v3) Server to easily propagate settings to the gpxe client. | ||
| If you are experienced with ubuntu and initramfs / initrd creation you can install ubuntu directly onto the iscsi target using the desktop (i386 or amd64) install CD (more on that later). The alternate install disk is not capable of installing additional packages at runtime, because of the limitations of the busybox environment. | If you are experienced with ubuntu and initramfs / initrd creation you can install ubuntu directly onto the iscsi target using the desktop (i386 or amd64) install CD (more on that later). The alternate install disk is not capable of installing additional packages at runtime, because of the limitations of the busybox environment. | ||
| Line 18: | Line 21: | ||
| The debian howto recommended to compile open-iscsi yourself as iscsistart and fwparam_ibft were not available in the debian packages that time. This is not necessary for ubuntu for some reasons: | The debian howto recommended to compile open-iscsi yourself as iscsistart and fwparam_ibft were not available in the debian packages that time. This is not necessary for ubuntu for some reasons: | ||
| - | * fwparam_ibft is no longer a (fully featured) component of neither the open-iscsi semi-stable release (which does not even support kernel 2.6.28+) nor the development git source tree FIXME **Is there some kind of a replacement?** | + | * fwparam_ibft is no longer a (fully featured) component of neither the open-iscsi semi-stable release (which does not even support kernel 2.6.28+) nor the development git source tree. It has been merged into the ''iscsistart'' tool in the same package, and its featureset reduced. |
| * iscsistart is available via [[http://packages.ubuntu.com/jaunty/open-iscsi|open-iscsi]] from the ubuntu repositories. | * iscsistart is available via [[http://packages.ubuntu.com/jaunty/open-iscsi|open-iscsi]] from the ubuntu repositories. | ||
| * the initramfs scripts are even prepared for iscsi usage in some way | * the initramfs scripts are even prepared for iscsi usage in some way | ||
| Line 27: | Line 30: | ||
| sudo aptitude install initramfs-tools open-iscsi sysv-rc-conf | sudo aptitude install initramfs-tools open-iscsi sysv-rc-conf | ||
| + | |||
| + | add iscsi to the list of modules to include in the boot image | ||
| + | |||
| + | sudo echo "iscsi" >> /etc/initramfs-tools/modules | ||
| change the initiatorname (of the client) to something unique if you are planning to set up many boxes | change the initiatorname (of the client) to something unique if you are planning to set up many boxes | ||
| Line 36: | Line 43: | ||
| sudo touch /etc/iscsi/iscsi.initramfs | sudo touch /etc/iscsi/iscsi.initramfs | ||
| - | now we have to workaround a bug in the jaunty stable tree, so edit /usr/share/initramfs-tools/hooks/iscsi with your favourite editor: | + | If you are using Ubuntu 9.04 then you have to workaround a bug in the jaunty stable tree. |
| + | |||
| + | The bug is in /usr/share/initramfs-tools/hooks/iscsi | ||
| + | |||
| + | If you are using Ubuntu 9.10 you don't have to edit this file. | ||
| + | |||
| + | edit /usr/share/initramfs-tools/hooks/iscsi with your favourite editor: | ||
| sudo joe /usr/share/initramfs-tools/hooks/iscsi | sudo joe /usr/share/initramfs-tools/hooks/iscsi | ||
| Line 88: | Line 101: | ||
| title Ubuntu 9.04, kernel 2.6.28-11-generic iSCSI | title Ubuntu 9.04, kernel 2.6.28-11-generic iSCSI | ||
| uuid f859db1e-39f8-4539-9f0e-8292f8f93cca | uuid f859db1e-39f8-4539-9f0e-8292f8f93cca | ||
| - | kernel /vmlinuz-2.6.28-11-generic ISCSI_INITIATOR=iqn.2009-04.arbeitsgruppe:general ISCSI_TARGET_NAME=iqn.2009-04.Arbeitsgruppe.Commander1024:general.ubuntu ISCSI_TARGET_IP=192.168.234.1 ISCSI_TARGET_PORT=3260 root=UUID=021ebcfc-188a-41ba-9864-ee18cbf7af9f ro | + | kernel /vmlinuz-2.6.28-11-generic ip=dhcp ISCSI_INITIATOR=iqn.2009-04.arbeitsgruppe:general ISCSI_TARGET_NAME=iqn.2009-04.Arbeitsgruppe.Commander1024:general.ubuntu ISCSI_TARGET_IP=192.168.234.1 ISCSI_TARGET_PORT=3260 root=UUID=021ebcfc-188a-41ba-9864-ee18cbf7af9f ro |
| initrd /initrd.img-2.6.28-11-generic | initrd /initrd.img-2.6.28-11-generic | ||
| quiet | quiet | ||
| + | |||
| + | WARNING: Make a backup of grub.cfg! When you upgrade your system the ubuntu installer will overwrite it. If that is the case you have to add your iscsi options again! After upgrading always check if your grub.cfg is still intact. | ||
| ===== Transfer your image to the iSCSI Target server ===== | ===== Transfer your image to the iSCSI Target server ===== | ||
| [[sanboot:transfer|transfer the disk image to your iSCSI target]] | [[sanboot:transfer|transfer the disk image to your iSCSI target]] | ||
| + | [[sanboot:iscsi_boot|Boot from your iSCSI target image]] | ||
| ===== Installing ubuntu directly onto the iSCSI SAN ===== | ===== Installing ubuntu directly onto the iSCSI SAN ===== | ||
| - | DELETEME WIP | ||
| - | |||
| Installing ubuntu directly onto SAN is basically the same as the method: HDD -> SAN and takes advantage of the possibility to install packages in the running live cd system. But that means you cannont use the Alternate install disc out-of-the-box. | Installing ubuntu directly onto SAN is basically the same as the method: HDD -> SAN and takes advantage of the possibility to install packages in the running live cd system. But that means you cannont use the Alternate install disc out-of-the-box. | ||
| Line 186: | Line 199: | ||
| ===== FIXME: Notes from contributors ===== | ===== FIXME: Notes from contributors ===== | ||
| + | ==== Ubuntu 10.04 LTS / Lucid ==== | ||
| + | |||
| + | Disclaimer: use everything in this section at your own risk! Think for yourself. | ||
| + | |||
| + | With Lucid, it is basically the same as described above, except for: | ||
| + | |||
| + | * copying early_udev and bugfixing scripts is not necessary | ||
| + | * make sure the OS image contains its target definition under /etc/iscsi/nodes/... -- otherwise iscsid start will kill the connection upon boot. You get that target definition by mounting the iscsi target. iscsiadm seems to be creating it. | ||
| + | * use sysv-rc-conf to remove "networking" and "open-iscsi" from *all* run levels. | ||
| + | * make sure that *all* open-iscsi sysv links are gone. My experience shows that using sysv-rc-conf is *not* enough: | ||
| + | <code> | ||
| + | find /etc -name 'K*open-iscsi' | ||
| + | find /etc -name 'S*open-iscsi' | ||
| + | </code> | ||
| + | * One possibly has to repeat the previous step when upgrading/reinstalling open-iscsi. | ||
| + | * create /etc/init/open-iscsi.conf: | ||
| + | <code> | ||
| + | description "Open-iSCSI" | ||
| + | |||
| + | start on filesystem | ||
| + | # no stopping! | ||
| + | exec /etc/init.d/open-iscsi start | ||
| + | </code> | ||
| + | * Lucid detects on its own if rootfs is an iscsi target. It will prevent network shutdown on shutdown and read-only remounting of the rootfs should make sure that data gets flushed to disk. | ||
| + | * For your own convenience, edit the following line in /etc/default/grub as shown below: | ||
| + | <code> | ||
| + | GRUB_CMDLINE_LINUX_DEFAULT="ip=dhcp ISCSI_INITIATOR=<yourInitiatorName> ISCSI_TARGET_NAME=<yourTargetName> ISCSI_TARGET_IP=<yourTargetIp> ISCSI_TARGET_PORT=3260 quiet splash" | ||
| + | </code> | ||
| + | |||
| + | === Stabilization/Paranoia/Warnings === | ||
| + | |||
| + | in order to prevent data loss (for example, a corrupted dpkg db), one may do the following stuff: | ||
| + | |||
| + | * Enable data journaling. That will cut your maximum write performance in half. | ||
| + | * One may increase node.session.timeo.replacement_timeout in iscsid.conf to avoid escalation of temporary connection problems to upper layers. In *my* situation it (almost) *never* makes sense to tell the ext4 driver about I/O problems because there is no fallback. It would just give me an unclean filesystem (not unmounted properly, like a hard reset). However(!!), an unclean filesystem may be better than a totally screwed one: imagine your iSCSI target host crashes, looses some data that still has not been written to disk, and the client continues to use that target without doing a journal replay first... personally, I try to avoid that situation by never starting the iSCSI target automatically (removed from init scripts, starting it manually after killing the client machines...). IMHO the iSCSI protocol is a bit dumb. The target should detect a crash and refuse session continuation after restart... again, I'm not liable for *any* sort of data loss if you act according to these explanations. You *will* screw your data. Sooner or later. | ||
| + | * Additional warning: SAN boot using gpxe seems to not allow using a MaxSessions=1/MaxConnections=1 setting for the target, which would prevent concurrent accesses -- a very basic need for data integrity purposes. | ||
