From: Marc S. <ms...@25...> - 2004-10-20 12:27:36
|
Hi ! I have the following problem: Environment: Kernel 2.4.26 (from www.kernel.org) Patch: http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.4.26-3.bz2 Problem: Creating a larger filesystem as a normal user. (without beeing root) -> Creating a larger image with "dd" -> Creating a filesystem on that image -> Starting a uml-system -> Mounting the new image -> Copy the files from the old image to the new image Old roofs : root_fs.master New rootfs: root_fs.master.new What I have done: - mkfs.ext2 root_fs.master.new - sudo mount -o loop root_fs.master.new /mnt => Only for verification: OK it's usable, and empty - sudo umount /mnt - linux ubd0=root_fs.master ubd1=root_fs.master.new 1 In the single-user-uml-system: unconfigured1:~# mount -t ext2 /dev/ubd1 /mnt/ EXT2-fs: ubd(98,1): couldn't mount because of unsupported optional features (4). mount: wrong fs type, bad option, bad superblock on /dev/ubd1, or too many mounted file systems (could this be the IDE device where you in fact use ide-scsi so that sr0 or sda or so is needed?) unconfigured1:~# mount -oremount,ro / unconfigured1:~# mount -t ext2 /dev/ubd1 /mnt/ EXT2-fs warning (device ubd(98,1)): ext2_read_super: mounting ext3 filesystem as ext2 unconfigured1:/mnt# cd /mnt/ unconfigured1:/mnt# ls bin cdrom etc home lib mnt proc sbin tmp var boot dev floppy initrd lost+found opt root sys usr ====> I seems that ubd0 and ubd1 appear as the same devices I suppose that this is a bug .... |
From: Lars Kellogg-S. <la...@od...> - 2004-10-20 17:20:21
|
> ====> I seems that ubd0 and ubd1 appear as the same devices Have you verified that /dev/ubd0 and /dev/ubd1 are actually different devices? $ ls -l /dev/ubd[01] Make sure the minor numbers are different. If all you're trying to do is create a larger filesystem, a better option is dd + resize2fs on the host. Assuming that you're existing root_fs.master is 100 MB, and you'd like it to be 500 MB, you would first extend the file: $ dd if=/dev/zero of=root_fs.master bs=1M count=0 seek=500 And then extend the filesystem: resize2fs root_fs.master The whole process should look like this: $ ls -lh root_fs.master -rw-r--r-- 1 lars lars 100M 2004-10-20 13:16 root_fs.master $ sudo mount -o loop,ro root_fs.master /mnt/tmp $ df -h /mnt/tmp Filesystem Size Used Avail Use% Mounted on /var/tmp/root_fs.master 97M 4.1M 88M 5% /mnt/tmp $ sudo umount /mnt/tmp $ dd if=/dev/zero of=root_fs.master bs=1M count=0 seek=500 0+0 records in 0+0 records out 0 bytes transferred in 0.001692 seconds (0 bytes/sec) $ /sbin/resize2fs root_fs.master resize2fs 1.35 (28-Feb-2004) Resizing the filesystem on root_fs.master to 512000 (1k) blocks. The filesystem on root_fs.master is now 512000 blocks long. $ ls -lh root_fs.master -rw-r--r-- 1 lars lars 500M 2004-10-20 13:17 root_fs.master $ sudo mount -o loop,ro root_fs.master /mnt/tmp $ df -h /mnt/tmp Filesystem Size Used Avail Use% Mounted on /var/tmp/root_fs.master 485M 4.1M 456M 1% /mnt/tmp $ sudo umount /mnt/tmp -- Lars |
From: BlaisorBlade <bla...@ya...> - 2004-10-21 18:09:02
|
On Wednesday 20 October 2004 19:20, Lars Kellogg-Stedman wrote: > > ====> I seems that ubd0 and ubd1 appear as the same devices > > Have you verified that /dev/ubd0 and /dev/ubd1 are actually different > devices? > > $ ls -l /dev/ubd[01] > > Make sure the minor numbers are different. They not only must be different. The ubd0 minor must be 0, while the ubd1 minor must be 16 (it used to be 1, when partition support was not enabled). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Rick M. <rm...@gm...> - 2004-10-20 16:35:53
|
On Wed, 20 Oct 2004 14:27:26 +0200, Marc Schoechlin <ms...@25...> wrote: > Hi ! > > I have the following problem: > > Environment: > > Kernel 2.4.26 (from www.kernel.org) > Patch: http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.4.26-3.bz2 > > Problem: [...] > - linux ubd0=root_fs.master ubd1=root_fs.master.new 1 [...] > unconfigured1:~# mount -t ext2 /dev/ubd1 /mnt/ > EXT2-fs warning (device ubd(98,1)): ext2_read_super: mounting ext3 filesystem as ext2 [...] > ====> I seems that ubd0 and ubd1 appear as the same devices > > I suppose that this is a bug .... You may have hit a problem that I had. Apparently there is a problem with ubd minor node numbers changing? If you search the list you'll probably find the ref. From within the UML try mounting the image you specify as ubd1 on the command line as ubd16 inside UML. If this works then you've hit the minor node number problem. I only have had this happen on later kernels (2.4.2x onwards). I have a test UML running kernel version 2.4.18 and it doesn't have this problem, but another that has kernel version 2.4.26 does. -- ---------------------------------------------------------------- Rick Morrow, North Bay, Ontario, Canada Unix & Internetworking Systems Consultant PGP Public Key: http://www.delfax.net/~rmorrow/pgp_pub_keys.html |
From: BlaisorBlade <bla...@ya...> - 2004-10-21 18:08:10
|
On Wednesday 20 October 2004 18:35, Rick Morrow wrote: > On Wed, 20 Oct 2004 14:27:26 +0200, Marc Schoechlin <ms...@25...> wrote: > > Hi ! > > > > > ====> I seems that ubd0 and ubd1 appear as the same devices > > > > I suppose that this is a bug .... > You may have hit a problem that I had. Apparently there is a problem > with ubd minor node numbers changing? It's difficult it yields this kind of failure IMHO. However, the minors changed once: when there was no partition support, they were 0,1,2,3... while now they are 0,16,32,48....; the holes in between are for partitions: mknod /dev/ubd0p1 b 98 1 That device node will give you access to the first partition of ubd0. > If you search the list you'll > probably find the ref. From within the UML try mounting the image you > specify as ubd1 on the command line as ubd16 inside UML. You should correct the device nodes... > If this > works then you've hit the minor node number problem. I only have had > this happen on later kernels (2.4.2x onwards). I have a test UML > running kernel version 2.4.18 and it doesn't have this problem, but > another that has kernel version 2.4.26 does. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Lars Kellogg-S. <la...@od...> - 2004-10-21 18:57:47
|
> > Make sure the minor numbers are different. > They not only must be different. The ubd0 minor must be 0, while the ubd1 > minor must be 16 (it used to be 1, when partition support was not enabled). Speaking of device naming... The UML kernel uses command line options 'ubd0', 'ubd1', 'ubdn'...but the kernel itself identifies the devices (in, e.g., /proc/partitions) as ubda, ubdb, etc. Of course, this matches the naming scheme for existing disk devices (hda, sda, etc), but it conflicts with the command line and common parlance here in the mailing list. I suspect this could also cause problems with code that relies on /proc/partitions to scan for devices (I think maybe the LVM code and the mount-by-label support both use this file, but I could be wrong) -- they find an entry for "ubda", but no matching device node. Is this a real problem? Or am I just making stuff up? -- Lars |
From: Gerd K. <kr...@by...> - 2004-10-21 20:41:16
|
Lars Kellogg-Stedman <la...@od...> writes: > I suspect this could also cause problems with code that relies on > /proc/partitions to scan for devices (I think maybe the LVM code and the > mount-by-label support both use this file, but I could be wrong) -- they > find an entry for "ubda", but no matching device node. > > Is this a real problem? Well, the name mismatch on the kernel command line is just cosmetical. The device file names are a problem if they differ exactly because some stuff looks in /proc/partitions. SuSE uses the usual kernel numbering scheme for uml block devices because of that, i.e. the device files *are* named /dev/ubda, /dev/ubdb and so on. And a number appended for partitions, like it is done for hd + sd as well. If you use udev you should also get device nodes with that naming scheme. Gerd -- return -ENOSIG; |