[Bug 177478] Re: e2label crashed with SIGFPE in ext2fs_open2()
Well, again, please send me the first 256k of the filesystem and I can confirm if it's the problem I think it is... -- e2label crashed with SIGFPE in ext2fs_open2() https://bugs.launchpad.net/bugs/177478 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 177478] Re: e2label crashed with SIGFPE in ext2fs_open2()
You could also try downloading the e2fsck-static .deb from Debian- unstable, and use it to try to repair the filesystem. I expect it should fix the problem, if your goal is to recover your filesystem. I'm guessing you must be desperate since you've now opened something like 8 or so duplicate bug reports all for the same problem. :-) -- e2label crashed with SIGFPE in ext2fs_open2() https://bugs.launchpad.net/bugs/177478 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 177478] Re: e2label crashed with SIGFPE in ext2fs_open2()
Can you send me the first 256k of the filesystem which is causing e2fsprogs program to crash? (There really wasn't a need to open 3 separate bug reports, BTW, since they are all the same root cause.) So something like dd if=/dev/hdd1 of=/tmp/upload.img bs=1k count=256 and then send attach the /tmp/upload.img file to one of these bugs? Thanks!! -- e2label crashed with SIGFPE in ext2fs_open2() https://bugs.launchpad.net/bugs/177478 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 177976] Re: fsck.ext3 crashed with SIGFPE in ext2fs_open2()
*** This bug is a duplicate of bug 177478 *** https://bugs.launchpad.net/bugs/177478 fsck.ext3 is a link to e2fsck, so this ***really*** was a duplicate bug report. :-) ** This bug has been marked a duplicate of bug 177478 e2label crashed with SIGFPE in ext2fs_open2() -- fsck.ext3 crashed with SIGFPE in ext2fs_open2() https://bugs.launchpad.net/bugs/177976 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 177482] Re: dumpe2fs crashed with SIGFPE in ext2fs_open2()
*** This bug is a duplicate of bug 177478 *** https://bugs.launchpad.net/bugs/177478 ** This bug has been marked a duplicate of bug 177478 e2label crashed with SIGFPE in ext2fs_open2() -- dumpe2fs crashed with SIGFPE in ext2fs_open2() https://bugs.launchpad.net/bugs/177482 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 177481] Re: e2fsck crashed with SIGFPE in ext2fs_open2()
*** This bug is a duplicate of bug 177478 *** https://bugs.launchpad.net/bugs/177478 ** This bug has been marked a duplicate of bug 177478 e2label crashed with SIGFPE in ext2fs_open2() -- e2fsck crashed with SIGFPE in ext2fs_open2() https://bugs.launchpad.net/bugs/177481 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 177478] Re: e2label crashed with SIGFPE in ext2fs_open2()
You might want to try e2fsprogs 1.40.3-1 from Hardy. it's likely this bug was fixed with this commit: commit ba9d929d914654f8dba36c634bb537ecf0f0bb04 Author: Theodore Ts'o [EMAIL PROTECTED] Date: Fri Sep 7 16:40:25 2007 -0400 Don't crash if s_inode_size is zero Any attempt to open a filesystem with s_inode_size set to zero causes a floating point exception. This is true for e2fsck, dumpe2fs, e2image, etc. Fix ext2fs_open2() so that it returns the error code EXT2_ET_CORRUPT_SUPERBLOCK instead of crashing. Thanks to Dean Bender for reporting this bug. Signed-off-by: Theodore Ts'o [EMAIL PROTECTED] -- e2label crashed with SIGFPE in ext2fs_open2() https://bugs.launchpad.net/bugs/177478 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 187265] Re: fsck: root primary superblock differs from backup immediately after install
This bug was fixed in e2fsprogs 1.40.5, released 3 days ago. -- fsck: root primary superblock differs from backup immediately after install https://bugs.launchpad.net/bugs/187265 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 178659] Re: e2fsck freezes whole machine
This is a kernel issue, not an e2fsprogs issue. ** Changed in: linux-source-2.6.22 (Ubuntu) Sourcepackagename: e2fsprogs = linux-source-2.6.22 -- e2fsck freezes whole machine https://bugs.launchpad.net/bugs/178659 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124773] Re: fsck freezes on laptop
Hi Bryce, I've received your e2i file and e2fsck doesn't hang when I check it. This makes it very likely that what you have is a hardware and/or kernel bug. Does it still hang when you run e2fsck on your machine? -- fsck freezes on laptop https://bugs.launchpad.net/bugs/124773 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124773] Re: fsck freezes on laptop
So no one else is reporting this problem from any other distribution, all evidence is pointing to a Ubuntu-specific kernel problem. I will likely be transferring this bug to the kernel package in the absence of any evidence to the contrary. -- fsck freezes on laptop https://bugs.launchpad.net/bugs/124773 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6542] Re: ext2_types.h uses conflicting definition of __s64 and __u64 on amd64
As far as I know this bug is already fixed in Gutsy and Fiesty. ** Changed in: e2fsprogs (Ubuntu) Status: Confirmed = Fix Released -- ext2_types.h uses conflicting definition of __s64 and __u64 on amd64 https://bugs.launchpad.net/bugs/6542 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 20179] Re: Please add LUKS support to /sbin/findfs
Gutsy is shipping e2fsprogs 1.40.2, and so this issue has been addressed in the currently shipping Ubuntu release. ** Changed in: e2fsprogs (Ubuntu) Status: New = Fix Released -- Please add LUKS support to /sbin/findfs https://bugs.launchpad.net/bugs/20179 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 83848] Re: fsck -c on a HDD with bad sectors (ubuntu feisty herd 3)
Note that this is a kernel bug, not an e2fsprogs bug. In order to fix it we need to know detailed information about the hardware involved. ** Changed in: linux-source-2.6.20 (Ubuntu) Sourcepackagename: e2fsprogs = linux-source-2.6.20 -- fsck -c on a HDD with bad sectors (ubuntu feisty herd 3) https://bugs.launchpad.net/bugs/83848 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 78087] Re: crazy output (weird symbols in console, font changes)
Your system didn't crash; you just had a corrupted FAT filesystem image with garbage in its label that happened to put your terminal into graphical mode. You can fix this by using the Reset and Clear command on gnome-terminal's Terminal menu, off the menu bar. The following patch will cause blkid to safe-print special characters using the ^ and M- notation, to prevent future users from getting confused by this happening. It will be in a future version of e2fsprogs. ** Attachment added: Patch to make blkid safe-print tag values. http://launchpadlibrarian.net/10926755/patch -- crazy output (weird symbols in console, font changes) https://bugs.launchpad.net/bugs/78087 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 63175] Re: fsck on every (re)boot
Bulldog, this is due to Ubuntu having buggy init scripts, and not setting the time correctly before running e2fsck. For some number of strange reasons I haven't been able to get Ubuntu staff to deal with this problem correclty, so starting with e2fsprogs 1.40.3, the debian/rules files have been set up to work around the problem using an /etc/e2fsck.conf script: [options] buggy_init_scripts = 1 -- fsck on every (re)boot https://bugs.launchpad.net/bugs/63175 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 175544] Re: Please sync e2fsprogs (main) from Debian unstable (main)
Note that there will probably be a 1.40.4 being released fairly soon, to fix a number of bugs, but in particular Debian Bug #454926: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454926 So if you haven't rolled out 1.40.3 to all of your Hardy testers, you might want to hold off for a few days and wait for 1.40.4 -- Please sync e2fsprogs (main) from Debian unstable (main) https://bugs.launchpad.net/bugs/175544 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 174174] Re: [e2fsprogs] [CVE-2007-5497] several integer overflows in memory allocating code
Note that pre-built .debs for Ubuntu Gutsy (for e2fsprogs 1.40.3, which fixes a number of additional bugs over 1.40.2) can be found at http://userweb.kernel.org/~tytso/e2-pre-release/ubuntu ** Attachment added: Patch to address CVE-2007-5497 http://launchpadlibrarian.net/10792675/0001-libext2fs-Add-checks-to-prevent-integer-overflows-p.patch -- [e2fsprogs] [CVE-2007-5497] several integer overflows in memory allocating code https://bugs.launchpad.net/bugs/174174 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 164189] Re: uuidgen manual page inconsistency
This has already been fixed in git commit 3b302c2c. This fix will be in the upcoming e2fsprogs 1.40.3 release. - Ted -- uuidgen manual page inconsistency https://bugs.launchpad.net/bugs/164189 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 63175] Re: fsck on every (re)boot
When reporting problems, please tell us which version of e2fsprogs and what version of ubuntu you are using. Also whether you have your hardware clock ticking localtime or UTC. Otherwise a same here isn't very useful -- fsck on every (re)boot https://bugs.launchpad.net/bugs/63175 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Part of the reason why this problem hasn't been fixed is that it has been tagged incorrectly. It is not an e2fsprogs bug, but, as described above it is an Ubuntu installer issue. Unfortunately, I have not been able to find a way correctly tag this problem inside Launchpad as an installer issue, so the wrong people are paying attention to this bug. To be fair to the installation people, this is somewhat of a hard problem, since different people use different partition schemes, and partitions that should be shared (such as /home) and partitions that shouldn't (like /var) aren't necessarily easily determinable by a program not possessing artificial intelligence. You can use heuristics, of course, but heuristics are often incorrect. -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 160712] Re: fsck must never run when on batteries
*** This bug is a duplicate of bug 89752 *** https://bugs.launchpad.net/bugs/89752 See bug #89752. The problem is that the Ubuntu kernels isn't building the necessary ACPI modules into the kernel, but rather using loadable modules that aren't getting loaded before e2fsck runs. So that causes a problem with e2fsck not being able to tell whether or not the system is running on batteries or not. -- fsck must never run when on batteries https://bugs.launchpad.net/bugs/160712 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 160712] Re: fsck must never run when on batteries
*** This bug is a duplicate of bug 89752 *** https://bugs.launchpad.net/bugs/89752 ** This bug has been marked a duplicate of bug 89752 ACPI ac module not getting loaded before e2fsck runs -- fsck must never run when on batteries https://bugs.launchpad.net/bugs/160712 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89752] Re: ACPI ac module not getting loaded before e2fsck runs
Suggestion: In /etc/init.d/checkfs.sh and /etc/init.d/checkroot.sh, at the beginning of the file, place the command: ls /proc/acpi/ac_adapter. If it's not there, then that's clearly your problem. The thing to check would be the initrd file. to see if it includes the acpi modules: gunzip /boot/initrd.img-2.6.24-rc1 | cpio -t | grep acpi (Replace initrd-2.6.24-rc1 with the name of the initrd of whatever kernel you're running.) Finally, check /etc/initramfs-tools/initramfs-tools.conf. What is the settings for the MODULES parameter? I've set my config file to: # # MODULES: [ most | netboot | dep | list ] # # most - Add all framebuffer, acpi, filesystem, and harddrive drivers. # # dep - Try and guess which modules to load. # # netboot - Add the base modules, network modules, but skip block devices. # # list - Only include modules from the 'additional modules' list # MODULES=most It may be that you have this set to list or dep, and it's not picking up the APCI modules as a result. The problem is I run bleeding edge kernels because I like to live on the edge (and because I like being able to get 8 hours of battery life out of my computer --- see http://thunk.org/tytso/blog/2007/10/29/tip-o-the-hat-wag-o-the-finger-linux-power-savings-for-laptop-users/#comments for more details. So I don't see things which are clearly kernel packaging and configuration options issues for default ubuntu kernel users. Those issues are important of course; but I'm not the person to debug them -- ACPI ac module not getting loaded before e2fsck runs https://bugs.launchpad.net/bugs/89752 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124773] Re: fsck freezes on laptop
Hi Bryce, It's very likely your problem is different from the problems reported by people pre-e2fsprogs 1.40. Please refer to the section REPORTING BUGS in the e2fsck man page. In particular, what would be most helpful is the output of dumpe2fs and a compressed raw e2image snapshot of your filesystem. i.e., replacing /dev/hda1 with your device, something like this: e2image -r /dev/hda1 - | bzip2 hda1.e2i.bz2 Please note the privacy implications of this command as documented in the e2image man page before making it available in a public location such as using a launchpad attachment. In particular, a raw e2image file will expose the names of the files in your filesystem, although not the content of the files themselves. Hence, if you have any files with names such as ch1ld pr0n or secr1t Al Quaeda attack plans or even letter to my mistress :-), please make sure you understand what information you are making available when you send me such a file. If you want to send me private e-mail with download information, I will honor any confidentiality request you might make of me, and I won't look at any filename information except as might become available as I am debugging your problem. Best regards, -- fsck freezes on laptop https://bugs.launchpad.net/bugs/124773 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 93921] Re: vol_id: detects crypto_LUKS instead of ext3 UUID
Well, some formats allow for more complicated checks, and others don't. LUKS is really bad, in that it only uses 4 bytes at the beginning of the disk, and nothing else. And the formatter in question, NTFS, isn't under our control. So with blkid, I make a policy that probers that are more sophisticated should try first, and probers which are really stupid (and in the case of LUKS, the probe routine can only be stupid, because everything after the magic number is apparently random encrypted garbage :-). I agree that in general, it's better to make the probing routines more sophisticated, and to fix the broken tool if we can. But short of telling the whole world not to use Windows NT (I am King Canute! I can command the tide from coming in! :-), we can't really do the latter, and in this case, the format prevents us from doing the former. So changing the order to hide the LUKS prober behind more sophisticated probing routines does make sense. -- vol_id: detects crypto_LUKS instead of ext3 UUID https://bugs.launchpad.net/bugs/93921 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 93921] Re: vol_id: detects crypto_LUKS instead of ext3 UUID
Oops, I'm confusing this with another bug report where a NTFS partition was getting misidentified as LUKS. In this case, I suspect what happen is the user got very unlucky. Mke2fs always zaps the first 8k, *except* on sparc platforms (where the default is to use an inline partition table) and if it detects a BSD boot label. So if the LUKS encrypted superblock has 4 bytes that match the two possible values of the BSD boot label, mke2fs will skip zero'ing the boot sector. I could remove that check, but on platforms that are dual-booting with BSD, this could run into problems. In any case, I still think that moving the LUKS check makes sense in this case, since there's no way to improve the probing function, given the LUKS format. -- vol_id: detects crypto_LUKS instead of ext3 UUID https://bugs.launchpad.net/bugs/93921 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124773] Re: fsck freezes on laptop
Well, for someone who knows what they are doing, they *can* skip the check. They can simply boot into simple user mode, and use tune2fs to adjust mount count. Or, if you are booting using a plain text console, just edit /etc/e2fsck.conf, add: [options] allow_cancellation = true This will allow ^C to work. However, if you are using a graphical boot, it's up to the graphical boot manager to forward the ^C to e2fsck, which is not my problem. Personally, I think it's a REALLY, REALLY BAD IDEA, given my understanding of what Ubuntu is aiming for. There are solutions for technically clueful users; they're just not obvious, as you proposed. If you don't know to boot into single user mode, you probably don't have enough clue to understand when it's safe to do this, and when not to. Also, note that for users who are complaining that fsck is freezing at random places, there's almost some kind of hardware and/or kernel bug going on. Bypassing the fsck isn't going to help, and in fact, may cause much larger forms of data loss later on. -- fsck freezes on laptop https://bugs.launchpad.net/bugs/124773 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124773] Re: fsck freezes on laptop
Ah, Ubuntu must set up their scripts so that even in single user mode, it doesn't bypass single user mode. Well, that's what init=/bin/sh is for (although this might not work if your boot setup requires an initrd ramdisk image --- but that's a boot scripts issue). BTW, and if you don't know how to change Ubuntu to use a text boot (by editing /boot/grub/menu.lst) I would again question whether you know enough not to screw yourself up by bypassing necessary system functions willy-nilly. A little knowledge can be a dangerous thing. It's probably more OK for Windows because Windows users are used to arbitrarily losing all of their data :-) Can we get back to why your system was hanging in fsck in the first place? What version of e2fsck did you have installed on your system, and was it always hanging at the same percentage level? -- fsck freezes on laptop https://bugs.launchpad.net/bugs/124773 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124773] Re: fsck freezes on laptop
If you edit the right sections of the menu.lst file (the automatic options sections), then apt-get won't blow away your changes when you install new kernel versions. -- fsck freezes on laptop https://bugs.launchpad.net/bugs/124773 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124773] Re: fsck freezes on laptop
Part of the problem that I'm concerned about is that the vast majority of Ubuntu users are less experienced that say Debian users. That's not a slight against Ubuntu users, but merely a statement of fact; Ubuntu has done a lot of good work to allow less experienced users to be able to install and use Linux. That is a good thing; a very good thing. But it also means that sometimes the protecting users against themselves is in fact a good thing. There is a reason why there are safety interlocks on lawn mowers; giving more control to inexperienced users is not always a good thing. So if the filesystem is corrupted such that if the system is booted, the mission critical application would silently give the wrong answers, or perhaps trade the wrong stocks, or give the 1000 times the amount of X-rays necessary to the human body, would you really be doing the user a favor by giving them the ability to skip an fsck because they are impatient?For life and mission critical systems, usually the designers want to give less control to the users (who often are not sophisticated computer users), not more control. If the system has to be kept running in order to keep some mission critical system going, then the right answer is to have backup systems and a high availability system (such as Linux-HA) which enables the backup when the primary system is not available. Skipping necessary filesystem checks just because it might take too long and allowing potential silent failures is Just A Bad Idea. Then too, if you really want to avoid long delays due to periodic fsck's, the right answer is to use devicemapper, and have a cron script fired during the off-hours (say 1am on Sunday nights, when no one is using the system), which takes a read-only snapshot of the filesystem, and then run the e2fsck against the snapshot once a week or once a month. If there are any discrepancies detected when checking the read- only snapshot, then the script should either send e-mail to the system administrator requesting scheduled maintenance ASAP to fix the problem, or if there is a HA system running, the script should signal the HA system that it is about to take the system down, then shutdown the applications and force a reboot and fsck of the corrupted filesystem. If no errors are detected in the read-only snapshot, then the read-only snapshot can be released and tune2fs -C 0 -T now /dev/sdXX can be used on the original filesystem indicate that it has been successfully checked.So there are clean ways of avoiding the slow boot-time checks while actually increasing the system reliability, besides letting a potentially clueless user skip a necessary system function out of impatience. -- fsck freezes on laptop https://bugs.launchpad.net/bugs/124773 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124773] Re: fsck freezes on laptop
I'd much rather fix the bug for good. So first of all, if always freezes at the same percentage, that is a bug that has already been fixed (see Debian bug #411838, which was fixed in Debian version 1.39+1.40-WIP-2007.04.07+dfsg-1 or later). It looks like at least some of the people who are reporting this bug are saying that it happens at a different percentage completed which changes from run to run of e2fsck. That sounds like a device driver problem, especially when people further report it's fine after the system boots, or if they are using a live CD (I assume this is a Ubuntu live CD which is the same version as your system, so it's the same version of e2fsprogs on the live CD as your system)? I'll note that I'm not hearing this complaint from users of any other distribution, which again makes me suspicious that it's something Ubuntu specific like the Ubuntu kernel. OK, so let's take this from first principles. #1, can you create a compressed e2image of your disk (see the REPORTING BUGS section of the e2fsck man page). #2, can you re-enable fsck at boot, force an fsck, by using the command tune2fs -C 99 /dev/hdXXX, and rebooting, and confirm that it is still locking up for you. #3, if it is, can you place the compressed e2image file at a URL where I can download it. Optionally, you can unbzip the image file in a scratch filesystem where you have enough room, and try running e2fsck over that image file. If it doesn't hang when you try e2fsck'ing the e2image file, and yet it does hang at boot, then it's definitely either a hardware problem or a kernel problem, and we can redirect this bug report to the Ubuntu kernel developers. -- fsck freezes on laptop https://bugs.launchpad.net/bugs/124773 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89752] Re: skipping fsck while booting on battery
It works fine for me (Ubuntu Feisty), but I'm building my own kernel and CONFIG_ACPI_BATTERY is set to yes, instead of building it as a module. The problem is that the init scripts aren't loading the acpi ac module soon enough, so there is no way for e2fsck to tell whether or not we are on battery or not at that stage of the boot script. There is nothing e2fsck can do here; this is a bug in the init scripts. Or, you can do what I do and build your own kernel. In any case, this is NOT an e2fsprogs bug. As I said, it works fine for me, and the fix very clearly doesn't involve e2fsprogs; it involves making sure that /proc/acpi/ac_adapter is visible when e2fsck runs, which is a function of loading the acpi ac module early enough, or building it directly into the kernel. -- skipping fsck while booting on battery https://bugs.launchpad.net/bugs/89752 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89752] Re: ACPI ac module not getting loaded before e2fsck runs
** Summary changed: - skipping fsck while booting on battery + ACPI ac module not getting loaded before e2fsck runs ** Description changed: - Binary package hint: e2fsprogs - - It should be a good idea to skip filesystem check after X mounts while a - laptop is booting on battery, to save battery life. + This ACPI module needs to be loaded before e2fsck runs. This would + allow e2fsck to detect when a laptop is booting on battery, so it can + skip filesystem checks to save battery life. -- ACPI ac module not getting loaded before e2fsck runs https://bugs.launchpad.net/bugs/89752 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 139792] Re: Ask for confirmation before mkfs
The problem is this breaks shell scripts and Installation programs --- including Ubuntu's. :-) There are enough ways that confused users can blow away their system, such as screwing up the options to dd. Sorry, but if someone can confuse mkfs and fsck, they have no business having root access to the system. ** Changed in: e2fsprogs (Ubuntu) Status: New = Invalid -- Ask for confirmation before mkfs https://bugs.launchpad.net/bugs/139792 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Take a look at /etc/fstab and see if the swap is being specified via a UUID or not. Then use swapon -s to see if you are actually using swap. Fortunately, if the swap partition isn't found, the system will stlil boot correctly. I agree that there's no point in changing the UUID for the swap partition --- actually the right thing to do is if there is a valid swap signature, the install procedure should simply skip the mkswap entirely. For filesystems, the reason why we change the UUID when we reformat the partition is because it is fundamentally a different filesystem at one point. For example, suppose at one point the filesystem contains the critical data files for a MySQL e-commerce database. Now suppose a college intern is given the root password to the server and typo's a mke2fs command, and blows away the filesystem and uses it to restore some backup tapes. Fundamentally, that filesystem now contains something else. Hence, it should have a new UUID. -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
Yep, I'd call it an installer bug, especially if Ubuntu is actively encouraging users to do install multiple systems. Either the installer should be less greedy about installing filesystems into its fstab, or the installer should #1, ask the user if they are sure about reformatting a filesystem, and #2, ask the user whether they want to keep the UUID (in which case it should save the original UUID, and then restore it via tune2fs after running mke2fs), or #3, if the user answered no to #2, search all other filesystems if they have an fstab file referencing that UUID, and ask the user if they would like to remove or modify the line in the other filesystem's fstab file. Note that no other distribution has had this problem, probably because they as aggressively using UUID's in /etc/fstab, and they aren't encouraging users to install alternative boot filesystems on their system for successive beta releases (and hence causing those filesystems to be reformatted). For example, most Debian testers just use apt-get dist-upgrade, and so they won't run into this particular problem. I suspect that Ubuntu is also reaching out to more novice users, who don't automatically consider the need to modify /etc/fstab or to omit unneeded filesystems in /etc/fstab in the first place. -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106209] Re: fsck Unable to resolve UUID
This isn't an e2fsprogs bug. This is a bug in the Ubuntu installation scripts, in that: (a) Ubuntu by default greedily tries to pull all partitions that are present in the system in /etc/fstab. (Maybe that isn't a good idea if you don't need a particular partition for a particular multiboot setup... i.e., if /dev/sda1 is your Tribe1 install, and /dev/sda2 is your Tribe2 install, and you are installing /dev/sda3 with Tribe 3, you DON'T want to put /dev/sda1 and /dev/sda2 in Tribe 3's /etc/fstab --- since you don't need multiple system's root filesystems mounted in Tribe3, and at some point you might overwrite your Tribe1 install in /dev/sda1 with Tribe 4, and at that point the /etc/fstab in your Tribe 3 install is totally bogus. On the other hand if /dev/sda4 is your /home directory, then obviously that should be in the Tribe 3 install.) (b) Ubuntu insists on re-running mkswap on each new install, so if you have multiple boot systems all sharing the same swap partition, you don't want to break the other ones by re-running mkswap and blowing away the UUID used for the swap partition, because then you have to update all of the other systems' /etc/fstab files. So yes, multi-boot is a great way to test multiple versions of distros --- I don't argue with that. But the problem is that fsck has no way of knowing whether or not /dev/sda1 was *really* important (i.e., it's an old Tribe1 install, it's OK if the filesystem with uuid FOO is no longer present), or whether it's some critical part of the filesystem where if it is no longer present, bringing up the system would result in a non-functional server, and so it's better to keep the system down and NOT let it to come up all the way. For example, if you have a critical e-commerce server, and you lose the filesystem containing the database, it's better to let your High Availability system let your backup servers take over, than to let a machine which is just going to answer http requests with help I've fallen and I can't get up responses; it's considered poor form. :-) One thing I am willing to do is to add support for an fstab mount options field, non-essential, which will cause fsck to simply skip a filesystem which can't be found. Then on desktop systems, system administrators or Desktop distros could by default mark filesystems as non-essential so that systems with missing filesystems can continue coming up. Note that this could be quite confusing even on Desktop system if your /home partition is missing, since users will then log in and not have any home directories, but that transfer the responsibility to whoever is setting up the /etc/fstab file --- it definitively makes it the Distro installer's fault. Also, teaching the non-essential mount option may not be enough, since I suspect it will still cause mount -a to barf, and I believe that will cause the init scripts to bomb out, just later --- so if people really want this, they will probably also have to teach mount to understand the non-essential mount option. But, short of fixing the Ubuntu installer not do dumb things such as greadily including other root filesystems for other Linux installs in /etc/fstab by default, so that things break when you reinstall a newer version of Linux or another distro in a partition referenced by other installs' /etc/fstab, that's about the best I can do. Any comments from the Ubuntu installer folks? -- fsck Unable to resolve UUID https://bugs.launchpad.net/bugs/106209 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 131201] Re: always fscks first boot after install
This is a test patch which I've generated which works around the problem a different way. I sitll think the Ubuntu installer and init scripts are being willfully negligent by not trying to do a better. If Ian is really right that the Ubuntu installer isn't going to ask the User to set the clock correctly, there is really not much I'm going to be able to do. ** Attachment added: ubuntu-lame-clock.patch http://launchpadlibrarian.net/9187241/ubuntu-lame-clock.patch -- always fscks first boot after install https://bugs.launchpad.net/bugs/131201 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 131201] Re: always fscks first boot after install
Let's try that again ** Attachment added: ubuntu-lame-clock.patch http://launchpadlibrarian.net/9187242/ubuntu-lame-clock.patch -- always fscks first boot after install https://bugs.launchpad.net/bugs/131201 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 137314] Re: blkid shows outdated / wrong UUID
Hi, please send the exact steps you used to reproduce this, instead of just giving me conclusions. And please tell me what version of Ubuntu/e2fsprogs you were using, thanks. When you say blkid, do you mean the blkid program, or the /etc/blkid.tab file? When you run the /sbin/blkid program, it will scan the devices which are currently available and revalidate the partitions before printing out the results. If the /etc/blkid.tab fle is writeable, it will update /etc/blkid.tab with the results. I have tested this by editing /etc/blkid.tab and changing the labels and uuid's in /etc/blkid.tab, and then running the /sbin/blkid program, and prints the correct results. If it is not doing this for you, I need the exact steps that you used to replicate your problem. If what you are complaining about is that partition imaging software is changing the UUID of the restored partition, but not changing the UUID in /etc/fstab, or that when you reformat the swap-space, all possible /etc/fstab files aren't getting updated, that's not blkid's problem. It's not responsible for the contents of /etc/fstab. It would be up to the partition imaging software to update /etc/fstab, and how to deal with the reformating the swap space problem is a hard one, but I would submit that's not a common case, and a system administrator who tries to install a second Linux system on the same computer is going to have to be responsible for editing /etc/fstab on the first installed system. -- blkid shows outdated / wrong UUID https://bugs.launchpad.net/bugs/137314 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 63175] Re: fsck on every (re)boot
I still dont get the proper answer at this simple question on each bug reports. Why settings made by tune2fs isnt check by fsck. E2fsck is checking the superblock settings made by tune2fs. However, in order to perform the check based on times since last fsck time, e2fsck requires that the system clock be set correctly. With current buggy Debian/Ubuntu boot scripts, this isn't happening. I could work around the problem by adding a config option to /etc/e2fsck.conf [work-around-buggy-Ubuntu-boot-scripts] time-offset = 43200 Which would tell e2fsck to subtract 43,200 seconds from the time returned by time(0), to work around the fact that Ubuntu is screwing up the system clock in the early boot cycle due to not correctly handling the time zone correctly. But otherwise, this is not a problem to solved by e2fsck, but by the buggy Debian/Ubuntu boot scripts that can't be bothered to have the time set correctly when e2fsck is run. -- fsck on every (re)boot https://bugs.launchpad.net/bugs/63175 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 63175] Re: fsck on every (re)boot
What I notice is that the last checked time doesn't seem to be getting updated. It shows Jan 1, 1970 - even though if just ran through fsck 30 minutes ago, and every time I boot. In humandoing's case, it looks like the problem is that the battery for his CMOS system clock is dead, so the time is always incorrectly set at Jan 1, 1970 during early boot. That a separate problem, and about the only fix would be for e2fsck to never do time-based checks if someone has bad hardware clock on their system. So unliike dahas's comment, the solution would be for e2fsck it *ignore* the tune2fs settings, because the system clock can't be trusted when e2fsck is run. -- fsck on every (re)boot https://bugs.launchpad.net/bugs/63175 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 63175] Re: fsck on every (re)boot
In correct, tune2fs -c 0 does NOT mean skip all time-based checks. tune2fs -c 0 means to skip checks based on number of mounts. To disable all time-based checks, you need to use tune2fs -i 0. Read the tune2fs man page, please!! The bug in this case seems to be in your understanding of tune2fs options. -- fsck on every (re)boot https://bugs.launchpad.net/bugs/63175 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 66032] Re: fsck.ext3: Unable to resolve
If you have a filesystem mentioned in /etc/fstab, and you remove it, then of course you will have this failure. At this point, I believe that this bug was fixed in 1.40, for people who had problems with filesystems that were getting misidentified by NTFS. There may also be some users who are sufferring from the Feisty install code grabbing all filesystems and stuffing them in /etc/fstab, and then when people pull a removable disk or some such, the system won't boot. so at this point I think the right thing to do is just to declare this a dup of #110138, and that it has been fixed in e2fsprogs 1.40 and in Gutsy. -- fsck.ext3: Unable to resolve https://bugs.launchpad.net/bugs/66032 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 134763] Re: [Feisty]fsck shows a bug on a partition
Please read the REPORTING BUGS section of the e2fsck man page. I need to know exactly what sort of inconsistencies were reported by e2fsck. Also, are you sure that /dev/hda5 on your new installation of Feisty is the same as on the other installation of Feisty? You might want to run dumpe2fs and look at the UUID and make sure it really is the filesystem that you think it is. Sometimes different kernels will autodetect different disks in different orders, and /dev/hda is just the first disk detected by the kernel. -- [Feisty]fsck shows a bug on a partition https://bugs.launchpad.net/bugs/134763 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 128792] Re: fsck - Trying to Verify Removed Removable Drives
Fsck is trying to read an uninstalled hard drive *because* *you* *told* *it* *to* *do* *so*.Doctor, doctor, it hurts when I stick a sharp ice-pick in my eye! Well, don't do that! The problem is that fstab was really fundamentally intended for key filesystems that must be present in order for the system to run correctly at boot time. If /usr is on a separate device, and it can't be found, you *want* the boot process to stop, and not just don't worry, be happy, and let the system keep going with critical parts of the system missing. If you have a mission critical database in /u1, and the drive is off-line, it is better to let the system *not* come up and then let your High Availability system, such as Linux-HA, let the backup system take over than just let the system come up but not actually be able to do anything useful (or worse yet, return inaccurate/wrong information!) This problem could be solved by having a way to mark a filesystem as optional, and add support for fsck to check to see if a disk is present, and to skip the fsck if it is not there. And mount could potentially do the same thing. But it's really not a complete solution since it doesn't handle what happens if the removable disk is inserted some time after the boot sequence is finished. I suspect the real right answer is to extend the support we currently have for CD-ROM's to support removable hard drives, which we currently actually already have if you are using the Ubuntu/GNOME desktop, although as far as I know the GNOME desktop doesn't automatically run fsck on a disk after it is inserted and before it automounts it. The whole paradigm of boot-time fsck to check removable drives is really just all wrong. -- fsck - Trying to Verify Removed Removable Drives https://bugs.launchpad.net/bugs/128792 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 128792] Re: fsck - Trying to Verify Removed Removable Drives
This isn't a bug. noauto just means, don't mount the filesystem by default. See the fstab(5) man page. If you want to have something in /etc/fstab, but you don't want it to be mounted by default *and* you don't want it to be checked by default, you need to set the fsck pass number to 0. Again, please read the fstab man page. ** Changed in: e2fsprogs (Ubuntu) Status: New = Invalid -- fsck - Trying to Verify Removed Removable Drives https://bugs.launchpad.net/bugs/128792 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 125331] Re: Please sync e2fsprogs-1.40.1
Note the freeze exception filed in bug #124839. However, at this point I will recommend syncing against 1.40.2 (about to be released). An e2fsck seg fault bug (present in Feisty as well, BTW) was just reported to me, so there are two bug fixes that will be in 1.40.2 (plus translation file updates): http://repo.or.cz/w/e2fsprogs.git?a=commit;h=5e9ba85c2694926eb784531d81ba107200cf1a51 http://repo.or.cz/w/e2fsprogs.git?a=commit;h=575307cc63d24766ff789262a5cea7b4faf2fa13 -- Please sync e2fsprogs-1.40.1 https://bugs.launchpad.net/bugs/125331 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124839] Re: Request Freeze Exception for E2fsprogs 1.40.1
I thought the explicit request from a developer defined in Debian Import Freeze required a Freeze Exception, but you probably know the process better than I. Note that I am about to release 1.40.2, with two bug fixes including one reported to me today that will cause e2fsck to seg fault on a badly corrupted filesystem. Said bug (see http://repo.or.cz/w/e2fsprogs.git?a=commit;h=5e9ba85c2694926eb784531d81ba107200cf1a51 for details) is in Feisty as well, BTW. -- Request Freeze Exception for E2fsprogs 1.40.1 https://bugs.launchpad.net/bugs/124839 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 125106] Re: fsck not updating clean history
#1. Are you sure you got the UUID's correct? #2. Were the filesystems mounted at the time? Fsck won't work on a mounted filesystem; in fact you should have gotten a Big Fat Warning, Is it checking your filesystem after every boot? And are you paying attention to *which* filesystem it is checking. Are you sure it is checking the filesystems that you just checked by hand? Please check using dumpe2fs -h /dev/hdb1, and note especially these fields: Last mount time: Fri Jul 6 01:51:48 2007 Last write time: Fri Jul 6 01:51:48 2007 Mount count: 2 Maximum mount count: 22 Last checked: Thu Jul 5 22:56:02 2007 Check interval: 15552000 (6 months) Next check after: Tue Jan 1 21:56:02 2008 These should tell the tale about what is going on. It could be any number of things, none of which would be an e2fsprogs bugs. The most likeliest problem is that time is not correctly set at boot. See this bug here: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/43239 But in any case, if you aren't checking the filesystems while they are mounted, check using dumpe2fs after you do the check. That will tell you the state of the filesystem, and whether or not e2fsck will do a check when it runs. Note that if your system clock is not using GMT, definitely take a look at the above referenced above. -- fsck not updating clean history https://bugs.launchpad.net/bugs/125106 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 6542] Re: ext2_types.h uses conflicting definition of __s64 and __u64 on amd64
Note that a fix to this problem is I believe in 1.39+1.40-WIP-2006.11.14+dfsg-2ubuntu1, which is in both Feisty and Gutsy. So I believe this bug can be marked Fix Released. Can you test to make sure you are happy now? -- ext2_types.h uses conflicting definition of __s64 and __u64 on amd64 https://bugs.launchpad.net/bugs/6542 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 93921] Re: vol_id: detects crypto_LUKS instead of ext3 UUID
This specific issue has already been raised upstream, who has said it's not their problem. They don't consider trying to improve in-band type detection of fillesystems to be a priority. :-( My recommendation is to move the LUKS detection farther down in the list of filesystem types in vol_id, but it's not clear upstream will be willing to do that. -- vol_id: detects crypto_LUKS instead of ext3 UUID https://bugs.launchpad.net/bugs/93921 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124839] Re: Request Freeze Exception for E2fsprogs 1.40.1
My apologies, but that *was* the procedure documented here: https://wiki.ubuntu.com/FreezeExceptionProcess If Ubuntu-release should not be subscribed to bugs requesting an exception to the Freeze Exception, please tell me what the correct procedure should be. -- Request Freeze Exception for E2fsprogs 1.40.1 https://bugs.launchpad.net/bugs/124839 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 124839] Re: Request Freeze Exception for E2fsprogs 1.40.1
On Mon, Jul 09, 2007 at 07:02:02AM -, Sarah Hobbs wrote: Please *dont* subscribe ubuntu-release to bugs. My apologies, but that *was* the procedure documented here: https://wiki.ubuntu.com/FreezeExceptionProcess If Ubuntu-release should not be subscribed to bugs requesting an exception to the Freeze Exception, please tell me what the correct procedure should be. Thanks, regards, - Ted -- Request Freeze Exception for E2fsprogs 1.40.1 https://bugs.launchpad.net/bugs/124839 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 124839] Re: Request Freeze Exception for E2fsprogs 1.40.1
On Mon, Jul 09, 2007 at 09:43:37AM -, Jim Qode wrote: ** Changed in: e2fsprogs (Ubuntu) Status: New = Confirmed Thanks, I assume that this means the Freeze exception has been approved; can you help walk me through the next step, if I need to do anything? I'm a Debian developer and I'm not fully up on the Ubuntu procedures, so it's not clear to me if I need to prepare a new set of binary packages for Gutsy (I've built them on Feisty and Sid as part of my development testing), or whether there is some automated process which takes the sid upload and transmogrifies it into an Ubuntu package. If it is the former, I assume there some kind of sponsored upload process given that I don't have upload privileges for Ubuntu (at least as far as I know!). Can you walk me through that? Thanks, and thanks in advance for your accomodation of my relative lack of inexperience in the Ubuntu processes! - Ted -- Request Freeze Exception for E2fsprogs 1.40.1 https://bugs.launchpad.net/bugs/124839 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124773] Re: fsck freezes on laptop
What version of e2fsck are you using? -- fsck freezes on laptop https://bugs.launchpad.net/bugs/124773 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124773] Re: fsck freezes on laptop
What happens when you manually run the command e2fsck -n /dev/hdXX, where /dev/hdXX should be your laptop filesystem. Does anything get printed before it frezes. Is there any disk activity when it is frozen. -- fsck freezes on laptop https://bugs.launchpad.net/bugs/124773 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124773] Re: fsck freezes on laptop
That sounds suspiciously like Debian bug #411838, which was fixed in Debian version 1.39+1.40-WIP-2007.04.07+dfsg-1 or later. -- fsck freezes on laptop https://bugs.launchpad.net/bugs/124773 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124773] Re: fsck freezes on laptop
Let's see if I can confirm whether or not this is the same bug. First of all, can you reproduce it if you re-enable fsck checking? Secondly, do you remember what percentage number it froze at, and was it always the same? If so, what was the number? -- fsck freezes on laptop https://bugs.launchpad.net/bugs/124773 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 110138] Re: findfs/blkid detects ext3 partition as ntfs (without UUID)
Note that if Gutsy is going to take e2fsprogs, the version that should be taken at this point is e2fsprogs 1.40.1, which has a number of important bugfixes over e2fsprogs 1.40. -- findfs/blkid detects ext3 partition as ntfs (without UUID) https://bugs.launchpad.net/bugs/110138 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 124839] Request Freeze Exception for E2fsprogs 1.40.1
Public bug reported: Binary package hint: e2fsprogs E2fsprogs 1.40.1 has just been released into upstream, and into Debian unstable. It fixes a number of rather critical bugs that are found in the current version (1.39+1.40-WIP-2007.04.07+dfsg-2).There have been two releases since that last release, 1.40 and 1.40.1 and both have been bug-fix only releases. Some of more notable bugs that have been fixed since then include: * If there are corrupted inodes found in pass2, and the locale is set to Turkish, e2fsck will hang in an infinite loop due to a buggy Turkish translation which resulted in an @-expansion loop. E2fsck now has a recursive depth limit of 10 when doing @-expansions to avoid this problem. * Partitions that previously contained an NTFS filesystem could be misidentified as NTFS instead of the ext2/3 filesystem, due to a bug in libblkid. This has bitten many Ubuntu users, who have filed a number of Launchpad bugs. Those have been largely consolidated into Launchpad #110138 * E2fsprogs 1.39 introduced a bug which caused e2fsck to not work on floppy drives. This was fixed in e2fsprogs 1.40 There are a number of other bugs that have been fixed, including Debian Bug #'s 401711, #407107, #416477, #432052, Sourceforge Bug# 1745818, and Gento Bug #146903, but the three above are the most serious. E2fsck has also been enhanced so that if the journal is corrupted, it will remove the journal, and then automatically recreate it at the end of e2fsprogs run. In addition it is more paranoid about checking all blocks in the journal to make sure they are valid, and if uses the backup journal inode information in the superblock it will now write that information into the journal inode after the information has been checked out. The previous version was uploaded into unstable a bit over a weak ago, and one bug was reported, which has been fixed in 1.40.1. I believe 1.40.1 to be stable, but if you want to wait 10 days until it migrates to testig, thta's also fine, but I wanted to get the request for a freeze exception in now. If there are any problems, I am monitoring the launchpad bug reports, and am prepared to fix any problems that shake out promptly. Regards, Ted ** Affects: e2fsprogs (Ubuntu) Importance: Undecided Status: New -- Request Freeze Exception for E2fsprogs 1.40.1 https://bugs.launchpad.net/bugs/124839 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 110138] Re: findfs/blkid detects ext3 partition as ntfs (without UUID)
FYI, e2fsprogs 1.40 has been released, both in upstream, and I just uploaded e2fsprogs 1.40-1 to Debian/sid (currently in upload queue as of this writing). Can someone let me know what's necessary to get the Gutsy release engineering team to consider pulling this into gutsy? Thanks!! -- findfs/blkid detects ext3 partition as ntfs (without UUID) https://bugs.launchpad.net/bugs/110138 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 43239] Re: fsck should check against a timestamp 49710 days old
Well, the problem is fundamentally more about the initscripts and util- linux than it is about e2fsprogs. The message printed by e2fsprogs will change, so that it says the time is in the future, as opposed to 49710 days. But the root cause of the bug really is the fact that the system clock is not set correctly at the time the root filesystem is checked. Even with the future version of e2fsprogs, if the time is incorrect, a filesystem check will be forced when it doesn't need to be, which is what users really complain about. Simply changing the message isn't going to keep users from getting upset (and they deserve to be). I had thought the bug was fixed since util-linux moved the hwclock.sh to rcS.d/S8hwclock.sh in version 2.12r-13, and Feisty is using 2.12r- 17ubuntu, but I see that upon closer inspection it looks like Feisty still has hwclock.sh started at S50 (and Debian still has it as S11 instead of S8, argh; so bug #342887 was inappropriately closed in Debian, sigh). So I believe the correct answer at this point is that an Ubuntu task against util-linux needs to be kept open against the Ubuntu util-linux package, since that is where the correct patch should be applied. Does that sound right to you? -- fsck should check against a timestamp 49710 days old https://bugs.launchpad.net/bugs/43239 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 107965] Re: [Feisty]Bug with kernel 2.6.20 on AMD 64 : no way to boot
The other distro happened to use the label /. If you have parallel mounted distribution, using mount-points for labels can be very confusing. In any case, if simply going to another kernel solved the problem, then this clearly isn't an e2fsck-static bug. I am confused about how changing the kernel would cause fsck to bomb out, and changing the kernel boot option shouldn't make a difference either. Can you send me your /etc/fstab file? In any case, unless you can replicate it, and I'd suggest that perhaps this bug report should be closed out. -- [Feisty]Bug with kernel 2.6.20 on AMD 64 : no way to boot https://bugs.launchpad.net/bugs/107965 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 43239] Re: fsck should check against a timestamp 49710 days old
The fundamental bug here is in the init scripts. E2fsck assumes that the system time is correct. Unfortunately, if you have the system time set to tick localtime, instead of GMT, the Debian/Ubuntu boot scripts do not adjust for the fact that the hardware clock is not ticking UTC until after checking the root filesystem. This causes the last checked time to be writen out in the wrong time zone, and then if you reboot right away, it causes this problem. In the latest versions of e2fsprogs, e2fsck will print a messaging that the clock is insane, and then check the filesystem since it could also be the case that the clock is insane. But the real, fundamental flaw is that the init scripts aren't correctly making sure that the system clock is accurately set before e2fsck is run. ** Changed in: e2fsprogs (Ubuntu) Status: Confirmed = Invalid ** Also affects: sysvinit (Ubuntu) Importance: Undecided Status: New -- fsck should check against a timestamp 49710 days old https://bugs.launchpad.net/bugs/43239 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 110138] Re: findfs/blkid detects ext3 partition as ntfs (without UUID)
Note: e2fsprogs 1.40-rc1 was released yesterday at: http://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/e2fsprogs-1.40-rc1.tar.gz E2fsprogs 1.40 final is scheduled to be released at the end of the week; if folks could test it to make sure there aren't any seriously embarassing bugs, I would greatly appreciate it. I am currently running e2fsprogs 1.40-rc1 on my Ubuntu Feisty laptop If anyone can connect me with whomever makes e2fsprogs decision making for Ubuntu Gutsy about getting this into the Gutsy (since I believe I just missed the last Debian import deadline), I would greatly appreciate it. -- findfs/blkid detects ext3 partition as ntfs (without UUID) https://bugs.launchpad.net/bugs/110138 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 43239] Re: fsck should check against a timestamp 49710 days old
I started looking further on this issue, and it looks like it has been fixed in util-linux by making /etc/localtime a file, and by making sure the timezone is set correctly at boot time. See these debian bug reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343645 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342887 In any case, it's not an e2fsprogs issue. Time should be set correctly when e2fsck runs, gosh darn it! ** Changed in: sysvinit (Ubuntu) Status: New = Invalid -- fsck should check against a timestamp 49710 days old https://bugs.launchpad.net/bugs/43239 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 121687] Re: Confusing message for fsck check at boot
The problem is that boots is not accurate. A filesystem can be mounted at other times than just at boot up. For example, if you have a USB exnternal disk, it will get mounted each time you insert it into your system. In addition, on larger systems there may be multiple partitions and filesystems, and so it's not your hard disk, it's a specific filesystem. And we deliberately stagger things so that if you have multiple filesystems, we don't check them all at one time. In any case, there are many, many messages that get printed at boot time, and not all of them make sense to the newbie user. If Ubuntu wants to put some pretty graphical interface over e2fsck, great, but the suggested changes don't at all make sense for experienced system administrators who *do* care about this kind of detail, and taking away useful information is uncool. -- Confusing message for fsck check at boot https://bugs.launchpad.net/bugs/121687 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 20179] Re: Please add LUKS support to /sbin/findfs
Checked into e2fsprogs's SCM, will be in e2fsprogs 1.40 -- Please add LUKS support to /sbin/findfs https://bugs.launchpad.net/bugs/20179 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89752] Re: skipping fsck while booting on battery
** Also affects: powermgmt-base (Ubuntu) Importance: Undecided Status: Unconfirmed -- skipping fsck while booting on battery https://bugs.launchpad.net/bugs/89752 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48563] Re: filesystem check fails on boot, but filesystem isn't bad
OK, so it looks like you fixed /media/md4, but I'm guessing you have yet *another* filesystem that is labelled as '/'. Can you send me the output of the bllkid command. And can you make sure you don't have another filesystem that is labelled as '/'?I'm guessing that at one point for some reason either you or some installer labelled all of your filesystems as '/'. Otherwise, if it was checked as clean when the *real* root filesystem was checked, it wouldn't make sense that a subsequent run of e2fsck would say that the filesystem was marked as having errors and that the root directory was corrupted. -- filesystem check fails on boot, but filesystem isn't bad https://bugs.launchpad.net/bugs/48563 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 93921] Re: findfs does not find a UUID which patently exists
Ah, OK. So this looks like it was really a bug with vol_id where it was giving you the UUID for the old LUKS partition, so when you searched for the UUID of the old LUKS partition, findfs didn't find it because it correctly identified it as an ext3 partition. I've received a patch to identify a crypto_LUKS into e2fsprogs, so I'm going to want to make sure we don't misidentify a previously old LUKS partition.I also want to make sure that mke2fs is zapping the location where the LUKS partition was located so we don't have this problem in the future. ** Also affects: udev (Ubuntu) Importance: Undecided Status: Unconfirmed -- findfs does not find a UUID which patently exists https://bugs.launchpad.net/bugs/93921 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 66316] Re: FSCK run twice
Did you see something like this? /: clean I'm wondering if what happened is that the label of multiple filesystem was set to '/'. In any case, if this can't be replicated, I'm inclined to close this bug. -- FSCK run twice https://bugs.launchpad.net/bugs/66316 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 66316] Re: FSCK run twice
closing as invalid, as requested. ** Changed in: e2fsprogs (Ubuntu) Status: New = Invalid -- FSCK run twice https://bugs.launchpad.net/bugs/66316 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 110138] Re: findfs/blkid detects ext3 partition as ntfs (without UUID)
OK, I've looked at this some more, and I think I can guess what happened. The NTFS superblock is located in the boot sector (the first 512-byte sector on the disk).Code to zap the bootsector has been in mke2fs for a long time (since at least 2000, and probably earlier). However, in 2002 we added code to avoid zapping the bootsector if it looked like a BSD disk label, since that cause problems. I'm guessing that you had a partifion which previously had contained NTFS, or which at any rate had the NTFS signature at offset 3 from the beginning of the boot sector, but which also looked like BSD disk label, so mke2fs avoided clearing out the boot sector. This allowed blkid to misidentify the filesystem. The enclosed patches, which will be in e2fsprogs 1.40, tries harder to validate that the partition really is NTFS, and sets the NTFS UUID and Label information. It still can get fooled, since the MFT is located near the middle of the disk, so it won't necessarily get zapped by mke2fs. I will also probably change mke2fs so that it will be more aggressive about zapping the boot sector if it contains an NTFS signature. ** Attachment added: Patch to add NTFS probing support (will be in e2fsprogs 1.40) http://launchpadlibrarian.net/8125325/ntfs-probe-patch -- findfs/blkid detects ext3 partition as ntfs (without UUID) https://bugs.launchpad.net/bugs/110138 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89752] Re: skipping fsck while booting on battery
This bug should be rejected, since e2fsck already has this functionality (built into the binary). If you are running off battery, it will double the number of mounts that are allowed until it forces an fsck. This allows the check to be deferred, but not indefinitely. -- skipping fsck while booting on battery https://bugs.launchpad.net/bugs/89752 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 66032] Re: fsck.ext3: Unable to resolve
I'm pretty sure this bug is related to bug #110138, where the partition is getting mis-identified as an NTFS parition. Due to a bug in e2fsprogs previous to version 1.30, the initial bootsector (which is where the NTFS signature is stored) wasn't getting erased.This could cause blkid to misidentify the filesystem as NTFS. This would only happen on old partitions which had previously contained NTFS, and which were formated as ext2/ext3 using an old mke2fs binary. A quick workaround to this problem is: dd if=/dev/zero of=/dev/hdXX bs=1 count=512 I have a patch which makes blkid less likely to report a false positive; it has been attached to bug #110138. Regards, -- fsck.ext3: Unable to resolve https://bugs.launchpad.net/bugs/66032 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 86114] Re: e2label appears to be broken in Feisty Herd 4
Can you send the output of the commands blkid and cat /proc/partitions on sony-feisty? Thanks!! -- e2label appears to be broken in Feisty Herd 4 https://bugs.launchpad.net/bugs/86114 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 93921] Re: findfs does not find a UUID which patently exists
What does the blkid command report? -- findfs does not find a UUID which patently exists https://bugs.launchpad.net/bugs/93921 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 66032] Re: fsck.ext3: Unable to resolve
** Changed in: e2fsprogs (Ubuntu) Assignee: (unassigned) = Theodore Ts'o ** Changed in: e2fsprogs (Ubuntu) Status: Confirmed = In Progress -- fsck.ext3: Unable to resolve https://bugs.launchpad.net/bugs/66032 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 110138] Re: findfs/blkid detects ext3 partition as ntfs (without UUID)
** Changed in: e2fsprogs (Ubuntu) Assignee: (unassigned) = Theodore Ts'o Status: Unconfirmed = In Progress -- findfs/blkid detects ext3 partition as ntfs (without UUID) https://bugs.launchpad.net/bugs/110138 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 66316] Re: FSCK run twice
I'm not sure I under stand what you're saying here? It sounds like one filesystem hadn't been checked after 29 mounts, said it would be checked on the next reboot, and oin the next reboot it was checked. Could it be that you had another filesystem on your filesystem that was ready to be checked, and it was checked on this boot cycle?How many filesystems do you have on your system? The number of mounts before a check are intentionally randomized to avoid (or at least make much, much less likely) that all of the filesystems on the system needing to be checked all at once. But it could be that one filesystem would be checked after the next boot, but the second filesystem was due to be checked at the current boot. That might explain what you saw. Othetrwise, I'm not sure what you are reporting/complaining about. Regards, -- FSCK run twice https://bugs.launchpad.net/bugs/66316 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89752] Re: skipping fsck while booting on battery
e2fsck has this feature already (and has had it since e2fsprogs version 1.35, released February 28, 2004) ** Changed in: e2fsprogs (Ubuntu) Status: Needs Info = Rejected -- skipping fsck while booting on battery https://bugs.launchpad.net/bugs/89752 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 68589] Re: Failed file system check, weird behaviour
What version of Ubuntu is this? If a particular filesystem is not always present, then you should configure the disk so that the fsck pass number is 0, and that mount option noauto is present so that the filesystem is not mounted at boot time. Then it will not interrupt the boot process, and the system will not try to mount the filesystem (and fail if it is not present). You can optionally add the user mount option to allow the user to manually mount the filesystem; with appropriate desktop software installed, it will also automatically mount the filesystem when it is inserted at the specified mount point. For example, I have the following in my /etc/fstab file: UUID=a8f27eb6-1759-4f48-859d-a4c3b4bcac13 /wd1ext3 noauto,user,exec,nosuid 0 0 As far as shutdown -h now inside the shell causing the boot to resume, yes I've noticed this as well. That appears to be a bug in the upstart package. You can also see this behavior by hitting control-alt-delete during the fsck process. ** Also affects: upstart (Ubuntu) Importance: Undecided Status: Unconfirmed ** Changed in: e2fsprogs (Ubuntu) Status: Unconfirmed = Rejected -- Failed file system check, weird behaviour https://bugs.launchpad.net/bugs/68589 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 107965] Re: [Feisty]Bug with kernel 2.6.20 on AMD 64 : no way to boot
Can you send me the output of the blkid command (run as root), please? This sounds like it may very well be a duplicate of bug #110138, but I'd like to confirm that. Thanks! -- [Feisty]Bug with kernel 2.6.20 on AMD 64 : no way to boot https://bugs.launchpad.net/bugs/107965 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 107433] Re: [Feisty]erratic pb with fsck at boot with kernel 2.6.20-generic on AMD 64
Can you run the blkid program and post the output, please? Thanks!! -- [Feisty]erratic pb with fsck at boot with kernel 2.6.20-generic on AMD 64 https://bugs.launchpad.net/bugs/107433 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 93921] Re: findfs does not find a UUID which patently exists
This is very likely a duplicate of bug #110138. Can you tell me something about the partition?Was there originally an NTFS partition on it, by any chance (or some other filesystem located at that location)? Also, when was the filesystem (with the problem) originally mke2fs'ed? There was bug in very old versions of mke2fs where it didn't zap the boot sector of the filesystem, which meant that an old NTFS filesystem signature could end up confusing the blkid/findfs programs. This would explain the symptoms that you reported. -- findfs does not find a UUID which patently exists https://bugs.launchpad.net/bugs/93921 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48563] Re: filesystem check fails on boot, but filesystem isn't bad
Hi Andy, I have a sneaking suspicion that what's confusing you is that there is some other filesystem which is NOT your root filesystem that has a label of /. E2fsck will use the label assuming it is more human friendly than the raw device name. However, if some other device (say, /dev/hda1) has a label of /, but which is NOT your real root filesystem, this would result in very confusing behavior. When you ran e2fsck /dev/hda5 from a rescue CD, it printed the following: [EMAIL PROTECTED]:~# e2fsck /dev/hda5 -d -f e2fsck 1.38 (30-Jun-2005) 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 /dev/hda5: 125124/1224000 files (0.7% non-contiguous), 732289/2443880 blocks If /dev/hda5 had a label of '/', it would have printed: /: 125124/1224000 files (0.7% non-contiguous), 732289/2443880 blocks But, it didn't.However, the filesystem that reported the warning with the bad root directory caused e2fsck to report: /: Root inode is not a directory. So what I would suggest is that you use the command e2label /dev/hdXX where /dev/hdXX gets replaced with each of the ext2/3 filesystems mentioned in your /etc/fstab. I suspect that some other filesystem other than your root filesystem, /dev/hda5, has a label of '/', and this is confusing you. Regards, -- filesystem check fails on boot, but filesystem isn't bad https://bugs.launchpad.net/bugs/48563 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48563] Re: filesystem check fails on boot, but filesystem isn't bad
Andy, If you have the time to check your old machine, assuming it is still intact, I would greatly appreciate it. That way we can determine whether or not we really have a bug, and hopefully either fix the bug, or close out this bug report. Thanks!!! -- filesystem check fails on boot, but filesystem isn't bad https://bugs.launchpad.net/bugs/48563 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 68589] Re: Failed file system check, weird behaviour
Well, the problem is that we need to distinguish between a critical filesystem (like /usr) being not present, and something completely optional, like /media/disk. More of a concern is where a filesystem is critical for an application-level server, and if it's missing it causes the server to really go boom. So we could just do the don't worry, be happy approach and just silently ignore a missing filesystem, and then let the server come up skipping the filesystem check and the filesystem mount. But this could cause bigger problems and cause more troubles than if the server is left down. I could see a system configuration option which has the don't worry, be happy philosophy, and the more careful mode. But that's an initscripts issue, not an e2fsprogs issue. Also, if the Ubuntu installer was automatically adding all of these entries to /etc/fstab, that might be a design flaw in the Ubuntu installer. -- Failed file system check, weird behaviour https://bugs.launchpad.net/bugs/68589 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 110138] Re: findfs/blkid detects ext3 partition as ntfs (without UUID)
Stupid question, but what's the schedule for Gutsy? If I get e2fsprogs 1.40 released in the next week or so, would it be too late for Gutsy to move up to the e2fsprogs 1.40 release? -- findfs/blkid detects ext3 partition as ntfs (without UUID) https://bugs.launchpad.net/bugs/110138 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 110138] Re: findfs/blkid reports incorrect info / update-grub fails to resolve UUID
How was this filesystem created? It's apparently idnetifying it as an NTFS filesystem because 3072 bytes from the beginning of the filesystem, the signature string NTFS appeared, and this confused the blkid library. However, mke2fs should have cleared that portion of the disk to avoid false posiives; and it's done so for quite a long time. I should probably make the NTFS check more paranoid, but it shouldn't be happening -- findfs/blkid reports incorrect info / update-grub fails to resolve UUID https://bugs.launchpad.net/bugs/110138 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 110138] Re: findfs/blkid reports incorrect info / update-grub fails to resolve UUID
Actually, that's wrong; blkid is looking at offset 3 from the beginning of the filesystem ,and seeing NTFS. That looks like a bug. Am investigating... -- findfs/blkid reports incorrect info / update-grub fails to resolve UUID https://bugs.launchpad.net/bugs/110138 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 83982] Re: Deleting large files corrupts EXT3 file system
What's happening is that if e2fsck does a complete scan of the filesystem, which in your case your are forcing by touching /forcefsck, and e2fsck notices that there are no more files 2GB, and the large_file feature flag is set, e2fsck will clear the large_file feature flag. Currently it doesn't print a message when it does this, which is causing the confusion. Since it has modified the filesystem, it will return an exit status of 1 (filesystem modified) or 3 (filesystem modified | system should be rebooted) if the filesystem in question is the root filesystem. This is because if parts of the root filesystem were modified, it's not safe to remount the filesystem read-write, since some of the inconsistent parts of the filesystem could have been cached in memory, and so when the filesystem is re-mounted read/write, the broken bits of the filesystem could get written back to disk, undoing e2fsck's work. So it's not that deleting large file corrupts the EXT3 filesystem; it's that e2fsck noticed that the filesystem no longer had any large files, and did you a favor by clearing an RO compat bit which would allow the filesystem to be mounted read/write on really old Linux kernels (which didn't support large files). It probably should have written a message to explain what it was doing, and I could perhaps accept an argument that perhaps there should be a config parameter to suppress clearing the large_file flag, on the argument that very few filesystems are likely to be mounted on a Linux 1.0 or 1.2 systems these days. On the other hand, this happens rarely enough and the time to force reboot isn't that great, so maybe it's not worth the config parameter. In any case that's what's going on. -- Deleting large files corrupts EXT3 file system https://launchpad.net/bugs/83982 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77649] kernel-package doesn't work if CONFIG_LOCALVERSION_AUTO is set
Public bug reported: Binary package hint: kernel-package If building a kernel with CONFIG_LOCALVERSION_AUTO is enabled, so that the LOCALVERSION is automatically set to be the -git revision ID, then make-kpkg will fail to create a .deb. The problem is that make-kpkg needs to know the LOCALVERSION version that will be used, and it currently doesn't check for CONFIG_LOCALVERSION_AUTO and then call scripts/setlocalversion to determine the LOCALVERSION that will be used. ** Affects: kernel-package (Ubuntu) Importance: Undecided Status: Unconfirmed -- kernel-package doesn't work if CONFIG_LOCALVERSION_AUTO is set https://launchpad.net/bugs/77649 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
