I have tried all vanilla-sources-2.6.25* and gentoo-sources-2.6.25-r2 with the same reesult. Just when kernel is about to mount / and start init it says something along the lines of "can't boot from unknown block device (8,5)". But funny thing is, it lists that device as recognised with all its partitions - it's /dev/sda5 ( booting from extended partition). I have checked multiple times adn it seems I have configed-in everythin neccesary, certainly ext2/ext3 filesystem which I am usin and ATA & SATA support etc etc. gentoo-sources-2.6.24-r7 works perfectly with practically the same config file... I know i should report bug upstream, but can't find effective way to do so, and here on gentoo I was hoping that extra voices will help me narrow down what was it that makes it fail on my machine... MY machine is: AMD64 X2 6000+ nVidia 8800GT 4GB DDR2 Foxcon board NF570 SLI chipset multiple disks on IDE as well as on SATA. all main partitions on /dev/sda (SATA) I will attach kernel config, emerge --info output and /etc/fstab... Reproducible: Always Steps to Reproduce: 1. make mrproper && make menuconfig bzImage modules modules_install 2. copy bzImage into /boot and tweak grub.conf 3. reboot Actual Results: Kernel panics with "can't find unknown block device (8,5)" just after listing it with all its partitions... Expected Results: normal boot with mounting the "/" and starting init...
Created attachment 152779 [details] output of emerge --info
Created attachment 152781 [details] /etc/fstab
Created attachment 152783 [details] kernel config file
Hi Branko, Bugzilla is not a support channel, so please reopen after you have varified that this is really a regression in kernel. Hint: are you sure that you haven't migrated from old regular PATA drivers to the new libata framework, for example?
(In reply to comment #4) > Hi Branko, Bugzilla is not a support channel, so please reopen after you have > varified that this is really a regression in kernel. Hint: are you sure that > you haven't migrated from old regular PATA drivers to the new libata framework, > for example? > I'm quite certain that I didn't screw uo with new ata/sata framework, since I have played with it some time ago and since I didn't really change anythin substantial in config file since 2.6.23 . Update: I heve tried new gentoo-sources-2.6.25-r3 with exactly the same results as with any previous -r* But interesting thing is that I have copied all most of teh relevant system bits from my root partition /dev/sda5 to my /root ( /dev/sda3 ), changed grub.conf accordingly and system boots just fine ! It seems that new kernel can't boot from extended partitions ( at least in my configuration) even though it lists them just fine when attempt fails...
You're using both the old ide and the new ata drivers. It's possible that these conflict, and anyway I don't think it's needed since CONFIG_ATA_PIIX also supports PATA drives on the Intel ICH controller. So please disable CONFIG_IDE in your .config and see if that works for you.
I ah just tried that. I shut of old infrastructure completely. And results are the same. I can't boot from /dev/sda5, but can boot from /dev/sda3... It still seems that access to extended partitions ( > 4) is the problem...
Created attachment 152901 [details] kernel config new version wthout old ata infrastructure
I have just tried something new. I have booted new kernel from /dev/sda3 and have tried to mount /dev/sda5 manually - it failed with "no superblock or wrong fs" Since I have several more extended partitions, I have tried to mount them, an succeeded. /dev/sda5 is ext4dev and every other partition I have succesfully mounted is ex2/3. It seems new kernel has problems with ext4dev. I have read something about inode size change from 128 bytes to 256 bytes in order to accomodate new features in ext4, so i checked it out with tune2fs -l and found it to be 128 bytes. Could that be the source of my problems ?
(In reply to comment #9) > I have just tried something new. I have booted new kernel from /dev/sda3 and > have tried to mount /dev/sda5 manually - it failed with "no superblock or wrong > fs" > > Since I have several more extended partitions, I have tried to mount them, an > succeeded. > > /dev/sda5 is ext4dev and every other partition I have succesfully mounted is > ex2/3. > > It seems new kernel has problems with ext4dev. > > I have read something about inode size change from 128 bytes to 256 bytes in > order to accomodate new features in ext4, so i checked it out with tune2fs -l > and found it to be 128 bytes. > > Could that be the source of my problems ? > Hmm. I have cleaned /dev/sda5 and made anew ext3 fs on it ( inode size 256) and kernel refused to mount it as ext4dev. Dmesg showe a remark simething like "ext4dev - refusing to mount filesystem with test bit set..." So, new kernel _refuses_ to mount ext4dev without flipping some explicit bit. It wouldn't hurt if there was notice about this for end user. Otherwise, everything else seems to be working fine now...
One more thing- with kernel2.6.25 I can't mount any ext2/3 fs which is big enough that it should have inode size=256 at creation. This means that I can mount /boot, but can't mount couple other partitions that are substantially bigger and are perfectly fine with kernel 2.6.24* ...
Am I correct in thinking that your only problem was with an ext4 partition, you reformatted it to ext3, and all is now well? If so then we can close this bug. FYI, in case you were unsure, the ext4 filesystem is not ready for general use yet. You basically shouldn't be using it unless you are developing it. That is why the explicit bit you mentioned was added -- upstream wanted to make it very clear it wasn't ready for general use (yet).
(In reply to comment #12) > Am I correct in thinking that your only problem was with an ext4 partition, you > reformatted it to ext3, and all is now well? If so then we can close this bug. > > FYI, in case you were unsure, the ext4 filesystem is not ready for general use > yet. You basically shouldn't be using it unless you are developing it. That is > why the explicit bit you mentioned was added -- upstream wanted to make it very > clear it wasn't ready for general use (yet). True, but many people were using it successfully for quite a while and not all were developers. So upgrade to 2.6.25 will upset them and probably generate flood of complaints, so some warning notice might be in order. Also, this is not only trouble with 2.6.25. After upgrading new kernel has made one of ext3 partitions inaccessible. It was created a while ago and it had inode size 128. After 2.6.25-r3 refused to mount it, it became inacessible als under 2.6.24-r7. Tune2fs showed that new kernel has set resize_inode option on and old kernel has refused to work with it... Otherwise, anything that is either too small for inode size 256 ( like /boot) or has been initialised with inode size 256 seems to be working fine...
One more thing- not all of those using ext4dev were using it just to ask for trouble. Some, like me, have tried it because they have heard that it is cimpatible with ext3 and that using option "extents" can really show what ext4 is all about. Unfortunately, no one has told me that once you mount ext3 as ext4 with "extents", there is no simple way back, especially if you were writing/changing some files under that mount option...
I'm sure that you weren't intentionally looking for trouble; I'm sorry if I gave that impression. It sounds like wherever you heard about it from did not properly emphasise the dangers. Certainly the ext4 developers are very careful to tell people loudly and often that they should not trust their data to it yet. Unfortunately, after news gets passed along a few times, those details can be lost... (In reply to comment #13) > True, but many people were using it successfully for quite a while and not all > were developers. So upgrade to 2.6.25 will upset them and probably generate > flood of complaints, so some warning notice might be in order. Perhaps so. Hopefully it will make casual ext4 users reconsider whether it is really such a good idea, anyway. Better to be upset by this than by losing all your data ;) Honestly, anyone with important data on a ext4 filesystem should get it off ASAP. The developers do seem to be doing a great job keeping things stable, but if anything goes wrong there aren't many tools out there to help recover, and you're unlikely to get much help or sympathy from upstream. > Also, this is not only trouble with 2.6.25. After upgrading new kernel has made > one of ext3 partitions inaccessible. It was created a while ago and it had > inode size 128. > > After 2.6.25-r3 refused to mount it, it became inacessible als under 2.6.24-r7. > > Tune2fs showed that new kernel has set resize_inode option on and old kernel > has refused to work with it... This doesn't entirely make sense, sorry. First, as far as I can see, inode size and the resize_inode feature don't actually have anything to do with each other, despite their names. Also resize_inode shouldn't be added automatically, regardless of inode size, so I'm not sure what is going on there. In fact tune2fs can't set that feature, it can only clear it. Not to mention it is a compat feature, so it shouldn't prevent old kernels mounting the filesystem anyway. It might help if you gave the exact error you get when you try to mount the filesystem under 2.6.24. Please post your dmesg showing the error and the output of "/sbin/dumpe2fs -h" on the filesystem, thanks.
(In reply to comment #15) > I'm sure that you weren't intentionally looking for trouble; I'm sorry if I > gave that impression. It sounds like wherever you heard about it from did not > properly emphasise the dangers. Certainly the ext4 developers are very careful > to tell people loudly and often that they should not trust their data to it > yet. Unfortunately, after news gets passed along a few times, those details >can be lost... True. But the other trouble is visibility. One can hardly find developers advice regarding ext4 on the net simply because ext4 doesn't have practically any webpage where one could go and check the facts "from horses mouth". All there is is a long list of articles like "ext4 is here, check it out". I could manage to find something about irreversibility of "extents" option long after I have mounted the thing and it's not as I wasn't searching for data. Also, this silent inode size change thing with kernel 2.6.25 is creepy. It should have been advertised LOUDLY and not purely mentioned on some obscure developers site which even Google had trouble to reach... > Perhaps so. Hopefully it will make casual ext4 users reconsider whether it is > really such a good idea, anyway. Better to be upset by this than by losing all > your data ;) But why then is it not mentioned on gentoo ? Many people know about danger of losing data and keep on such disks only non-life critical data, but it still can be the PITA to loose it. As far as I could understand, that was the point of ext4dev - to get into the hands of broader public that was willing to try it. It was obscurity that got on my nerves - there were some things that I wanted to try in 2.6.25 ( and some that were bothering me in earlier versions and I hoped to see them fixed) so I thought it is some stupid bug and kept trying every vanilla and gentoo version I could get. Finally, I had googled for an answer and found it on some forum in the form of hearsay Q & A. It's a little disconcerning to rely on such Al Queda style information flow to say the least ;o) > This doesn't entirely make sense, sorry. First, as far as I can see, inode size > and the resize_inode feature don't actually have anything to do with each > other, despite their names. Also resize_inode shouldn't be added automatically, > regardless of inode size, so I'm not sure what is going on there. In fact > tune2fs can't set that feature, it can only clear it. Not to mention it is a > compat feature, so it shouldn't prevent old kernels mounting the filesystem > anyway. True. Iam just reporting it as I see it. This was the only ext3 partition with inode isze 128 that I have tried to mount on 2.6.25 and this partition was after that inaccessible even on old 2.6.24-r7. After that I had some other issues and decided to recompile everything with latest gcc-4.2.3. I have also recompiled all kernels and now all partitions mount fine. It might have had something to do with lvm2 - this was lvm2 partition, I'm not sure. I'll check again 2.6.25's ability to mount old ext3 partition in a moment...
(In reply to comment #16) > True. Iam just reporting it as I see it. This was the only ext3 partition with > inode isze 128 that I have tried to mount on 2.6.25 and this partition was > after that inaccessible even on old 2.6.24-r7. > > After that I had some other issues and decided to recompile everything with > latest gcc-4.2.3. I have also recompiled all kernels and now all partitions > mount fine. It might have had something to do with lvm2 - this was lvm2 > partition, I'm not sure. > > I'll check again 2.6.25's ability to mount old ext3 partition in a moment... OK, that would be great. Once you see the error, please post the information I requested in the last paragraph of comment 15 and let's see if we can get to the bottom of what is happening there.
(In reply to comment #17) > OK, that would be great. Once you see the error, please post the information I > requested in the last paragraph of comment 15 and let's see if we can get to > the bottom of what is happening there. > I can't. Everything is working now. Without thinking about it, I mounted the thing under 2.6.24 as ext4dev and it worked. After that, 2.6.25 refused to mount it and I found recipe on the net for setting test flag on it, after which it is working under both kernels. So, good new is i am resolving this bug, bad news is I can't recreate problematic circumstances to toy with. Everything seems fine there and I couldn't find abd files, but pr0n is like tropical forest- it thrives on its own but needs occasional fire to get reborn ;o)
OK, thanks for the update.
