A decade later, found the same bug in grub.
It might not affect "standard" grub usage (e.g. Ubuntu) where it may not
need to probe and guess filesystem type just to boot the system, but
thank you for the excellent diagnosis nevertheless!
@haskinsa99 Please don't change the status out of Fix Released. That is
the final status for the bug, Confirmed is not a valid state once a bug
has been marked Fixed Released. Thanks.
** Changed in: util-linux (Ubuntu)
Status: Confirmed = Fix Released
--
mount ext fileystem fails,
** Changed in: util-linux (Ubuntu)
Status: Fix Released = Confirmed
--
mount ext fileystem fails, booting fails, blkid produces no output
https://bugs.launchpad.net/bugs/518582
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Kudos to the original reporter and inventor of the ingenious solution. I
was bit by this bug on a regular laptop and dumbfounded as my Lucid
system's blkid saw the file system, while the Karmic system didn't.
It would be a very good idea indeed to backport this patch to karmic's
util-linux, as it
Just fixed a 9.10 system using the cure suggested in the bug
description. Will the fix be applied to 9.10 as well?
--
mount ext fileystem fails, booting fails, blkid produces no output
https://bugs.launchpad.net/bugs/518582
You received this bug notification because you are a member of Ubuntu
Upstream patch (fixed 14 days ago...)
http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=commit;h=74b1659ddaac4aa409b56d1eaa07d87b5b11b98e
The patch is also included in the bugfix release 2.17.2.
--
mount ext fileystem fails, booting fails, blkid produces no output
util-linux (2.17.2-0ubuntu1) now in Lucid.
** Changed in: util-linux (Ubuntu Lucid)
Status: Confirmed = Fix Released
** Changed in: util-linux (Ubuntu Lucid)
Assignee: (unassigned) = Kees Cook (kees)
--
mount ext fileystem fails, booting fails, blkid produces no output
shouldnt its importance be high or something
--
mount ext fileystem fails, booting fails, blkid produces no output
https://bugs.launchpad.net/bugs/518582
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
** Also affects: util-linux (Ubuntu Lucid)
Importance: Undecided
Status: New
** Changed in: util-linux (Ubuntu Lucid)
Milestone: None = ubuntu-10.04-beta-2
** Changed in: util-linux (Ubuntu Lucid)
Importance: Undecided = High
--
mount ext fileystem fails, booting fails, blkid
I cannot reproduce this with a simple loop-back filesystem:
sudo -s
cd /tmp
dd if=/dev/zero of=test.ext4 bs=1 count=1 seek=1G
mkfs.ext4 -F test.ext4
mkdir -p /mnt/test
mount -o loop text.ext4 /mnt/test
echo $(seq $(hexdump -s 0x410 -n 2 -e '%d\n' test.ext4) - 9336 ) | (cd
/mnt/test; xargs touch)
Hrm, no, I am wrong about location. It does seem to be 0x410, but there
is additional logic in the minix probe that needs to be satisfied. See
probe_minix in shlibs/blkid/src/superblocks/minix.c
--
mount ext fileystem fails, booting fails, blkid produces no output
For a filesystem that fails, can you attach the first 10K of the
partition?
sudo dd if=/dev/sda1 of=/tmp/10k.data bs=10k count=1
The minix sanity checks are failing:
sb = blkid_probe_get_sb(pr, mag, struct minix_super_block);
if (!sb || sb-s_imap_blocks == 0 ||
Is anyone even using a minix filesystem? I mean can't we just not check
for that?
--
mount ext fileystem fails, booting fails, blkid produces no output
https://bugs.launchpad.net/bugs/518582
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Ah, sorry, I should be comparing against the superblock, not the
group_desc.
uint16_t s_ninodes;
uint16_t s_nzones;
uint32_ts_inodes_count;
uint16_t s_imap_blocks;
uint16_t s_zmap_blocks;
uint32_ts_blocks_count;
uint16_t s_firstdatazone;
uint16_t s_log_zone_size;
This failure mode depends on the size of the filesystem, the number of
reserved blocks, and the inodes used. This series of steps reproduces
the problem for me:
rm -f /dev/shm/test.ext4
dd if=/dev/zero of=/dev/shm/test.ext4 bs=1 count=1 seek=1023M
mkfs.ext4 -F /dev/shm/test.ext4
tune2fs -r 0
This script may help identify at risk filesystems. For my system, my
/boot partition is vulnerable, but I'd need to create 2 more inodes
to hit the glitch.
** Attachment added: minix-possible
http://launchpadlibrarian.net/41556914/minix-possible
** Changed in: util-linux (Ubuntu Lucid)
** Description changed:
Symptoms: (Ubuntu 9.10 on an ext4 partition /dev/sda1)
- 1. Booting fails.
+ 1. Booting fails with error message:
+
+ Gave up waiting for root device. common problems
+ -Boot args(cat/proc/cmdline)
+ -check rootdelay=(did the system wait long enough?)
+
** Package changed: ubuntu = util-linux (Ubuntu)
--
mount ext fileystem fails, booting fails, blkid produces no output
https://bugs.launchpad.net/bugs/518582
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
18 matches
Mail list logo
