# rpm -qf /sbin/mk_initrd aaa_base-2001.10.19-1 # rpm -qi aaa_base --changelog <snip other info> SuSE series: a * Fri Oct 19 2001 - ro@suse.de - added call for SuSEfirewall2 in ip-up script (#11638) - updated mk_initrd for ext3 support - added rc.config variable DISPLAYMANAGER_REMOTE_ACCESS - fixed chroot for gpg in postinstall - removed suid bits for cdrecord permissions.{paranoid,secure} - added artswrapper to permission, suid in easy only - turned off cdspell default for bash As you can see the changelog does mention ext3 fix. Purple Shirt wrote:

Hello,

so I been using SuSE 7.3's ext3 abilities. No complains there but I had my worries when I did an occasional reboot that a machine still fscked. I wondered "Are my machines using ext3 or am I just thinking they are using ext3?"

So I come across a thread on another list (slug.org.au) where a RH user also discovered he thought he was using ext3 but he actually wasn't.

So my first comment would be that I installed my machines from scratch and did make 100% sure they are formatted and mounted as ext3. But then I see this:

Machine 1:

mail:~ # cat /proc/mounts /dev/root / ext2 rw 0 0 proc /proc proc rw 0 0 devpts /dev/pts devpts rw 0 0 /dev/hdc1 /home ext3 rw 0 0 shmfs /dev/shm shm rw 0 0

mail:~ # cat /etc/fstab /dev/hda1 / ext3 defaults 1 1 /dev/hdc1 /home ext3 defaults 1 2 /dev/fd0 /media/floppy auto noauto,user 0 0 proc /proc proc defaults 0 0 /dev/hda2 swap swap defaults 0 0 /dev/hda3 swap swap defaults 0 0

root file system is ext2 even though during install it was chosen to be ext3. This was a failure by SuSE. /home drive is ext3 and was installed(formatted) as such after the system was running by manually running yast2 configuration as root. This one was correctly done by SuSE.

Machine 2:

nt:~ # cat /proc/mounts /dev/root / ext2 rw 0 0 proc /proc proc rw 0 0 devpts /dev/pts devpts rw 0 0 /dev/hdb1 /usr/local/ftp/pub ext2 rw 0 0 shmfs /dev/shm shm rw 0 0 192.168.1.1:/home /home nfs rw,v2,rsize=8192,wsize=8192,hard,udp,lock,addr=192.168.1.1 0 0 /dev/hdb1 /data ext2 rw 0 0

nt:~ # cat /etc/fstab /dev/hda2 swap swap defaults 0 0 /dev/hda3 swap swap defaults 0 0 /dev/hdb3 swap swap defaults 0 0 /dev/hdb4 swap swap defaults 0 0 /dev/hda1 / ext3 defaults 1 1 /dev/hdb1 /usr/local/ftp/pub ext2 defaults 1 2 /dev/hdc /media/cdrom auto ro,noauto,user,exec 0 0 /dev/hdd /media/cdrw auto ro,noauto,user,exec 0 0 /dev/fd0 /media/floppy auto noauto,user 0 0 proc /proc proc defaults 0 0

root file system is ext2 even though during install it was chosen to be ext3. This was a failure by SuSE. /usr/local/ftp/pub is suppose to be ext2 as it is an old file system I keep around. No problem with this.

So I figure something is wrong with the SuSE install. Why if I chose a ext3 root filesystem in yast1/2 does it switch over to ext2? Does this have anything to do with ext3 as root file system and the "updated" mkinitrd script?

My point about mk_initrd script:

SuSE released CD version 7.3 and it contained a flaw not allowing somebody to use ext3 as the root file system. The flaw is described here:

http://sdb.suse.de/en/sdb/html/ext3_rootfs_73.html

The writeup was released on Nov 2 after the CD version was released. My first problem is SuSE didn't release a package update. I find a file system problem to be a major problem but SuSE only feels that they write up a little note on the web and it will have to do.

Ok so the write up points us to an updated mk_initrd script. I go over to that script but DO NOT find any mention inside the script ChangeLog that this ext3 bug has been fixed. How am I suppose to trust this script any more than the one I got on my machine that it does a better job if the ChangeLog doesn't even mention it fixes this bug?

Ok so I try to overlook that as well and I read the ChangeLog and the last change was made on September 13 which is BEFORE SuSE 7.3 was released. So how to heck does this script fix a problem which was unknown until Nov 2 if its last change was made on September 13? Can we do time travel now?

Another problem I have is that I use SuSE 7.3 FTP which was released on Nov 14. Nov 14 comes after Nov 2 where the ext3 bug was acknowledged. So my brain swaps like crazy wondering if the FTP version has the fix up in it or not. A sensible person might figure they got the fix up in the FTP version since it came after the bug was acknowledged("fixed"). Another might figure the bug is still there since there wasn't enough time to make that change. But how do you know?

So my last resort is to download that alleged new mk_initrd from Sep 3 and do a diff.

(suse 7.3 ftp mk_initrd versus the web mk_initrd)

diff /sbin/mk_initrd /root/mk_initrd

175c175,176 < [ "$arch" = ppc ] && kernels_default="vmlinux" ---

...

[ "$arch" = ia64 ] && kernels_default="vmlinuz vmlinuz.suse" [ "$arch" = ppc ] && kernels_default="vmlinux vmlinux.suse" 180c181 < [ "$arch" = ppc ] && initrds_default="initrd"

---

...

[ "$arch" = ia64 -o "$arch" = ppc -o "$arch" = alpha ] && initrds_default="initrd initrd.suse" 233d233 < [ "x$splash" = xauto -a ! -f /etc/lilo.conf ] && splash= 281,285d280 < # ppc magic: kernel can be either vmlinux or vmlinuz < if [ "$arch" = ppc -a "$kernels_default" = vmlinux ] ; then < [ ! -f "$boot_dir/vmlinux" ] && kernels_default="vmlinuz" < fi < 489a485,490

cp -a $root_dir/bin/{rm,mkdir} $tmp_mnt/bin cp -a $root_dir/bin/ls $tmp_mnt/bin cp -a $root_dir/usr/bin/lsof $tmp_mnt/bin cp -a $root_dir/sbin/pivot_root $tmp_mnt/bin mkdir -p $tmp_mnt/mnt

Hmmm, no mention of a ext3 change. So in the end I as a user sit here wonder what my mk_initrd script does and what the one from Sep 3 does better wich supposedly is newer than the one I use(from nov 14)....but how can they differ if they are both version 1.21 (according to their ChangeLog)?

So we have different mk_initrd scripts with same version numbers but different contents and I think I am using ext3 but I am not and I wish somebody told me what is going on because I have no clue how to proceed on these issues....

Marcel

-- Nadeem Hasan nhasan@nadmm.com http://www.nadmm.com/