system:vicki_debian_lenny_to_squeeze
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| system:vicki_debian_lenny_to_squeeze [2012-03-13T04:29:31+0000] – bit more about pre-upgrade steps will be done as feasible michael_paoli | system:vicki_debian_lenny_to_squeeze [2013-02-17T20:00:48+0000] (current) – typo/wordo fix michael_paoli | ||
|---|---|---|---|
| Line 543: | Line 543: | ||
| # | # | ||
| </ | </ | ||
| - | |||
| ===== vicki host install/" | ===== vicki host install/" | ||
| < | < | ||
| Line 645: | Line 644: | ||
| o /boot | o /boot | ||
| o vicki-boot | o vicki-boot | ||
| - | o Finish partitioning | + | o Finish partitioning |
| (continue without swap) | (continue without swap) | ||
| o Install base system | o Install base system | ||
| Line 846: | Line 845: | ||
| ===== sflug VM upgrade to Debian GNU/Linux 6.0.4 ===== | ===== sflug VM upgrade to Debian GNU/Linux 6.0.4 ===== | ||
| * sflug VM log bits made available here: [[http:// | * sflug VM log bits made available here: [[http:// | ||
| - | * upgrade to be done [[http:// | + | * upgrade to be done [[http:// |
| - | * will be upgrading, mostly per: | + | * will be upgrading/was upgraded, mostly per: |
| * **backup(s)** - since [www.]sf-lug.com is (generally) " | * **backup(s)** - since [www.]sf-lug.com is (generally) " | ||
| * from host (vicki), sflug' | * from host (vicki), sflug' | ||
| Line 858: | Line 857: | ||
| * from the host there are separate and unique LVs, and for the most part host wouldn' | * from the host there are separate and unique LVs, and for the most part host wouldn' | ||
| * we won't present both " | * we won't present both " | ||
| - | * also, these backups are " | + | * also, these backups are " |
| - | * note also this is separate/ | + | * note also this is separate/ |
| + | * doing the backup - here's part of what doing the " | ||
| + | < | ||
| + | //I show my comments on lines starting with // | ||
| + | //I don't show all output of all commands (mostly reduced for brevity/ | ||
| + | //from sflug (guest), we have relatively simplistic filesystem and swap setup, | ||
| + | //one " | ||
| + | //with partition for root (/) filesystem, and swap | ||
| + | # sfdisk -uS -l | ||
| + | |||
| + | Disk /dev/sda: 1435 cylinders, 255 heads, 63 sectors/ | ||
| + | Units = sectors of 512 bytes, counting from 0 | ||
| + | |||
| + | | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | / | ||
| + | # | ||
| + | //and to confirm a bit - ignoring virtual filesystems, | ||
| + | # mount -t notmpfs, | ||
| + | /dev/sda1 on / type ext3 (rw, | ||
| + | # awk ' | ||
| + | UUID=792a4837-91bc-4b36-bce7-a5a4208845bf / ext3 errors=remount-ro 0 1 #/ | ||
| + | # blkid /dev/sda1 | ||
| + | /dev/sda1: UUID=" | ||
| + | # cat / | ||
| + | Filename | ||
| + | / | ||
| + | # awk ' | ||
| + | UUID=e326206f-55a6-4fbb-8c81-62f8dfb30753 none swap sw 0 0 #/dev/sda2 LABEL=swap | ||
| + | # blkid /dev/sda2 | ||
| + | /dev/sda2: TYPE=" | ||
| + | # | ||
| + | //so, quite simple there and no surprises. | ||
| + | # hostname | ||
| + | vicki | ||
| + | # virsh list --all | ||
| + | Id Name | ||
| + | ---------------------------------- | ||
| + | 2 sflug running | ||
| + | 26 balug running | ||
| + | |||
| + | # virsh dumpxml sflug | fgrep '< | ||
| + | <source dev='/ | ||
| + | # | ||
| + | //so, the storage for the sflug VM is on / | ||
| + | //how much space used and free (and PE size) for that VG? | ||
| + | # vgdisplay / | ||
| + | PE Size 4.00 MiB | ||
| + | Total PE 6904 | ||
| + | Alloc PE / Size 2941 / 11.49 GiB | ||
| + | Free PE / Size 3963 / 15.48 GiB | ||
| + | # | ||
| + | //so, we can see that a fair bit less than half of the VG is used, | ||
| + | //thus we know we've got ample room to complete our backup, | ||
| + | //and also for our snapshot LV to be present; | ||
| + | //snapshot LV doesn' | ||
| + | //as it essentially only tracks changed data, | ||
| + | //and since we'll do this backup relatively quickly, | ||
| + | //and the sflug host won't be changing lots of data nor quickly at that time anyway, | ||
| + | //we don't need much space for the snapshot. | ||
| + | //So, let's do a good test run of our procedure: | ||
| + | //we peek at LV names in the VG, to avoid any accidental name collision: | ||
| + | # ls / | ||
| + | sda sflug-disk-BACKUP | ||
| + | # | ||
| + | //we examine size of our source LV: | ||
| + | # lvdisplay / | ||
| + | Current LE | ||
| + | # | ||
| + | //we create our target LV, | ||
| + | // | ||
| + | //as that's codename of the " | ||
| + | //and less likely to cause confusion (e.g. backup, which backup, when, of what?) | ||
| + | # lvcreate -l 2816 -n sda-lenny vg-sflug | ||
| + | Logical volume " | ||
| + | # | ||
| + | //we check on free PEs in our VG - we'll use them all for our snapshot (probably excessive), | ||
| + | //but we only need them for a quite short while anyway, | ||
| + | //so not an issue to be a bit excessive here for a quite short while anyway. | ||
| + | //we reexamine our free PEs in the VG: | ||
| + | # vgdisplay / | ||
| + | Free PE / Size 1147 / 4.48 GiB | ||
| + | # | ||
| + | //we use them all for our snapshot LV: | ||
| + | # lvcreate -l 1147 -n sda-snapshot -s / | ||
| + | Logical volume " | ||
| + | //I include use of time below, just to see how long it takes (dd also happens to provide similar information) | ||
| + | //and also, especially when operating as superuser (root), we want to be sure our commands are correct, | ||
| + | //Unix, and mostly likewise Linux, tends to presume one knows what one is doing, | ||
| + | //and probably doubly (or more) so for superuser, | ||
| + | //so carefully triple-check the command(s) before viciously striking the < | ||
| + | //(says me ;-) - has saved my butt on more than one occasion) | ||
| + | //here we want to be particularly careful with where we're writing our data to, | ||
| + | //what we remove, | ||
| + | //and also that we in fact pick our correct data source | ||
| + | # time dd if=/ | ||
| + | 2816+0 records in | ||
| + | 2816+0 records out | ||
| + | 11811160064 bytes (12 GB) copied, 424.946 s, 27.8 MB/s | ||
| + | |||
| + | real 7m4.957s | ||
| + | user 0m0.016s | ||
| + | sys | ||
| + | //a bit over 7 minutes - from a point-in-time snapshot, recoverable, | ||
| + | //had we done that instead with source of the live rw mounted sda (well, containing sda1), | ||
| + | //what we'd have had instead in our target data would have been an inconsistent mess with no guarantees of recoverability | ||
| + | //and out of curiosity, just before removing it, | ||
| + | //I peek at our snapshot to see how much space it has actually used: | ||
| + | # lvdisplay / | ||
| + | Current LE | ||
| + | COW-table LE | ||
| + | Allocated to snapshot | ||
| + | //as we can see, almost none (0.16%) | ||
| + | //and removing our snapshot: | ||
| + | # lvremove -f / | ||
| + | Logical volume " | ||
| + | # | ||
| + | //removing the snapshot is important - if it's left around ("too long") and runs out of room, I/O on the LVs stops | ||
| + | //(that can then be corrected by extending the snapshot LV, or removing it) | ||
| + | //pretty much the same LV snapshot techniques are often used for live database (DB) backups, e.g.: | ||
| + | //put the relevant database files/ | ||
| + | //(done within the DB, and in many cases involves more than one which must be done together as a set), | ||
| + | //snapshot them (as set), take database (or those files/ | ||
| + | //proceed to next set, etc., | ||
| + | //and also release each snapshot after it (or its set) has completed being backed up. | ||
| + | //so, as exercise, we'll check the recoverability of our backup, | ||
| + | //since it's just one journaled filesystem (and swap, that we don't care about the swap data), | ||
| + | //fairly simple to test (we won't do this test when we do our backup "for real" - we know it works, | ||
| + | // | ||
| + | //And to note first, we're going to bend our UUID " | ||
| + | //as here we're going to give host peek into the guest' | ||
| + | //as we only let it see one instance of this UUID, | ||
| + | //as the other duplicate UUIDs are within the partitions of / | ||
| + | //which we won't be having the host access (certainly at least not at the same time!) | ||
| + | //from our partition information earlier from the guest (we could also examine it from the host), | ||
| + | //we know how to construct a loop device to access just the first partition within our LV copy: | ||
| + | # losetup -o `expr 512 ' | ||
| + | / | ||
| + | # | ||
| + | //does it match what we expect? | ||
| + | # blkid / | ||
| + | /dev/loop0: UUID=" | ||
| + | # | ||
| + | //yes ... journaled filesystem, so, manner in which we copied it should be quite recoverable, | ||
| + | //but rather than just try to mount it (which may replay journal and do relatively light checks), | ||
| + | // | ||
| + | // | ||
| + | //to replay - but that should be about it). | ||
| + | # fsck.ext3 -f / | ||
| + | e2fsck 1.41.12 (17-May-2010) | ||
| + | /dev/loop0: recovering journal | ||
| + | Clearing orphaned inode 278547 (uid=0, gid=1, mode=0100700, | ||
| + | Pass 1: Checking inodes, blocks, and sizes | ||
| + | Pass 2: Checking directory structure | ||
| + | Pass 3: Checking directory connectivity | ||
| + | Pass 4: Checking reference counts | ||
| + | Pass 5: Checking group summary information | ||
| + | |||
| + | /dev/loop0: ***** FILE SYSTEM WAS MODIFIED ***** | ||
| + | /dev/loop0: 28306/ | ||
| + | # | ||
| + | //and as we'd expect, quite " | ||
| + | //some bit(s) like Clearing orphaned inode or similar, may be expected, | ||
| + | //e.g. if snapshot happens, and there are unlinked open files at the time, | ||
| + | //then those files no longer exist in any directory, | ||
| + | //but their inode (and storage, if any) hasn't yet been freed, | ||
| + | //while that's normal for Unix/Linux if a PID still has the files open, | ||
| + | // | ||
| + | //so that bit if housekeeping on the filesystem is still to be done (which would | ||
| + | //normally happen rather quickly on live mounted filesystem after last PID having the unlinked | ||
| + | //file open, closed the file (explicitly, | ||
| + | //we could do more with that filesystem (e.g. testing, etc.) if we wished at this point, | ||
| + | //but that more than suffices for our testing here, so time to free up that loop device: | ||
| + | # losetup -d / | ||
| + | # | ||
| + | </ | ||
| * **incorporating " | * **incorporating " | ||
| * from earlier similar upgrade done on balug qemu-kvm VM guest on same host, encountered **problem with reboot - namely upgrade procedure produced a flawed / | * from earlier similar upgrade done on balug qemu-kvm VM guest on same host, encountered **problem with reboot - namely upgrade procedure produced a flawed / | ||
| Line 873: | Line 1049: | ||
| * **relevant Debian documentation**: | * **relevant Debian documentation**: | ||
| * [[http:// | * [[http:// | ||
| - | * **especially: | + | * **especially: |
| - | * and also if/ | + | * will do pre-upgrade steps in advance as feasible, have done the following: |
| + | * 4.1.1\\ output of:\\ # dpkg_--get-selections ' | ||
| + | * 4.1.6 checked package splashy not installed | ||
| + | * 4.2 - should be good on no 3rd party packages, etc., system has been updated to the latest point release of lenny (5.0.10). | ||
| + | * 4.2.1 checked good: No packages are scheduled to be installed, removed, or upgraded. | ||
| + | * 4.2.2 good (/ | ||
| + | * 4.2.3:\\ looks good: # dpkg --audit\\ dpkg -l looks quite good, used: # dpkg -l | grep -v '^ii '\\ dpkg --get-selections ' | ||
| + | * 4.2.4 proposed-updates not in / | ||
| + | * 4.2.5 - presumably not an issue (doesn' | ||
| + | * **done** (main upgrade proper sequence, and immediately preceding steps): | ||
| + | * did LV snapshot backup, from host (vicki) (target created earlier; also, this was set up to execute via at(1) at 5:40 P.M. on the day of the upgrade - 20 minutes prior to start of our upgrade maintenance window; and in earlier test runs, completed in under 10 minutes; checked that it completed okay, script and output on viki host under / | ||
| + | * # lvcreate -l 1147 -n sda-snapshot -s / | ||
| + | * # time dd if=/ | ||
| + | * # lvremove -f / | ||
| + | * and here's what that script that was executed looks like, and its output: | ||
| + | < | ||
| + | # hostname; pwd -P; cat bkup; echo; cat bkup.out | ||
| + | vicki | ||
| + | / | ||
| + | #!/bin/sh | ||
| + | set -e | ||
| + | umask 077 | ||
| + | cd / | ||
| + | at 1740 << \__EOT__ | ||
| + | set -e | ||
| + | umask 077 | ||
| + | cd / | ||
| + | exec >> bkup.out 2>& | ||
| + | echo start `date -Iseconds` | ||
| + | [ -b / | ||
| + | lvcreate -l 1147 -n sda-snapshot -s / | ||
| + | time dd if=/ | ||
| + | lvremove -f / | ||
| + | } | ||
| + | echo end `date -Iseconds` | ||
| + | __EOT__ | ||
| + | |||
| + | start 2012-03-14T17: | ||
| + | Logical volume " | ||
| + | 2816+0 records in | ||
| + | 2816+0 records out | ||
| + | 11811160064 bytes (12 GB) copied, 421.079 s, 28.0 MB/s | ||
| + | 0.01user 34.83system 7: | ||
| + | 23068824inputs+23068680outputs (1major+1242minor)pagefaults 0swaps | ||
| + | Logical volume " | ||
| + | end 2012-03-14T17: | ||
| + | # | ||
| + | </ | ||
| + | * present Debian GNU/Linux 6.0.4 " | ||
| + | * on guest, scan SCSI devices, create mount point (if not present), update /etc/fstab, and mount it: | ||
| + | * # (for tmp in / | ||
| + | * # (umask 022 && mkdir / | ||
| + | * Even though we told the host to present the device to guest as sdc, it showed up on guest as sdb, so we went with that: | ||
| + | * add to / | ||
| + | * # mount / | ||
| + | * 4.3 - continue per documentation\\ add new cdrom ISO to / | ||
| + | * looking now at the above, and checking shell history, had actually intended to use / | ||
| + | * # ln -s / | ||
| + | * ... | ||
| + | * 4.4.5 **before** first reboot, inspected / | ||
| + | * inspected legacy grub, and grub2 configurations - grub looked fine, tweaked grub2 - mostly via / | ||
| + | * ... | ||
| + | * we essentially completed through step 4.6.3, " | ||
| + | * we also checked both web server and DNS server both on the host and up and running and operational as expected. | ||
| + | * **and done(!)** - these bits were completed later, but not later than 2012-03-17: | ||
| + | * went through and completed our various clean-up tasks: | ||
| + | * reviewed configurations - in the interests of time (and uptime), some of the configurations where we had local modifications, | ||
| + | * init / rc stuff - we didn't earlier get the advantages of the newer faster start-up system - some legacy/ | ||
| + | * 4.7 (the part before 4.7.1) | ||
| + | * steps starting at and beyond step 4.8 | ||
| + | * saved script output from most of the upgrade process - reviewed that for any potentially security sensitive bits, and as there weren' | ||
| + | * high-level (human written (with some machine assist) and intended for human consumption) log file for the system is available at:\\ [[http:// | ||
| + | * did full virtual power reboot test (did reboot tests 2012-03-14, but not with full virtual power down and back up again with guest), ensured that guest comes up fine with no need for any console input being provided | ||
| + | * and (documentation bits - didn't really need to refer to or use this particular document with/for our upgrade) | ||
system/vicki_debian_lenny_to_squeeze.1331612971.txt.bz2 · Last modified: 2012-03-13T04:29:31+0000 by michael_paoli