"Jean-David Beyer" <jeandavid8@verizon.net> wrote in message
news:zq5hi.3903$RZ1.299@trnddc05...
> RHL9 supports ext3 file systems; all you need do is run tune2fs and tell
> it
> to upgrade (on a partition by partition basis, so you need not change all
> at
> once).
>
> Something like the following if it is hda7 that you want to change. You
> can
> probably change the root file system as well, without umounting it, but
> you
> probably have to reboot to get it to take effect.
>
> umount /dev/hda7
> tune2fs -j /dev/hda7
> [change /etc/fstab from ext2 to ext3 for /dev/hda7]
> mount /dev/hda7
>
> See the man pages to be sure.
>

Thanks. Gave that a try. It converted easily enough, but booting now gives
an "EXT2-fs warning", (ext2_read_super: mounting ext3 filesystem as ext2).

/etc/fstab was changed to reflect ext3

Haven't had time to dig further, but suspect the kernel may simply not have
ext3 support. How can you tell if it does or doesn't (?).

If it is going to require building a whole new kernel to get use of ext3,
I'll likely just convert the FS back to ext2.

Thanks...

"Ercmz" <none@nowhere.cvb> wrote in message
news:46855129$0$3139$4c368faf@roadrunner.com...
> Thanks. Gave that a try. It converted easily enough, but booting now
> gives an "EXT2-fs warning", (ext2_read_super: mounting ext3 filesystem as
> ext2).
>
> /etc/fstab was changed to reflect ext3
>
> Haven't had time to dig further, but suspect the kernel may simply not
> have ext3 support. How can you tell if it does or doesn't (?).
>
> If it is going to require building a whole new kernel to get use of ext3,
> I'll likely just convert the FS back to ext2.
>
> Thanks...

I'm more of a hardware person than software...

All the partitions, except for the / (root) partition, appear to function as
ext3 now.

This is what I found:

http://www.redhat.com/support/wpapers/redhat/ext3/

[ It does look like ext3 support is directly compiled into the stock RH9
2.4.20-6 kernel, versus loading as a module, but I can only guess. I don't
know how to check if it is or not. ]

"The tune2fs program can add a journal to an existing ext2 file system. If
the file system is already mounted while it is being transitioned, the
journal will be visible as the file .journal in the root directory of the
file system. If the file system is not mounted, the journal will be hidden
and will not appear in the file system. Just run tune2fs -j /dev/hda1 (or
whatever device holds the file system you are transitioning) and change ext2
to ext3 on the matching lines in /etc/fstab."

[ The above is straight-forward and did exactly as advertised for all
partitions except for the / (root) partition. ]

"If you are transitioning your root file system, you will have to use an
initrd to boot. Run the mkinitrd program as described in the manual and make
sure that your LILO or GRUB configuration loads the initrd. (If you fail to
make that change, the system will still boot, but the root file system will
be mounted as ext2 instead of ext3 - you can tell this by looking at the
output of the command cat /proc/mounts.)"

[ Yep, that is exactly the behavior I'm seeing. The root filesystem is
being mounted as ext2. ...but
"use an initrd to boot." <-- I don't know what the heck an "initrd" is,
let alone how to use one.
"Run the mkinitrd program as described in the manual" <--- what manual?
]

On 2007-06-29, Ercmz <none@nowhere.cvb> wrote:
>
> "If you are transitioning your root file system, you will have to use an
> initrd to boot. Run the mkinitrd program as described in the manual and make
> sure that your LILO or GRUB configuration loads the initrd. (If you fail to
> make that change, the system will still boot, but the root file system will
> be mounted as ext2 instead of ext3 - you can tell this by looking at the
> output of the command cat /proc/mounts.)"
>
> [ Yep, that is exactly the behavior I'm seeing. The root filesystem is
> being mounted as ext2. ...but
> "use an initrd to boot." <-- I don't know what the heck an "initrd" is,
> let alone how to use one.
> "Run the mkinitrd program as described in the manual" <--- what manual?
> ]

You should also be able to boot from a CD or floppy to effect the
transition for the root filesystem. Boot from CD/floppy, e2fsck the root
filesystem, which will transition the journal, then boot from hard disk,
which should now not need to try to transition the root filesystem from
ext2 to ext3. (I've never actually tried this before, however, so if
you are concerned, my guess is the man page for mkinitrd might help you
make a new initrd.)

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

Ercmz wrote:
> "Ercmz" <none@nowhere.cvb> wrote in message
> news:46855129$0$3139$4c368faf@roadrunner.com...
>> Thanks. Gave that a try. It converted easily enough, but booting now
>> gives an "EXT2-fs warning", (ext2_read_super: mounting ext3 filesystem as
>> ext2).
>>
>> /etc/fstab was changed to reflect ext3
>>
>> Haven't had time to dig further, but suspect the kernel may simply not
>> have ext3 support. How can you tell if it does or doesn't (?).
>>
>> If it is going to require building a whole new kernel to get use of ext3,
>> I'll likely just convert the FS back to ext2.
>>
>> Thanks...
>
> I'm more of a hardware person than software...
>
> All the partitions, except for the / (root) partition, appear to function as
> ext3 now.
>
> This is what I found:
>
> http://www.redhat.com/support/wpapers/redhat/ext3/
>
> [ It does look like ext3 support is directly compiled into the stock RH9
> 2.4.20-6 kernel, versus loading as a module, but I can only guess. I don't
> know how to check if it is or not. ]
>
> "The tune2fs program can add a journal to an existing ext2 file system. If
> the file system is already mounted while it is being transitioned, the
> journal will be visible as the file .journal in the root directory of the
> file system. If the file system is not mounted, the journal will be hidden
> and will not appear in the file system. Just run tune2fs -j /dev/hda1 (or
> whatever device holds the file system you are transitioning) and change ext2
> to ext3 on the matching lines in /etc/fstab."
>
> [ The above is straight-forward and did exactly as advertised for all
> partitions except for the / (root) partition. ]

ext3 is built into the kernel, I thought. Now at one time, people kept their
/boot partition as ext2, and I still do this, but there is no reason for it,
just my policy. Perhaps it requires some module to boot up, and has to be up
to load the module. IIRC (and I may not), only the /boot partition needs (or
needed) to be ext2, not the whole / partition, so if it matters to you, make
a separate /boot partition. 50 Megabytes should be enough. Maybe even 25
megabytes.
>
> "If you are transitioning your root file system, you will have to use an
> initrd to boot. Run the mkinitrd program as described in the manual and make
> sure that your LILO or GRUB configuration loads the initrd. (If you fail to
> make that change, the system will still boot, but the root file system will
> be mounted as ext2 instead of ext3 - you can tell this by looking at the
> output of the command cat /proc/mounts.)"
>
> [ Yep, that is exactly the behavior I'm seeing. The root filesystem is
> being mounted as ext2. ...but
> "use an initrd to boot." <-- I don't know what the heck an "initrd" is,
> let alone how to use one.
> "Run the mkinitrd program as described in the manual" <--- what manual?
> ]
>
>
>


--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 18:20:01 up 9 days, 1:55, 3 users, load average: 4.38, 4.32, 4.27

"Jean-David Beyer" <jeandavid8@verizon.net> wrote in message
news:FEfhi.34$Np2.11@trnddc07...
> Ercmz wrote:
>> "Ercmz" <none@nowhere.cvb> wrote in message
>> news:46855129$0$3139$4c368faf@roadrunner.com...
>>> Thanks. Gave that a try. It converted easily enough, but booting now
>>> gives an "EXT2-fs warning", (ext2_read_super: mounting ext3 filesystem
>>> as
>>> ext2).
>>>
>>> /etc/fstab was changed to reflect ext3
>>>
>>> Haven't had time to dig further, but suspect the kernel may simply not
>>> have ext3 support. How can you tell if it does or doesn't (?).
>>>
>>> If it is going to require building a whole new kernel to get use of
>>> ext3,
>>> I'll likely just convert the FS back to ext2.
>>>
>>> Thanks...
>>
>> I'm more of a hardware person than software...
>>
>> All the partitions, except for the / (root) partition, appear to function
>> as
>> ext3 now.
>>
>> This is what I found:
>>
>> http://www.redhat.com/support/wpapers/redhat/ext3/
>>
>> [ It does look like ext3 support is directly compiled into the stock RH9
>> 2.4.20-6 kernel, versus loading as a module, but I can only guess. I
>> don't
>> know how to check if it is or not. ]
>>
>> "The tune2fs program can add a journal to an existing ext2 file system.
>> If
>> the file system is already mounted while it is being transitioned, the
>> journal will be visible as the file .journal in the root directory of the
>> file system. If the file system is not mounted, the journal will be
>> hidden
>> and will not appear in the file system. Just run tune2fs -j /dev/hda1 (or
>> whatever device holds the file system you are transitioning) and change
>> ext2
>> to ext3 on the matching lines in /etc/fstab."
>>
>> [ The above is straight-forward and did exactly as advertised for all
>> partitions except for the / (root) partition. ]
>
> ext3 is built into the kernel, I thought. Now at one time, people kept
> their
> /boot partition as ext2, and I still do this, but there is no reason for
> it,
> just my policy. Perhaps it requires some module to boot up, and has to be
> up
> to load the module. IIRC (and I may not), only the /boot partition needs
> (or
> needed) to be ext2, not the whole / partition, so if it matters to you,
> make
> a separate /boot partition. 50 Megabytes should be enough. Maybe even 25
> megabytes.

Hi,

Spent a few minutes reading earlier and think I may be tracking somewhat.
From what I read, and what it looks like on my end, ext3 support appears to
be through a module and not compiled into the kernel.
And since the modules are on the root partition, it is a chicken and egg
thing. It needs to load the ext3 module to do ext3, but has to be in ext2
to get at it.
If I read and understood correctly, if I were to made an initrd (since
learned that is the 'initial ramdisk') with ext3 support, then it would
work?
Went ahead and downloaded full kernel sources as well. Grabbed the config's
and mod-init-tools as well. Can't say too thrilled about building a new
kernel. Did it years ago and while it did work, it was like having a root
canal. (I'm not a software person. LOL.)

I see what you are saying about keeping /boot as ext2. Makes sense.
Confused a bit on how that would help module loading though, as they all
live in /lib/modules in the / partition.

Thanks!

The drives (and partitions) on this 'ol computer are itty-bitty small..

---------------------------
# df -T

Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/hdc1 ext3 2433136 1902624 404920 83% /
/dev/hda1 ext3 101485 9017 87228 10% /boot
none tmpfs 63192 0 63192 0% /dev/shm
/dev/hda4 ext3 1139327 312066 768394 29% /hda4
---------------------------
# cat /etc/fstab

LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/hda2 swap swap defaults 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0
0
/dev/cdrom /mnt/cdrom udf,iso9660
noauto,owner,kudzu,ro 0 0
---------------------------
# cat /proc/modules
loop 11224 0 (autoclean)
autofs 12148 1 (autoclean)
3c59x 29360 1
ext3 64736 2 (autoclean)
jbd 47860 2 (autoclean) [ext3]
mousedev 5204 0 (unused)
keybdev 2720 0 (unused)
hid 20772 1
input 5632 0 [mousedev keybdev hid]
ehci-hcd 18472 0 (unused)
usb-ohci 20392 0 (unused)
usbcore 73088 1 [hid ehci-hcd usb-ohci]
---------------------------

Ercmz wrote:

> Spent a few minutes reading earlier and think I may be tracking somewhat.
> From what I read, and what it looks like on my end, ext3 support appears to
> be through a module and not compiled into the kernel.
> And since the modules are on the root partition, it is a chicken and egg
> thing. It needs to load the ext3 module to do ext3, but has to be in ext2
> to get at it.
> If I read and understood correctly, if I were to made an initrd (since
> learned that is the 'initial ramdisk') with ext3 support, then it would
> work?
> Went ahead and downloaded full kernel sources as well. Grabbed the config's
> and mod-init-tools as well. Can't say too thrilled about building a new
> kernel. Did it years ago and while it did work, it was like having a root
> canal. (I'm not a software person. LOL.)
>
> I see what you are saying about keeping /boot as ext2. Makes sense.
> Confused a bit on how that would help module loading though, as they all
> live in /lib/modules in the / partition.
>
Unless I am mistaken, you can boot the kernel entirely from /boot. Once the
kernel is booted and the rest of the system comes up, early in the process,
/ is mounted, and once that is done, the module for ext3 can be loaded. Now
when that was an issue, I ran Red Hat Linux 9, and I know I did nothing
special to get it to load, and I definitely had / as ext3. So either Red Hat
supplied the right initrd, or I did not need a special one. I know I never
made one, and I never compiled a kernel in those days.

With Red Hat Enterprise Linux, here is the log after a reboot

Jun 19 16:16:37 trillian kernel: Attached scsi disk sda at scsi0, channel 0,
id 0, lun 0
Jun 19 16:16:37 trillian kernel: Attached scsi disk sdb at scsi0, channel 0,
id 1, lun 0
Jun 19 16:16:37 trillian kernel: Attached scsi disk sdc at scsi0, channel 0,
id 2, lun 0
Jun 19 16:16:37 trillian kernel: Attached scsi disk sdd at scsi0, channel 0,
id 3, lun 0
Jun 19 16:16:37 trillian kernel: SCSI device sda: 35916548 512-byte hdwr
sectors (18389 MB)
Jun 19 16:16:37 trillian kernel: sda: sda1 sda2 sda3
Jun 19 16:16:37 trillian kernel: SCSI device sdb: 35916548 512-byte hdwr
sectors (18389 MB)
Jun 19 16:16:37 trillian kernel: sdb: sdb1 sdb2
Jun 19 16:16:37 trillian kernel: SCSI device sdc: 35916548 512-byte hdwr
sectors (18389 MB)
Jun 19 16:16:37 trillian kernel: sdc: sdc1 sdc2
Jun 19 16:16:37 trillian kernel: SCSI device sdd: 35916548 512-byte hdwr
sectors (18389 MB)
Jun 19 16:16:37 trillian kernel: sdd: sdd1 sdd2
Jun 19 16:16:37 trillian kernel: blk: queue f7a21818, I/O limit 524287Mb
(mask 0x7fffffffff)
Jun 19 16:16:37 trillian kernel: Vendor: EXABYTE Model: VXA-2
Rev: 2120
Jun 19 16:16:37 trillian kernel: Type: Sequential-Access
ANSI SCSI revision: 02
Jun 19 16:16:37 trillian kernel: blk: queue f7a21618, I/O limit 524287Mb
(mask 0x7fffffffff)
Jun 19 16:16:37 trillian kernel: Journalled Block Device driver loaded <---<<<
Jun 19 16:16:37 trillian kernel: kjournald starting. Commit interval 5 seconds
Jun 19 16:16:37 trillian kernel: EXT3-fs: mounted filesystem with ordered
data mode. <---<<<

Now what I do not understand is that it loaded the Journalled Block Device
Driver before it mounted the first EXT3-fs, the one that contains the root
(/) directory where the modules are.

Only much later in the file do I get:

Jun 19 16:16:08 trillian rc.sysinit: Checking root filesystem succeeded
Jun 19 16:16:08 trillian rc.sysinit: Remounting root filesystem in
read-write mode: succeeded <---<<< but how was it mounted the first time?
Jun 19 16:16:08 trillian rc.sysinit: Activating swap partitions: succeeded
Jun 19 16:16:09 trillian rc.sysinit: Finding module dependencies: succeeded

But that appears to have happened earlier. Queuing to /var/log/messages
seems peculiar here. It appears that just before this, it reset the system
clock, so this is really later and in proper sequence. Whew!

I see, grub knows where initrd is, and it is in the /boot partition. I
suppose these days, the initrd has the journalling module in it.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 07:10:01 up 9 days, 14:46, 5 users, load average: 4.24, 4.16, 4.17

"Keith Keller" <kkeller-usenet@wombat.san-francisco.ca.us> wrote in message
news:va6gl4xi21.ln2@goaway.wombat.san-francisco.ca.us...
> You should also be able to boot from a CD or floppy to effect the
> transition for the root filesystem. Boot from CD/floppy, e2fsck the root
> filesystem, which will transition the journal, then boot from hard disk,
> which should now not need to try to transition the root filesystem from
> ext2 to ext3. (I've never actually tried this before, however, so if
> you are concerned, my guess is the man page for mkinitrd might help you
> make a new initrd.)
>
> --keith

Hi,

Actually, I did try a variant of that after converting and making the
journals. I figured running an e2fsck right away afterwards would make
sense, so unmounted the non root partitions and ran it. For the root
partition (yep, I know this was bad -- but I was lazy!), during a boot
sequence, I powered down so that the next boot sequence, it would whine
about the unclean powerdown and would bring up the interactive mode where
e2fsck could be run against the root partition...

"Jean-David Beyer" <jeandavid8@verizon.net> wrote in message
news:0irhi.890$Pv2.143@trnddc03...
> Ercmz wrote:
>
>> Spent a few minutes reading earlier and think I may be tracking somewhat.
>> From what I read, and what it looks like on my end, ext3 support appears
>> to
>> be through a module and not compiled into the kernel.
>> And since the modules are on the root partition, it is a chicken and egg
>> thing. It needs to load the ext3 module to do ext3, but has to be in
>> ext2
>> to get at it.
>> If I read and understood correctly, if I were to made an initrd (since
>> learned that is the 'initial ramdisk') with ext3 support, then it would
>> work?
>> Went ahead and downloaded full kernel sources as well. Grabbed the
>> config's
>> and mod-init-tools as well. Can't say too thrilled about building a new
>> kernel. Did it years ago and while it did work, it was like having a
>> root
>> canal. (I'm not a software person. LOL.)
>>
>> I see what you are saying about keeping /boot as ext2. Makes sense.
>> Confused a bit on how that would help module loading though, as they all
>> live in /lib/modules in the / partition.
>>
> Unless I am mistaken, you can boot the kernel entirely from /boot. Once
> the
> kernel is booted and the rest of the system comes up, early in the
> process,
> / is mounted, and once that is done, the module for ext3 can be loaded.
> Now
> when that was an issue, I ran Red Hat Linux 9, and I know I did nothing
> special to get it to load, and I definitely had / as ext3. So either Red
> Hat
> supplied the right initrd, or I did not need a special one. I know I never
> made one, and I never compiled a kernel in those days.
>
> With Red Hat Enterprise Linux, here is the log after a reboot
>
> Jun 19 16:16:37 trillian kernel: Attached scsi disk sda at scsi0, channel
> 0,
> id 0, lun 0
> Jun 19 16:16:37 trillian kernel: Attached scsi disk sdb at scsi0, channel
> 0,
> id 1, lun 0
> Jun 19 16:16:37 trillian kernel: Attached scsi disk sdc at scsi0, channel
> 0,
> id 2, lun 0
> Jun 19 16:16:37 trillian kernel: Attached scsi disk sdd at scsi0, channel
> 0,
> id 3, lun 0
> Jun 19 16:16:37 trillian kernel: SCSI device sda: 35916548 512-byte hdwr
> sectors (18389 MB)
> Jun 19 16:16:37 trillian kernel: sda: sda1 sda2 sda3
> Jun 19 16:16:37 trillian kernel: SCSI device sdb: 35916548 512-byte hdwr
> sectors (18389 MB)
> Jun 19 16:16:37 trillian kernel: sdb: sdb1 sdb2
> Jun 19 16:16:37 trillian kernel: SCSI device sdc: 35916548 512-byte hdwr
> sectors (18389 MB)
> Jun 19 16:16:37 trillian kernel: sdc: sdc1 sdc2
> Jun 19 16:16:37 trillian kernel: SCSI device sdd: 35916548 512-byte hdwr
> sectors (18389 MB)
> Jun 19 16:16:37 trillian kernel: sdd: sdd1 sdd2
> Jun 19 16:16:37 trillian kernel: blk: queue f7a21818, I/O limit 524287Mb
> (mask 0x7fffffffff)
> Jun 19 16:16:37 trillian kernel: Vendor: EXABYTE Model: VXA-2
> Rev: 2120
> Jun 19 16:16:37 trillian kernel: Type: Sequential-Access
> ANSI SCSI revision: 02
> Jun 19 16:16:37 trillian kernel: blk: queue f7a21618, I/O limit 524287Mb
> (mask 0x7fffffffff)
> Jun 19 16:16:37 trillian kernel: Journalled Block Device driver loaded
> <---<<<
> Jun 19 16:16:37 trillian kernel: kjournald starting. Commit interval 5
> seconds
> Jun 19 16:16:37 trillian kernel: EXT3-fs: mounted filesystem with ordered
> data mode. <---<<<
>
> Now what I do not understand is that it loaded the Journalled Block Device
> Driver before it mounted the first EXT3-fs, the one that contains the root
> (/) directory where the modules are.
>
> Only much later in the file do I get:
>
> Jun 19 16:16:08 trillian rc.sysinit: Checking root filesystem succeeded
> Jun 19 16:16:08 trillian rc.sysinit: Remounting root filesystem in
> read-write mode: succeeded <---<<< but how was it mounted the first
> time?
> Jun 19 16:16:08 trillian rc.sysinit: Activating swap partitions:
> succeeded
> Jun 19 16:16:09 trillian rc.sysinit: Finding module dependencies:
> succeeded
>
> But that appears to have happened earlier. Queuing to /var/log/messages
> seems peculiar here. It appears that just before this, it reset the system
> clock, so this is really later and in proper sequence. Whew!
>
> I see, grub knows where initrd is, and it is in the /boot partition. I
> suppose these days, the initrd has the journalling module in it.
>

Hi,

Thanks for the reply. I admit that I'm going to have to read it several
times...
Haven't messed around with anything since posting the last time...
Just grep'd my /var/message files for 'remount' and 'read-write' with no
hits..

Guess it is going to take a bit of work, and reading, to figure out this
chicken and egg thing..

Thanks...

Figured out what the problem was.

I had installed new modutils, in preperation to build a 2.6~ kernel, which
were conflicting with the initrd that I built for ext3 support.

Reverting back to the old modutils got the new initrd to finally work
correctly.

With UPS and now ext3 working on everything, I'm happy as it all much more
"tolerant" now. Definetly closer to being an "appliance" than a "computer",
which was the whole intention.

Thanks...

"Jean-David Beyer" <jeandavid8@verizon.net> wrote in message
news:0irhi.890$Pv2.143@trnddc03...
> Unless I am mistaken, you can boot the kernel entirely from /boot. Once
> the
> kernel is booted and the rest of the system comes up, early in the
> process,
> / is mounted, and once that is done, the module for ext3 can be loaded.
> Now
> when that was an issue, I ran Red Hat Linux 9, and I know I did nothing
> special to get it to load, and I definitely had / as ext3. So either Red
> Hat
> supplied the right initrd, or I did not need a special one. I know I never
> made one, and I never compiled a kernel in those days.
>

Hi,

Now that I have worked it through, your post makes sense to me. I think I
can offer an explaination as to why I needed to build a new initrd as well.

This is speculation, but it appears that different initrd's are installed
during setup based upon which filesystem is selected at install. Since
ext2 was selected (years ago) during install, an initrd that didn't have
ext3 support was used. The original ext2 initrd was ~90K while the initrd
that I made with ext3 support was ~145K. Once I put the old modutils back
in, it began to load correctly. I built new modutils in preperation for
building a 2.6~ kernel, but in haste overlooked part of the installation
where you were advised to do a "make old", which copied your old modutils to
..old files. Did a force install of the old modutils, then installed the new
modutils correctly. The new initrd is now finding the .old files (which it
needs, since still using 2.4.20-6 kernel.) Was going to build a 2.6~
kernel, but now that everything is working, don't see any need to.
Security isn't a concern since nobody can get at it. Never had any problems
related to the 2.4.20 kernel. "If it aint broke, don't fix it."

None of the stuff that I do with it is critical. I've always had a fancy
for sensors and "real world" computer integration going back to Tandy TRS-80
Coco's. Just various projects here and there. Some do things that are
practical, others do things just to do them... Even though there are
ready-built gadgets and animals to do much of the same things these days, it
is just fun to do them yourself.

Thanks!