[arch-releng] squash FS error sometimes on ISOs
Hi, if i build local ISOs here on my machine (x86_64) i sometimes could not boot the ISOs cause the generated squashfs files are corrupted. When building the ISO again it works. I have checked my RAM for several hours without a problem... Have you noticed such errors also on ISO building? The errors: http://users.archlinux.de/~gerbra/tmp/1.png http://users.archlinux.de/~gerbra/tmp/2.png If we may have a problem with mksquashfs then we have to recheck all images we build. On sigurd this would be mainly the final images, we have to downlaod them all and test if they boot fine before make the release... Gerhard
On Sun, Aug 2, 2009 at 4:53 AM, Gerhard Brauer<gerbra@archlinux.de> wrote:
Hi,
if i build local ISOs here on my machine (x86_64) i sometimes could not boot the ISOs cause the generated squashfs files are corrupted. When building the ISO again it works.
I have checked my RAM for several hours without a problem... Have you noticed such errors also on ISO building? The errors: http://users.archlinux.de/~gerbra/tmp/1.png http://users.archlinux.de/~gerbra/tmp/2.png
If we may have a problem with mksquashfs then we have to recheck all images we build. On sigurd this would be mainly the final images, we have to downlaod them all and test if they boot fine before make the release...
On a slightly related note, take a look at the dmesg output on sigurd- something is acting up a bit: $ dmesg | tail ioctl32(grub:28054): Unknown cmd fd(3) cmd(00001261){t:12;sz:0} arg(00000000) on /home/archiso/install-iso/archlinux-2009.08-alpha-ftp-i686.img ioctl32(mke2fs:28828): Unknown cmd fd(3) cmd(80041272){t:12;sz:4} arg(ff810c40) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img.part1 ioctl32(mke2fs:28828): Unknown cmd fd(3) cmd(00001260){t:12;sz:0} arg(ff810c4c) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img.part1 ioctl32(mke2fs:28828): Unknown cmd fd(3) cmd(801c0204){t:02;sz:28} arg(ff810c24) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img.part1 ioctl32(mke2fs:28828): Unknown cmd fd(3) cmd(00001268){t:12;sz:0} arg(ff810ed8) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img.part1 ioctl32(mke2fs:28828): Unknown cmd fd(3) cmd(0000125e){t:12;sz:0} arg(ff810e5c) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img.part1 ioctl32(sfdisk:28850): Unknown cmd fd(3) cmd(00000301){t:03;sz:0} arg(ffa01fd0) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img ioctl32(sfdisk:28850): Unknown cmd fd(3) cmd(80041272){t:12;sz:4} arg(ffa01f30) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img ioctl32(sfdisk:28850): Unknown cmd fd(3) cmd(00001260){t:12;sz:0} arg(ffa01f0c) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img TCP: Peer 91.45.207.117:1722/80 unexpectedly shrunk window 3158076810:3158089878 (repaired)
Am Sonntag, den 02.08.2009, 12:19 -0500 schrieb Dan McGee:
On a slightly related note, take a look at the dmesg output on sigurd- something is acting up a bit:
$ dmesg | tail ioctl32(grub:28054): Unknown cmd fd(3) cmd(00001261){t:12;sz:0} arg(00000000) on .......
Hmm, these are very old dmesg-outputs, we already have builded beta1 on sigurg meanwhile...
Am Sonntag, den 02.08.2009, 19:33 +0200 schrieb Gerhard Brauer:
Am Sonntag, den 02.08.2009, 12:19 -0500 schrieb Dan McGee:
On a slightly related note, take a look at the dmesg output on sigurd- something is acting up a bit:
$ dmesg | tail ioctl32(grub:28054): Unknown cmd fd(3) cmd(00001261){t:12;sz:0} arg(00000000) on .......
Hmm, these are very old dmesg-outputs, we already have builded beta1 on sigurg meanwhile...
Sorry, hit the bad keys... Mail text should go on... I/we keep an eye on it... I will (local on my machine) also for similar, IMHO i saw last some error messagaes nearly similar when building USB images... But again: all this work is done in chroots, so nothing on sigurd self should be hurt... Gerhard
Dan McGee wrote:
On a slightly related note, take a look at the dmesg output on sigurd- something is acting up a bit:
$ dmesg | tail ioctl32(grub:28054): Unknown cmd fd(3) cmd(00001261){t:12;sz:0} arg(00000000) on /home/archiso/install-iso/archlinux-2009.08-alpha-ftp-i686.img ioctl32(mke2fs:28828): Unknown cmd fd(3) cmd(80041272){t:12;sz:4} arg(ff810c40) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img.part1
ioctl32 messages from kernel are triggered when you are running a x86-64 kernel, and when call an ioclt() from 32 bit user-space app with an unsupported command (in other words when no conversion between 32 bit to 64 bit ioctl). But only 50 of this messages are showed by the kernel, next call just return -EINVAL -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Sun, 02 Aug 2009 14:35:32 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Dan McGee wrote:
On a slightly related note, take a look at the dmesg output on sigurd- something is acting up a bit:
$ dmesg | tail ioctl32(grub:28054): Unknown cmd fd(3) cmd(00001261){t:12;sz:0} arg(00000000) on /home/archiso/install-iso/archlinux-2009.08-alpha-ftp-i686.img ioctl32(mke2fs:28828): Unknown cmd fd(3) cmd(80041272){t:12;sz:4} arg(ff810c40) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img.part1
ioctl32 messages from kernel are triggered when you are running a x86-64 kernel, and when call an ioclt() from 32 bit user-space app with an unsupported command (in other words when no conversion between 32 bit to 64 bit ioctl). But only 50 of this messages are showed by the kernel, next call just return -EINVAL
So, what does this mean? we call commands that don't exist, isn't that pretty bad? How does this affect iso building? Dieter
Dieter Plaetinck wrote:
On Sun, 02 Aug 2009 14:35:32 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Dan McGee wrote:
On a slightly related note, take a look at the dmesg output on sigurd- something is acting up a bit:
$ dmesg | tail ioctl32(grub:28054): Unknown cmd fd(3) cmd(00001261){t:12;sz:0} arg(00000000) on /home/archiso/install-iso/archlinux-2009.08-alpha-ftp-i686.img ioctl32(mke2fs:28828): Unknown cmd fd(3) cmd(80041272){t:12;sz:4} arg(ff810c40) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img.part1
ioctl32 messages from kernel are triggered when you are running a x86-64 kernel, and when call an ioclt() from 32 bit user-space app with an unsupported command (in other words when no conversion between 32 bit to 64 bit ioctl). But only 50 of this messages are showed by the kernel, next call just return -EINVAL
So, what does this mean? we call commands that don't exist, isn't that pretty bad? How does this affect iso building?
Dieter
Is a good question, but the answer is maybe difficult respond. First, the ioctl is not executed at all. Second the program that call to ioctl() with and unsupported cmd, in this enviroment, is probably that manages the return status from the call to avoid problems, then in case that is critical, the programs is sure that will be aborted instead of continue running. In this cite case 00001261 is 0 _IO (macro) (bits 31-30) 0x12 (driver) (15-8) 0x60 (function) (7-0) = 97 in decimal $ grep -r "_IO(" . | grep 0x12 | grep 97 ./include/linux/fs.h:#define BLKFLSBUF _IO(0x12,97) /* flush buffer cache */ So no problem. (i guess) and for 80041272 0x8 = 10 = _IOR 0x12 (driver) 0x72 (function) ./include/linux/fs.h:#define BLKGETSIZE64 _IOR(0x12,114,size_t) /* return device size in bytes (u64 *arg) */ Probably the program will try another ioctl to get size if one fail, an abort if can do it (i guess) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Gerardo Exequiel Pozzi wrote:
Dieter Plaetinck wrote:
On Sun, 02 Aug 2009 14:35:32 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Dan McGee wrote:
On a slightly related note, take a look at the dmesg output on sigurd- something is acting up a bit:
$ dmesg | tail ioctl32(grub:28054): Unknown cmd fd(3) cmd(00001261){t:12;sz:0} arg(00000000) on /home/archiso/install-iso/archlinux-2009.08-alpha-ftp-i686.img ioctl32(mke2fs:28828): Unknown cmd fd(3) cmd(80041272){t:12;sz:4} arg(ff810c40) on /home/archiso/install-iso/archlinux-2009.08-alpha-core-i686.img.part1
ioctl32 messages from kernel are triggered when you are running a x86-64 kernel, and when call an ioclt() from 32 bit user-space app with an unsupported command (in other words when no conversion between 32 bit to 64 bit ioctl). But only 50 of this messages are showed by the kernel, next call just return -EINVAL
So, what does this mean? we call commands that don't exist, isn't that pretty bad? How does this affect iso building?
Dieter
Is a good question, but the answer is maybe difficult respond.
First, the ioctl is not executed at all. Second the program that call to ioctl() with and unsupported cmd, in this enviroment, is probably that manages the return status from the call to avoid problems, then in case that is critical, the programs is sure that will be aborted instead of continue running.
In this cite case 00001261 is
0 _IO (macro) (bits 31-30) 0x12 (driver) (15-8) 0x60 (function) (7-0) = 97 in decimal
I mean 0x61 not 0x60
$ grep -r "_IO(" . | grep 0x12 | grep 97 ./include/linux/fs.h:#define BLKFLSBUF _IO(0x12,97) /* flush buffer cache */
So no problem. (i guess)
and for 80041272
0x8 = 10 = _IOR 0x12 (driver) 0x72 (function)
./include/linux/fs.h:#define BLKGETSIZE64 _IOR(0x12,114,size_t) /* return device size in bytes (u64 *arg) */
Probably the program will try another ioctl to get size if one fail, an abort if can do it (i guess)
I mean "an abort if can do it" -> "and abort if can't do it". -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Am Sonntag, den 02.08.2009, 18:41 -0300 schrieb Gerardo Exequiel Pozzi:
Probably the program will try another ioctl to get size if one fail, an abort if can do it (i guess)
I'm sure the reaon for this dmesg messages were: a) Some error we possible have done during setup of the chroots (but the stat of /var/log/dmesg.log speak against this). b) More likely is the function command_usb () in mkarchiso, where and how we create the usb images (ext2 FS, partitioning the image file etc.) This in a linux32 chroot give probably the ioctl call errors in x86_64 kernel ring. Nothing to be worried about IMHO.... Gerhard
participants (4)
-
Dan McGee
-
Dieter Plaetinck
-
Gerardo Exequiel Pozzi
-
Gerhard Brauer