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
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
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
*** 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
*** 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 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
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
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.
--
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
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
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
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
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
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)
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
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
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
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
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
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
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,
*** 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
*** 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
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
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
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
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
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
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
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
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
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
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
** 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
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
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
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,
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
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
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,
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,
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
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
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
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
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
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
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,
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
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
#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
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
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,
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
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
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
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
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
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
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
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
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
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!!
--
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
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
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
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
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
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
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
** 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.
--
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
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
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
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
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
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
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
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.
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
** 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
** 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
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,
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
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
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
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
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
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)
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
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
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
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
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
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
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
501 - 596 of 596 matches
Mail list logo
