EXT2-fs error
Hi,
I keep getting the following error when trying to access files on my target system:
EXT2-fs error (device hda1): ext2_lookup: deleteed inode referenced: 31372
(the inode reference number changes depending upon what file I'm interrogating)
If I try to e2fsck /dev/hda1, I get the following warning:
/dev/hda1 is mounted.
WARNING!!! Running e2fsck on a mounted filesystem mat cause SEVERE filesystem demage.
The device is zeroed with dd before installation, which is done from a USB stick containing the image. What point is good to e2fsck (before installaion of the image or after)? How do I unmount hda1 (which is a flash drive, and the only storage device on the system), or should I just do so mounted?
Regards,
JNY
Signature · 2 lines
View this message in context: http://old.nabble.com/EXT2-fs-error-tp29591683p29591683.html Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"JNY" == JNY <[email protected]> writes:
JNY> Hi,
JNY> I keep getting the following error when trying to access files on JNY> my target system:
JNY> EXT2-fs error (device hda1): ext2_lookup: deleteed inode referenced: 31372
JNY> (the inode reference number changes depending upon what file I'm JNY> interrogating)
JNY> If I try to e2fsck /dev/hda1, I get the following warning:
JNY> /dev/hda1 is mounted.
JNY> WARNING!!! Running e2fsck on a mounted filesystem mat cause SEVERE JNY> filesystem demage.
JNY> The device is zeroed with dd before installation, which is done JNY> from a USB stick containing the image. What point is good to JNY> e2fsck (before installaion of the image or after)? How do I JNY> unmount hda1 (which is a flash drive, and the only storage device JNY> on the system), or should I just do so mounted?
Why don't you just check the image before writing (E.G. on your build machine)?
/sbin/e2fsck -f output/images/rootfs.ext2
e2fsck 1.41.9 (22-Aug-2009)
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
rootfs.ext2: 502/896 files (0.4% non-contiguous), 1453/3744 blocks
If the image is OK, then I guess your problem is either in the copying or some I/O issue on your flash disk.
Signature · 1 line
Bye, Peter Korsgaard
Why don't you just check the image before writing (E.G. on your build machine)?
/sbin/e2fsck -f output/images/rootfs.ext2
e2fsck 1.41.9 (22-Aug-2009)
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
rootfs.ext2: 502/896 files (0.4% non-contiguous), 1453/3744 blocks
If the image is OK, then I guess your problem is either in the copying or some I/O issue on your flash disk.
Signature · 27 lines
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
I don't have a file called rootfs.ext2. I have the following files:
bzImage
rootfs.i486.tar
rootfs.i486.tar.bz2
If I try to /sbin/e2fsck -f output/images/ any of those, I get:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Which is pretty much what I'd have expected, as they're mounted files. What
am I doing wrong.
--
View this message in context: http://old.nabble.com/EXT2-fs-error-tp29591683p29603102.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.Quoted 3 lines · JNY
(which is a flash
drive, and the only storage device on the system)
Out of curiosity, a USB flash device, or CF, or NAND flash, or ?
Quoted 1 line
or should I just do so mounted?
If you have to do it when the FS is mounted, you may want to remount it as read-write before you do the fsck:
mount -o remount,ro /
Then after the fsck, reboot.
Quoted 3 lines
I don't have a file called rootfs.ext2. I have the following files:
rootfs.i486.tar
rootfs.i486.tar.bz2
Which of these files are you transferring to the flash device, and how?
Mitch.
Quoted 5 lines · Mitch Davis
If you have to do it when the FS is mounted, you may want to remount it as read-write before you do the fsck:
?mount -o remount,ro /
Oops, I meant "read only", not "read-write". Sorry for the confusion.
Mitch.
Quoted 2 lines
Out of curiosity, a USB flash device, or CF, or NAND flash, or ?
Not sure about the USB stick, but the flash device (see below) on the target is NAND.
To clear up any confusion:
-USB stick is the means of transfering the image
-flash device is the target device memory
Quoted 5 lines
Quoted 3 lines
I don't have a file called rootfs.ext2. I have the following files:
rootfs.i486.tar
rootfs.i486.tar.bz2Which of these files are you transferring to the flash device, and how?
I'm transfering the bzImage file to the flash device, and referencing it with grub.
The USB stick always comes up clean when I e2fsck both partitions (even with a force -f).
Is it possible that when the file system is created by Buildroot, that it could need some kind of fsck, before it is transfered to the USB stick?
Signature · 2 lines
View this message in context: http://old.nabble.com/EXT2-fs-error-tp29591683p29641601.html Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
Quoted 5 lines · JNY
Quoted 2 lines
Out of curiosity, a USB flash device, or CF, or NAND flash, or ?
Not sure about the USB stick, but the flash device (see below) on the target is NAND.
Ok. And is this the same device you referred to as "hda"?
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
I don't have a file called rootfs.ext2. ?I have the following files:
rootfs.i486.tar
rootfs.i486.tar.bz2Which of these files are you transferring to the flash device, and how?
I'm transfering the bzImage file to the flash device, and referencing it with grub.
bzImage is the kernel file, and I didn't ask you about it. I'm asking about your filesystem.
The rootfs files contain your root filesystem. Can you tell us clearly what you're doing to set up the root filesystem on your device?
Mitch.
Quoted 5 lines
bzImage is the kernel file, and I didn't ask you about it. I'm asking about your filesystem.
The rootfs files contain your root filesystem. Can you tell us clearly
what you're doing to set up the root filesystem on
Quoted 1 line
your device?
Apologies. I use the following script (see below) to install the filesystem 'rootfs.i486.tar.bz2' and the kernel image 'bzImage'.
This script is called from /boot/grub/menu.lst on the USB stick.
echo Setting up main drive...
echo "d
n
p
1
a
1
w
" | /sbin/fdisk /dev/hda/usr/sbin/mkfs.ext2 /dev/hda1
echo Mounting drive and populating... /bin/mount /dev/sda2 /mnt/bin/mount /dev/hda1 /mnt/disk
rm -rf /mnt/disk/*/bin/tar -C /mnt/disk/ -xvf /mnt/rootfs.i486.tar.bz2 mkdir /mnt/disk/var/log/lighttpd
cp /mnt/grub/menu.lst /mnt/disk/boot/grub/ cp -av /mnt/home/* /mnt/disk/home/
cp -av /mnt/etc/inittab /mnt/disk/etc/
cp -av /mnt/etc/lighttpd /mnt/disk/etc/
cp -av /mnt/etc/network/* /mnt/disk/etc/network/ cp -av /mnt/etc/init.d/* /mnt/disk/etc/init.d/ cp -av /mnt/var/www /mnt/disk/var/
#umount /dev/hda1
echo "root (hd0,0)
setup (hd0)
quit
" | /sbin/grub
echo
echo Installation Finished. Please Reboot.
echo =====================================/bin/sleep 8000
Signature · 2 lines
View this message in context: http://old.nabble.com/EXT2-fs-error-tp29591683p29641651.html Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
Quoted 48 lines
Quoted 6 lines
bzImage is the kernel file, and I didn't ask you about it. I'm asking about your filesystem.
The rootfs files contain your root filesystem. Can you tell us clearly
what you're doing to set up the root filesystem on
Quoted 1 line
your device?
Apologies. I use the following script (see below) to install the filesystem 'rootfs.i486.tar.bz2' and the kernel image 'bzImage'.
This script is called from/boot/grub/menu.lston the USB stick.echo Setting up main drive...
echo "d
n
p
1a
1
w
" |/sbin/fdisk/dev/hda/usr/sbin/mkfs.ext2/dev/hda1echo Mounting drive and populating...
/bin/mount/dev/sda2/mnt/bin/mount/dev/hda1/mnt/disk
rm -rf/mnt/disk/*/bin/tar-C/mnt/disk/-xvf/mnt/rootfs.i486.tar.bz2mkdir/mnt/disk/var/log/lighttpd
cp/mnt/grub/menu.lst/mnt/disk/boot/grub/cp -av/mnt/home/*/mnt/disk/home/
cp -av/mnt/etc/inittab/mnt/disk/etc/
cp -av/mnt/etc/lighttpd/mnt/disk/etc/
cp -av/mnt/etc/network/*/mnt/disk/etc/network/cp -av/mnt/etc/init.d/*/mnt/disk/etc/init.d/cp -av/mnt/var/www/mnt/disk/var/
#umount/dev/hda1echo "root (hd0,0)
setup (hd0)
quit
" |/sbin/grub
Quoted 12 lines
echo
echo Installation Finished. Please Reboot.
echo =====================================/bin/sleep8000Signature · 7 lines
View this message in context: http://old.nabble.com/EXT2-fs-error-tp29591683p29641651.html Sent from the Buildroot (busybox) mailing list archive at Nabble.com. _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100909/27bf5f23/attachment.html>
Further to this problem:
I tried following advice recieved earlier in this thread (to check it on the build machine), and get the following output.
rootfs.i486.tar.bz2 was generated by Buildroot. I didn't think e2fsck could be used in this way, and that may be why this error is thrown, but if this is a valid operation, what could cause it?
[root at localhost images]# /sbin/e2fsck -f rootfs.i486.tar.bz2
e2fsck 1.41.9 (22-Aug-2009)/sbin/e2fsck: Superblock invalid, trying backup blocks.../sbin/e2fsck: Bad magic number in super-block while trying to open rootfs.i486.tar.bz2
The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
From: [email protected]
To: buildroot at busybox.net
Date: Thu, 9 Sep 2010 12:35:17 +0000
Subject: Re: [Buildroot] EXT2-fs error
Quoted 46 lines
Quoted 4 lines
bzImage is the kernel file, and I didn't ask you about it. I'm asking about your filesystem.
The rootfs files contain your root filesystem. Can you tell us clearly
what you're doing to set up the root filesystem on
Quoted 1 line
your device?
Apologies. I use the following script (see below) to install the filesystem 'rootfs.i486.tar.bz2' and the kernel image 'bzImage'.
This script is called from/boot/grub/menu.lston the USB stick.echo Setting up main drive...
echo "d
n
p
1a
1
w
" |/sbin/fdisk/dev/hda/usr/sbin/mkfs.ext2/dev/hda1echo Mounting drive and populating...
/bin/mount/dev/sda2/mnt/bin/mount/dev/hda1/mnt/disk
rm -rf/mnt/disk/*/bin/tar-C/mnt/disk/-xvf/mnt/rootfs.i486.tar.bz2mkdir/mnt/disk/var/log/lighttpd
cp/mnt/grub/menu.lst/mnt/disk/boot/grub/cp -av/mnt/home/*/mnt/disk/home/
cp -av/mnt/etc/inittab/mnt/disk/etc/
cp -av/mnt/etc/lighttpd/mnt/disk/etc/
cp -av/mnt/etc/network/*/mnt/disk/etc/network/cp -av/mnt/etc/init.d/*/mnt/disk/etc/init.d/cp -av/mnt/var/www/mnt/disk/var/
#umount/dev/hda1echo "root (hd0,0)
setup (hd0)
quit
" |/sbin/grub
Quoted 12 lines
echo
echo Installation Finished. Please Reboot.
echo =====================================/bin/sleep8000Signature · 7 lines
View this message in context: http://old.nabble.com/EXT2-fs-error-tp29591683p29641651.html Sent from the Buildroot (busybox) mailing list archive at Nabble.com. _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100910/a1ced494/attachment.html>
If I try the following script during installation, I get an mtab error when I try to run e2fsck:
echo Setting up main drive...
echo "d
n
p
1
a
1
w
" | /sbin/fdisk /dev/hda/usr/sbin/mkfs.ext2 /dev/hda1
echo Mounting drive and building fs...
echo =================================== /bin/mount /dev/sda2 /mnt/bin/mount /dev/hda1 /mnt/disk
rm -rf /mnt/disk/*/bin/tar -C /mnt/disk/ -xvf /mnt/rootfs.i486.tar.bz2
echo Unmounting drive and e2fsck ing it...
echo ===================================/bin/umount /dev/hda1/usr/sbin/e2fsck /dev/hda1
echo Remounting drive...
echo ===================================/bin/mount /dev/hda1 /mnt/disk
echo Populating drive...
echo ===================================
#this then continues to do all the other copying stuff
From: [email protected]
To: buildroot at busybox.net
Date: Fri, 10 Sep 2010 15:41:06 +0000
Subject: Re: [Buildroot] EXT2-fs error
Further to this problem:
I tried following advice recieved earlier in this thread (to check it on the build machine), and get the following output.
rootfs.i486.tar.bz2 was generated by Buildroot. I didn't think e2fsck could be used in this way, and that may be why this error is thrown, but if this is a valid operation, what could cause it?
[root at localhost images]# /sbin/e2fsck -f rootfs.i486.tar.bz2
e2fsck 1.41.9 (22-Aug-2009)/sbin/e2fsck: Superblock invalid, trying backup blocks.../sbin/e2fsck: Bad magic number in super-block while trying to open rootfs.i486.tar.bz2
The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
From: [email protected]
To: buildroot at busybox.net
Date: Thu, 9 Sep 2010 12:35:17 +0000
Subject: Re: [Buildroot] EXT2-fs error
Quoted 46 lines
Quoted 4 lines
bzImage is the kernel file, and I didn't ask you about it. I'm asking about your filesystem.
The rootfs files contain your root filesystem. Can you tell us clearly
what you're doing to set up the root filesystem on
Quoted 1 line
your device?
Apologies. I use the following script (see below) to install the filesystem 'rootfs.i486.tar.bz2' and the kernel image 'bzImage'.
This script is called from/boot/grub/menu.lston the USB stick.echo Setting up main drive...
echo "d
n
p
1a
1
w
" |/sbin/fdisk/dev/hda/usr/sbin/mkfs.ext2/dev/hda1echo Mounting drive and populating...
/bin/mount/dev/sda2/mnt/bin/mount/dev/hda1/mnt/disk
rm -rf/mnt/disk/*/bin/tar-C/mnt/disk/-xvf/mnt/rootfs.i486.tar.bz2mkdir/mnt/disk/var/log/lighttpd
cp/mnt/grub/menu.lst/mnt/disk/boot/grub/cp -av/mnt/home/*/mnt/disk/home/
cp -av/mnt/etc/inittab/mnt/disk/etc/
cp -av/mnt/etc/lighttpd/mnt/disk/etc/
cp -av/mnt/etc/network/*/mnt/disk/etc/network/cp -av/mnt/etc/init.d/*/mnt/disk/etc/init.d/cp -av/mnt/var/www/mnt/disk/var/
#umount/dev/hda1echo "root (hd0,0)
setup (hd0)
quit
" |/sbin/grub
Quoted 12 lines
echo
echo Installation Finished. Please Reboot.
echo =====================================/bin/sleep8000Signature · 7 lines
View this message in context: http://old.nabble.com/EXT2-fs-error-tp29591683p29641651.html Sent from the Buildroot (busybox) mailing list archive at Nabble.com. _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100910/57d16ccb/attachment-0001.html>
Johny, All,
Quoted 4 lines · On Friday 10 September 2010 17:41:06 Johnny Beardsmore wrote:
I tried following advice recieved earlier in this thread (to check it on the build machine), and get the following output.
rootfs.i486.tar.bz2 was generated by Buildroot.
Hey! rootfs.i486.tar.bz2 is not an ext2 image. It's a tarball !
Quoted 2 lines
I didn't think e2fsck
could be used in this way,
Yes, it can be used on file system images.
I guess you want to properly setup buildroot to generate an ext2 file system in place of (or along with) a tarball.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
Hello all,
OK. I've tried the following, and still no joy.
1) e2fsck the rootfs file on the build machine. This creates an error thus:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
2) After installation, logon from a rescue usb stick, umount the hda, and e2fsck it. This works (no EXT2 warning on first boot-up), but there is a warning on subsequent boot-ups, regardless of the reboot method.
3) Running e2fsck during installation, by inserting umount (where necessary), and e2fsck entries in the installation script. This has created a number of different errors, but no working solution.
I'm of the opinion that the problem is with the rootfs which is generated by Buildroot. The suggestion to check it on the build machine seemed very promising, and was along the lines of what I thought I should be doing, but I haven't had any success with it so far. This is driven by the way I can check the hda from the rescue USB, and go no warnings, but then when it's re-booted the warning returns.
This seems to have dragged on for some time (mostly because I've not been focussing on this problem). If anyone has any ideas I'd be grateful for them.
From: [email protected]
To: buildroot at busybox.net
Date: Thu, 9 Sep 2010 12:35:17 +0000
Subject: Re: [Buildroot] EXT2-fs error
Quoted 46 lines
Quoted 4 lines
bzImage is the kernel file, and I didn't ask you about it. I'm asking about your filesystem.
The rootfs files contain your root filesystem. Can you tell us clearly
what you're doing to set up the root filesystem on
Quoted 1 line
your device?
Apologies. I use the following script (see below) to install the filesystem 'rootfs.i486.tar.bz2' and the kernel image 'bzImage'.
This script is called from/boot/grub/menu.lston the USB stick.echo Setting up main drive...
echo "d
n
p
1a
1
w
" |/sbin/fdisk/dev/hda/usr/sbin/mkfs.ext2/dev/hda1echo Mounting drive and populating...
/bin/mount/dev/sda2/mnt/bin/mount/dev/hda1/mnt/disk
rm -rf/mnt/disk/*/bin/tar-C/mnt/disk/-xvf/mnt/rootfs.i486.tar.bz2mkdir/mnt/disk/var/log/lighttpd
cp/mnt/grub/menu.lst/mnt/disk/boot/grub/cp -av/mnt/home/*/mnt/disk/home/
cp -av/mnt/etc/inittab/mnt/disk/etc/
cp -av/mnt/etc/lighttpd/mnt/disk/etc/
cp -av/mnt/etc/network/*/mnt/disk/etc/network/cp -av/mnt/etc/init.d/*/mnt/disk/etc/init.d/cp -av/mnt/var/www/mnt/disk/var/
#umount/dev/hda1echo "root (hd0,0)
setup (hd0)
quit
" |/sbin/grub
Quoted 12 lines
echo
echo Installation Finished. Please Reboot.
echo =====================================/bin/sleep8000Signature · 7 lines
View this message in context: http://old.nabble.com/EXT2-fs-error-tp29591683p29641651.html Sent from the Buildroot (busybox) mailing list archive at Nabble.com. _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100913/3f6c7941/attachment-0001.html>
Hello,
Quoted 1 line · On Mon, 13 Sep 2010 07:51:55 +0000 Johnny Beardsmore <[email protected]> wrote:
1) e2fsck the rootfs file on the build machine. This creates an error thus:
Yann Morin has already told you that you are trying to run e2fsck on a tarball. A tarball is not an ext2 image, so obviously it cannot work.
What you're doing is exactly as if your trying to run an image verification program on a text document. It doesn't work because it makes no sense to try it in the first place.
Regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
My understanding of running e2fsck is that it should only be done on an unmounted file system (or setting to read-only, but I've never actually done this). I've only ever run it on hda (usually a hard disk or flash drive) or sda (usually a usb stick) after a umount. For me to e2fsck on the build machine means that I'm applying it to files on a mounted file system, not a complete unmounted drive. This is where I'm getting confused.
I'm obviously lacking some fundermental understanding of what e2fsck does. I know to run it when advised to after repartitionning (entire) drives with fdisk, and if I don't then sooner or later, inode errors start popping up, and data gets lost. I'm getting the advisory on start-up and as I'd expect, I'm getting inode errors on occasion. What I can't seem to do is use the fix I'd normally apply.
Quoted 15 lines
Date: Mon, 13 Sep 2010 10:20:31 +0200
From: thomas.petazzoni at free-electrons.com
To: buildroot at busybox.net
Subject: Re: [Buildroot] EXT2-fs errorHello,
Quoted 1 line · On Mon, 13 Sep 2010 07:51:55 +0000 Johnny Beardsmore <[email protected]> wrote:
1) e2fsck the rootfs file on the build machine. This creates an error thus:
Yann Morin has already told you that you are trying to run e2fsck on a tarball. A tarball is not an ext2 image, so obviously it cannot work.
Quoted 16 lines
What you're doing is exactly as if your trying to run an image verification program on a text document. It doesn't work because it makes no sense to try it in the first place.
Regards,
Thomas
Signature · 8 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100913/dc32184d/attachment.html>
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Johnny" == Johnny Beardsmore <[email protected]> writes:
Johnny> My understanding of running e2fsck is that it should only be Johnny> done on an unmounted file system (or setting to read-only, but Johnny> I've never actually done this). I've only ever run it on hda Johnny> (usually a hard disk or flash drive) or sda (usually a usb Johnny> stick) after a umount. For me to e2fsck on the build machine Johnny> means that I'm applying it to files on a mounted file system, Johnny> not a complete unmounted drive. This is where I'm getting Johnny> confused.
Here it works:
tar jxf buildroot-2010.08.tar.bz2
cd buildroot-2010.08
make menuconfig (don't change anything, exit and save) make/sbin/e2fsck -f output/images/rootfs.ext2 e2fsck 1.41.9 (22-Aug-2009)
Filesystem did not have a UUID; generating one.
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
output/images/rootfs.ext2: ***** FILE SYSTEM WAS MODIFIED ***** output/images/rootfs.ext2: 504/896 files (0.4% non-contiguous), 1268/3568 blocks
Signature · 1 line
Bye, Peter Korsgaard
Quoted 11 lines
Here it works:
tar jxf buildroot-2010.08.tar.bz2
cd buildroot-2010.08
make menuconfig (don't change anything, exit and save) make/sbin/e2fsck-f output/images/rootfs.ext2 e2fsck 1.41.9 (22-Aug-2009)
Filesystem did not have a UUID; generating one.
Quoted 11 lines
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 informationoutput/images/rootfs.ext2: ***** FILE SYSTEM WAS MODIFIED ***** output/images/rootfs.ext2: 504/896 files (0.4% non-contiguous), 1268/3568 blocks
Signature · 1 line
Bye, Peter Korsgaard
Hi,
I don't have a rootfs.ext2 in my output/images/. I have rootfs.i486.tar and rootfs.i486.tar.bz2. After un-taring these, I get /usr/sbin/mkfs.ext2 and /usr/sbin/fsck.ext2. What could I be doing differently? Regards,
JNY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100915/a6663ec5/attachment-0001.html>
Quoted 4 lines · On Wed, 15 Sep 2010 11:07:51 +0000 Johnny Beardsmore <[email protected]> wrote:
I don't have a rootfs.ext2 in my output/images/. I have rootfs.i486.tar and rootfs.i486.tar.bz2. After un-taring these, I get
/usr/sbin/mkfs.ext2and/usr/sbin/fsck.ext2. What could I be doing differently? Regards, JNY
You have mistakenly unselected the generation of an ext2 image in "Target filesystem options". The generation of an ext2 image is enabled by default when you start a fresh configuration, so if it's not enabled, it's because you have unselected it somehow.
Regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 5 lines
You have mistakenly unselected the generation of an ext2 image in "Target filesystem options". The generation of an ext2 image is enabled by default when you start a fresh configuration, so if it's not enabled, it's because you have unselected it somehow.
What does creating this file allow me to do (other than apply the previously mentioned e2fsck to it)? I assume I'll still be transfering all the same stuff to the target, but do I also include this file, and if so, where should it be located?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100915/15b5c84e/attachment.html>
Am Mittwoch, 15. September 2010, 14:39:37 schrieb Johnny Beardsmore:
Quoted 9 lines
Quoted 4 lines
You have mistakenly unselected the generation of an ext2 image in "Target filesystem options". The generation of an ext2 image is enabled by default when you start a fresh configuration, so if it's not enabled, it's because you have unselected it somehow.
What does creating this file allow me to do (other than apply the previously mentioned e2fsck to it)? I assume I'll still be transfering all the same stuff to the target, but do I also include this file, and if so, where should it be located?
It's an EXT2 image file. i.e. this file contains a perfect bitwise copy of what belongs on your device to get your rootfs. Just like a hard disk/floppy/CD image. You can dd if=rootfs.ext2 of=yourtargetdevicenode to transfer it. Of course that will delete any pre-existing files from the target device so watch out. What to put in place of yourtargetdevicenode depends on how you're accessing your target's storage device.
Cheers,
Malte
Hello Johny,
Quoted 4 lines · On Wed, 15 Sep 2010 12:39:37 +0000 Johnny Beardsmore <[email protected]> wrote:
What does creating this file allow me to do (other than apply the previously mentioned e2fsck to it)? I assume I'll still be transfering all the same stuff to the target, but do I also include this file, and if so, where should it be located?
This file is the image of an ext2 filesystem, so you can just copy it raw to a USB key or the partition of a USB key, and then just mount the USB key. See
I don't want to be/seem rude, but it seems you lack some really basic embedded Linux knowledge. May I suggest to order and read a book such as Building Embedded Linux Systems [1] ?
That would really help you understanding what is going on.
Also you are not explaining what you are trying to achieve *in the end*. It might be that generating an ext2 filesystem image is totally useless for what you're trying to do.
Regards,
Thomas
[1] http://oreilly.com/catalog/9780596529680
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 10 lines
I don't want to be/seem rude, but it seems you lack some really basic embedded Linux knowledge. May I suggest to order and read a book such as Building Embedded Linux Systems [1] ?
That would really help you understanding what is going on.
Also you are not explaining what you are trying to achieve *in the end*. It might be that generating an ext2 filesystem image is totally useless for what you're trying to do.
No offence taken. Reading such a book several months ago would have been a very prudent move. This is perhaps a bit late now, since in the next couple of weeks I hope to have finished this project. Most of my previous embedded experience didn't involve an operating system (mostly c onto AVRs via AVRstudio). I would like to thank everyone now for all the assistance I've recieved with this and the other problems I've encountered.
What I'm doing is using Buildroot to create an embedded OS for a small computing device (a pc-104). I have some code which then runs on the device and acts as a data collection/analysis system. Un-taring the rootfs.i486.tar.bz onto the flashdrive of the device using grub has worked for me (with the exception of the problem I'm experiencing), and the whole procedure has been built around this (most of this has been achieved by trial-and-error, and assistance from forums). I'd really like to avoid changing things to use the ext2 image file if possible and continue using the .tar.bz file. The problem is I keep loosing frequently accessed files, which is (I bilieve) due to me mounting a file system which hasn't been checked. I get a warning about the fs on boot, and inode errors when I try to acces a file which has been struck.
I believe this is quite a simple problem to fix - I just can't figure this one out. I believe I need (some how) to check the file system on either the build machine, and/or the target. If it is done on the target I may need to do this periodically/on-boot (due to the high number of unclean shut-down the device is likely to experience). Hopefully this is enough detail, but I'm pulling my hair out with this, so will willingly forward anything further which may assist. Thanks again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100916/e800bb05/attachment.html>
Quoted 10 lines
I don't want to be/seem rude, but it seems you lack some really basic embedded Linux knowledge. May I suggest to order and read a book such as Building Embedded Linux Systems [1] ?
That would really help you understanding what is going on.
Also you are not explaining what you are trying to achieve *in the end*. It might be that generating an ext2 filesystem image is totally useless for what you're trying to do.
No offence taken. Reading such a book several months ago would have been a very prudent move. This is perhaps a bit late now, since in the next couple of weeks I hope to have finished this project. Most of my previous embedded experience didn't involve an operating system (mostly c onto AVRs via AVRstudio). I would like to thank everyone now for all the assistance I've recieved with this and the other problems I've encountered.
What I'm doing is using Buildroot to create an embedded OS for a small computing device (a pc-104). I have some code which then runs on the device and acts as a data collection/analysis system. Un-taring the rootfs.i486.tar.bz onto the flashdrive of the device using grub has worked for me (with the exception of the problem I'm experiencing), and the whole procedure has been built around this (most of this has been achieved by trial-and-error, and assistance from forums). I'd really like to avoid changing things to use the ext2 image file if possible and continue using the .tar.bz file. The problem is I keep loosing frequently accessed files, which is (I bilieve) due to me mounting a file system which hasn't been checked. I get a warning about the fs on boot, and inode errors when I try to acces a file which has been struck.
I believe this is quite a simple problem to fix - I just can't figure this one out. I believe I need (some how) to check the file system on either the build machine, and/or the target. If it is done on the target I may need to do this periodically/on-boot (due to the high number of unclean shut-down the device is likely to experience). Hopefully this is enough detail, but I'm pulling my hair out with this, so will willingly forward anything further which may assist. Thanks again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100916/1358c0d9/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100916/1358c0d9/attachment.ksh>
Quoted 3 lines · Johnny Beardsmore
What I'm doing is using Buildroot to create an embedded OS for a small computing device (a pc-104). I have some code which then runs on the device and acts as a data collection/analysis system.
I have built a similar system to yours.
Quoted 3 lines
Un-taring the rootfs.i486.tar.bz onto the flashdrive of the device using grub has worked for me (with the exception of the problem I'm experiencing),
The confusion starts here. Where is the "rootfs.i486.tar.bz" and why are you un-taring it unto a flash drive?
In my system I use Syslinux to load the kernel, bzImage, into ram and then gunzip the file-system also into ram. Syslinux then passes some command line argument to linux and the system starts.
Where does the rootfs.i486.tar.bz file come from? Do you create it manually? or is it the output of buildroot? The file-system image I get from buildroot is called rootfs.i486.ext2.gz, no tar.
Quoted 8 lines
and the whole procedure has been built around this (most of this has been achieved by trial-and-error, and assistance from forums). I'd really like to avoid changing things to use the ext2 image file if possible and continue using the .tar.bz file. The problem is I keep loosing frequently accessed files, which is (I bilieve) due to me mounting a file system which hasn't been checked. I get a warning about the fs on boot, and inode errors when I try to acces a file which has been struck.
Do you have the flash drive mounted as you root file system? You maybe wearing out the flash thus loosing the those frequently accessed files. My flash drive (CF card) is mounted read-only and when certain events occur or a timeout in my application, the flash drive is remounted read-write, the data is written and then the flash drive is remounted read-only, in over three years and 23 system I haven?t lost any data.
Quoted 5 lines
I believe this is quite a simple problem to fix - I just can't figure this one out. I believe I need (some how) to check the file system on either the build machine, and/or the target. If it is done on the target I may need to do this periodically/on-boot (due to the high number of unclean shut-down the device is likely to experience).
I don't think doing in fsck on boot is going to help you, your files are getting corrupted on the unclean shut-downs fsck isn't going to be able to repair them.
Quoted 2 lines
Hopefully this is enough detail, but I'm pulling my hair out with
this, so will willingly forward anything further which may assist.
If you can clarify the confusion noted above maybe I can help.
Signature · 2 lines
Ormund Williams OrmLab LLC
Quoted 7 lines
Quoted 5 lines
Un-taring the rootfs.i486.tar.bz onto the flashdrive of the device using grub has worked for me (with the exception of the problem I'm experiencing),
The confusion starts here. Where is the "rootfs.i486.tar.bz" and why are you un-taring it unto a flash drive?
Sorry, I meant rootfs.i486.tar.bz2. The flash drive is the nv memory for the pc-104. I do so with the following script (see below). This is called from /boot/grub/menu.lst, and is located in /home/reflash.sh. The whole loading process is contained in a USB memory stick over two partitions (one with the MBR). It's done like this to make it easy for anyone to be able to load up the pc-104. They just plug in the stick, and turn it on.
echo "" | /sbin/fdisk /dev/hda/usr/sbin/mkfs.ext2 /dev/hda1
/bin/mount /dev/sda2 /mnt/bin/mount /dev/hda1 /mnt/disk
rm -rf /mnt/disk/*/bin/tar -C /mnt/disk/ -xvf /mnt/rootfs.i486.tar.bz2
mkdir /mnt/disk/var/log/lighttpd
cp /mnt/grub/menu.lst /mnt/disk/boot/grub/ cp -av /mnt/home/* /mnt/disk/home/
cp -av /mnt/etc/inittab /mnt/disk/etc/ cp -av /mnt/etc/lighttpd /mnt/disk/etc/ cp -av /mnt/etc/network/* /mnt/disk/etc/network/ cp -av /mnt/etc/init.d/* /mnt/disk/etc/init.d/ cp -av /mnt/var/www /mnt/disk/var/
echo "root (hd0,0)
setup (hd0)
quit
" | /sbin/grub
echo "Done"
Quoted 3 lines
Where does the rootfs.i486.tar.bz file come from? Do you create it manually? or is it the output of buildroot? The file-system image I get from buildroot is called rootfs.i486.ext2.gz, no tar.
rootfs.i486.tar.bz2 comes from Buildroot. It's in /output/staging along with the bzImage.
Quoted 6 lines
Do you have the flash drive mounted as you root file system? You maybe wearing out the flash thus loosing the those frequently accessed files. My flash drive (CF card) is mounted read-only and when certain events occur or a timeout in my application, the flash drive is remounted read-write, the data is written and then the flash drive is remounted read-only, in over three years and 23 system I haven?t lost any data.
There is a physical switch on the flash drive which is set to read/write (options are r/w and WP (write protect)). There's another switch (master / slave) which is set to master.
Quoted 3 lines
I don't think doing in fsck on boot is going to help you, your files are getting corrupted on the unclean shut-downs fsck isn't going to be able to repair them.
Perhaps I should force a clean shutdown? I might be barking up the wrong tree. I get the e2fsck warning on boot, and loose data. I assumed the two were connected. I've never experienced systematic hardware failure (unless it's a problem with a batch), so I assumed my code/engineering was at fault.
Quoted 1 line
If you can clarify the confusion noted above maybe I can help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100916/30d149e3/attachment.html>
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines
Quoted 4 lines
I do so with the following script (see below). This is called from
/boot/grub/menu.lst, and is located in/home/reflash.sh.I'm quite puzzled how GRUB can run a shell script...
I do it like this:
title Installation Procedure
#root (hd1,0)
kernel /boot/bzImage root=/dev/sda1 panic=5 slowusb rootdelay=10 init=/home/reflash.sh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100916/d9066002/attachment.html>
Quoted 9 lines · Johnny Beardsmore
Quoted 2 lines
I'm quite puzzled how GRUB can run a shell script...
I do it like this:
title Installation Procedure
#root (hd1,0)
kernel/boot/bzImageroot=/dev/sda1 panic=5 slowusb rootdelay=10 init=/home/reflash.sh
I see the connection now, but if it helps your comprehension, GRUB is long gone by the time the script starts. Grub loads the kernel and passes control, then the kernel mounts /dev/sda1, then calls /home/reflash.sh.
M.
A message that is not in the archive (sent off-list or not yet received): 233D327176C4471A9A40B36BC1B4EB35@AP366
Quoted 8 lines
It is fine to leave the flash drive switch as r/w but the device with buildroot rootfs on is best mounted ro so that, should power be removed, the ext2 filesystem is not open to corruption. If you need to write to the flash drive I would suggest that you partition it so that the partition with buildroot rootfs is mounted ro and the other partition is mounted r/w. Then you may risk corruption of the r/w partition but not the OS.
Quoted 5 lines
The fact you get a warning on boot is because when you
mount the drive it would seem it is having problems because the ext2 filesystem is corrupted in some way. This corruption could have occurred some time before it was booted, who knows when, but most likely when powered off while writing to the disk. Hence the whole ro bit above.
I'm definitely only working with one rw partition. It seems the two partition idea would be my best way forward at this stage. I'll figure this out and see it it resolves my problem.
Thanks again everyone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100916/20c186bb/attachment.html>
Quoted 3 lines · Johnny Beardsmore
I'm definitely only working with one rw partition.? It seems the two partition idea would be my best way forward at this stage.? I'll figure this out and see it it resolves my problem.
You could ask GRUB to load a RAM disk. The programs in the RAM disk could do the image copying to the flash FS. After the copy, the flash FS can be mounted, and a "pivot" done across to it. Then the RAM disk could be thrown away.
Just a thought...
Mitch.