[continued from previous message]   
      
   >> i2c /dev entries driver   
   >> pcf8563 0-0051: chip found, driver version 0.4.2   
   >> pcf8563 0-0051: rtc core: registered pcf8563 as rtc0   
   >> OXNAS bit-bash I2C driver initialisation OK   
   >> md: linear personality registered for level -1   
   >> md: raid0 personality registered for level 0   
   >> md: raid1 personality registered for level 1   
   >> TCP cubic registered   
   >> NET: Registered protocol family 1   
   >> NET: Registered protocol family 17   
   >> drivers/rtc/hctosys.c: unable to open rtc device (rtc)   
   >> md: Autodetecting RAID arrays.   
   >> md: Scanned 0 and added 0 devices.   
   >> md: autorun ...   
   >> md: ... autorun DONE.   
   >> RAMDISK: Compressed image found at block 0   
   >>   
   >> # Above is normal   
   >> # Below is crash   
   >>   
   >> EXT3-fs: Magic mismatch, very weird !   
   >> List of all partitions:   
   >> 0800 3907018584 sda driver: sd   
   >>    0801     498688 sda1   
   >>    0802 3906518016 sda2   
   >> 1f00        128 mtdblock0 (driver?)   
   >> 1f01       1792 mtdblock1 (driver?)   
   >> 1f02       1664 mtdblock2 (driver?)   
   >> 1f03        448 mtdblock3 (driver?)   
   >> 1f04         48 mtdblock4 (driver?)   
   >> 1f05          8 mtdblock5 (driver?)   
   >> 1f06          8 mtdblock6 (driver?)   
   >> No filesystem could mount root, tried:  ext3 ext2 vfat fuseblk   
   >> Kernel panic - not syncing: VFS: Unable to mount root fs on u   
   known-block(1,0)   
   >>   
   >> # Below *would* have been a normal continuation for a successful boot   
   >>   
   >> VFS: Mounted root (ext2 filesystem).   
   >> Freeing init memory: 116K   
   >> MTD_open   
   >> MTD_ioctl   
   >> MTD_read   
   >> MTD_close   
   >> MTD_open   
   >> MTD_ioctl   
   >> MTD_read   
   >> MTD_close   
   >> Mounting file systems...   
   >> MTD_open   
   >> MTD_ioctl   
   >> MTD_read   
   >> MTD_close   
   >> MTD_open   
   >> MTD_ioctl   
   >> MTD_read   
   >> MTD_close   
   >> egiga0: PHY is Realtek RTL8211BGR   
   >> Resetting GMAC   
   >> GMAC reset complete   
   >> ifconfig: bad address 'add'   
   >> Starting udhcpc ...   
   >> INITRD: Trying to mount NAND flash as Root FS.egiga0: PHY is Realtek   
   RTL8211BGR   
   >> egiga0: link down   
   >> ..egiga0: link up, 1000Mbps, full-duplex, not using pause, lpa 0xC1E1   
   >> .scsi 2:0:0:0: Direct-Access     ZyXEL    USB DISK 2.0     PMAP   
   PQ: 0 ANSI: 0 CCS   
   >>   
   >> Any ideas?   
   >   
   > What does "tune2fs" say about the parametrics of the filesystem ?   
   >   
   >     https://media.geeksforgeeks.org/wp-content/uploads/2023092   
   130854/Image-3.png   
   >   
   > Have you previously removed the drive and mounted it on a technician machine   
   ?   
   > Maybe some damage was done to it, while it was out of the NAS and being   
   probed.   
   >   
   > There's got to be some reason that not even the magic number is correct.   
      
   I don't think I would be able to run a graphical tool on it.  The only   
   access I have is via ...   
      
      Web interface   
      ssh command-line   
      USB and Ethernet   
      
   ... unlike the more modern QNAPs, which each have an HDMI output and a   
   remote control that I've never used.   
      
   > *******   
   >   
   > NOR flash can have bad bits in it, but that does not happen all that often.   
   > The most likely place for a failure, is segments which are flashed during   
   > each boot, and even with the high cycle count NOR flash supports, that   
   > sometimes leads to grief.   
   >   
   > The flash load can be segmented, and each chunk has a checksum. It normally   
   > isn't possible to capture an image of an entire flash chip, and just compare   
   > it to an entire image held in hand. The validity may only be able to be   
   determined   
   > by knowing the start and end address of a chunk and verifying it. Automation   
   > in the tools would be the preferred way to determine the flash itself   
   > wasn't causing a corruption. Normally, with flash devices, the loader   
   > will halt, if a portion of what it is loading is defective.   
      
   Don't think this would explain why only particular builds show the   
   kernel panic.  The original working build, the initrd of which I'm   
   trying to adapt, boots fine.  It's only the attempts to customise the   
   initrd which crash in a kernel panic.   
      
   > *******   
   >   
   > Processors do not normally go defective. Sometimes bad batches escape   
   > the factory. And a NAS box is highly unlikely to have been overclocked   
   > for most of its life.   
   >   
   > As for your firmware kit, I would have frozen the working environment   
   > at Ubuntu 7. In the hopes I would always have an old machine to run it on.   
   > Dragging a build environment along, say an unsupported one, on a dynamic   
   > OS situation, that's kinda asking for trouble.   
   Yes, perhaps, but my worst mistake seems to have been not to have copied   
   the build directory of the working build into a new build directory to   
   continue development thereafter, which seems to have meant that the   
   backup of what was working later got overwritten by backups of what did   
   not.  I'm a bit embarrassed and annoyed at my own stupidity there.   
      
   I'm about to try to do a new build from scratch, to see if I can work   
   out what is going wrong.   
      
   --   
      
   Fake news kills!   
      
   I may be contacted via the contact address given on my website:   
   www.macfh.co.uk   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)