Re: Re:
On Thu, 2007-08-09 at 16:33 -0400, Mark Lord wrote: > Probably something to do with either LVM or the Device Mapper having > the raw partition already "open" for some remapping purpose. > There was a note about that around here somewhere quite recently.. Indeed, that was it. I posted a followup "Re: [SOLVED] problems while mounting /boot partition" reporting such. Thanx for the heads up though! b. -- My other computer is your Microsoft Windows server. Brian J. Murrell signature.asc Description: This is a digitally signed message part
Re: [SOLVED] problems while mounting /boot partition
On Wed, 2007-08-08 at 18:28 +0200, Michal Piotrowski wrote: > Hi Brian, Hi Michal, > Brian J. Murrell pisze: > > I am using Ubuntu Gutsy, which is the in-development branch heading for > > their next stable release. > > You forgot about message subject, so no one has read this report. Indeed. Very unfortunate. I did re-post with a subject but I have not seen it show up yet, which I have been waiting for to post the solution. Maybe I will just do that here and again if it shows up with the subject posted. The crux of the problem is that the real partitions are being mapped/managed by device mapper, which is being used by LVM: $ ls -l /dev/mapper/ total 0 crw-rw 1 root root 10, 63 2007-08-08 04:56 control lrwxrwxrwx 1 root root 7 2007-08-08 04:56 hda1 -> ../dm-0 lrwxrwxrwx 1 root root 7 2007-08-08 04:56 hda2 -> ../dm-1 lrwxrwxrwx 1 root root 7 2007-08-08 04:56 hda3 -> ../dm-2 This is of course causing those partitions to be opened exclusively, preventing any further uses (i.e. sys_mount()) from being able to use them. Only hda3 of those above is actually an LVM PV. hda1 is an ext3 filesystem (/boot) and hda2 is a FAT32 (could even be FAT16) filesystem. Of course, mounting /dev/dm-0 instead of /dev/hda1 solves the problem. Why this started with Ubuntu's 2.6.22 kernel in Gutsy, I'm not sure. Whether it's a new DM feature or some change in the way Ubuntu handles devices, I don't know. Whatever the case, they need to fix their /dev/disk/by-uuid mappings anyway: $ ls -l /dev/disk/by-uuid/ | grep hda lrwxrwxrwx 1 root root 10 2007-08-08 08:56 12b8250a-d031-4ee1-b486-5e67478d06b4 -> ../../hda1 Cheers, b. -- A day in the yard with my son is just like a day at work. He goes hunting around for stuff and brings it back to me and says: "Hey Dad, look what I found. The money is for me and the screw is for you." signature.asc Description: This is a digitally signed message part
[no subject]
I am using Ubuntu Gutsy, which is the in-development branch heading for
their next stable release.
I have noticed that since some kernel release post-2.6.20 I have been
unable to mount my /boot partition:
$ sudo strace -f mount /dev/hda1 /mnt/foo
execve("/bin/mount", ["mount", "/dev/hda1", "/mnt/foo"], [/* 41 vars*/])= 0
brk(0) = 0x8062000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fbc000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=91976, ...}) = 0
mmap2(NULL, 91976, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fa5000
close(4)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260a\1"..., 512) = 512
fstat64(4, {st_mode=S_IFREG|0644, st_size=1339816, ...}) = 0
mmap2(NULL, 1349136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) =
0xb7e5b000
mmap2(0xb7f9f000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x143) = 0xb7f9f000
mmap2(0xb7fa2000, 9744, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fa2000
close(4)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7e5a000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e5a6b0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xb7f9f000, 4096, PROT_READ) = 0
munmap(0xb7fa5000, 91976) = 0
brk(0) = 0x8062000
brk(0x8083000) = 0x8083000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=2586, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fbb000
read(4, "# Locale name alias data base.\n#"..., 1024) = 1024
read(4, "ies are case independent.\n\n# Not"..., 1024) = 1024
read(4, ".euc \tko_KR.eucKR\nko_KR\t\tko_KR.e"..., 1024) = 538
read(4, "", 1024) = 0
close(4)= 0
munmap(0xb7fbb000, 4096)= 0
open("/usr/lib/locale/en_CA.UTF-8/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_IDENTIFICATION", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=363, ...}) = 0
mmap2(NULL, 363, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fbb000
close(4)= 0
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=25486, ...}) = 0
mmap2(NULL, 25486, PROT_READ, MAP_SHARED, 4, 0) = 0xb7fb4000
close(4)= 0
open("/usr/lib/locale/en_CA.UTF-8/LC_MEASUREMENT", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_MEASUREMENT", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
mmap2(NULL, 23, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fb3000
close(4)= 0
open("/usr/lib/locale/en_CA.UTF-8/LC_TELEPHONE", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_TELEPHONE", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=51, ...}) = 0
mmap2(NULL, 51, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fb2000
close(4)= 0
open("/usr/lib/locale/en_CA.UTF-8/LC_ADDRESS", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_ADDRESS", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=127, ...}) = 0
mmap2(NULL, 127, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fb1000
close(4)= 0
open("/usr/lib/locale/en_CA.UTF-8/LC_NAME", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/usr/lib/locale/en_CA.utf8/LC_NAME", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=62, ...}) = 0
mmap2(NULL, 62, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fb
close(4)= 0
open("/usr/lib/locale/en_CA.UTF-8/LC_PAPER", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_PAPER", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=34, ...}) = 0
mmap2(NULL, 34, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7faf000
close(4)= 0
open("/usr/lib/locale/en_CA.UTF-8/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/lib/locale/en_CA.utf8/LC_MESSAGES", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
close(4)= 0
open("/usr/lib/locale/en_CA.utf8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONL
Re: [PATCH] ip autoconfig with modules, kernel 2.4
On Fri, May 11, 2001 at 07:38:33PM +0100, Russell King wrote: > > As long as you can get the root server IP and path from the DHCP client, I can do that. :-) > then you mount it in a directory, and use pivot_root() to change to > that directory. Cool. > See the "Changing the root device" of Documentation/initrd.txt for more > information about this. This looks like the ticket. I will hack away at that when I can get a moment. :-) Thanx! b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ip autoconfig with modules, kernel 2.4
On Thu, May 10, 2001 at 06:00:39PM +0100, Russell King wrote: > > Hmm, if you've got userspace up and running, and loaded kernel > modules using insmod, then what's wrong about running a dhcp, > bootp or rarp client from userspace? In theory, and for just ip configuration, nothing. I should have given more information though. My goal is actually to NFSRoot the machine being booted. I could not determine a way to get the "root path" attribute given by the dhcp/bootp server from userspace back to the kernel so that it can "change_root()/mount_root()" with it. I seem to recall there was a proc interface for doing this at one time (in the 2.2 kernel) but it seemed to have went away. > You can then drop the > kernel space IP autoconfiguration code. If there were a way to tell the kernel, from userspace, for change_root()/mount_root() where the nfsroot path was, yes. I have been hunting through all of the (nfs) root mount code and I don't see it. It looks like it can be set either on the command line, or by the kernel implementation of bootp. Am I missing it somewhere? b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ip autoconfig with modules, kernel 2.4
Please CC me on any responses as I don't read the kernel-list in my
inbox. Thanx.
I am looking for comments on the attached patch. It's purpose is to
allow IP AutoConfig to happen additionally after the loading of an
initial ramdisk.
This allows one to use a "generic all-purpose" built kernel (i.e. a
fully modular kernel) to retrieve it's IP configuration via BOOTP or
RARP (and DHCP when that is ported into 2.4) as long as the ethernet
driver module for the installed ethernet card is loaded via the
initial ramdisk.
Of course, this elminates the need to build kernels with lots of
statically linked ethernet drivers or building lots of kernels with
specific drivers statically linked in.
My hope is that this is seen as a good idea (and a good
implementation) and that the patch is accepted into the Linux kernel.
All comments welcome.
Thanx,
b.
--- linux-2.2.17.old/init/main.c.orig Tue Mar 27 15:59:08 2001
+++ linux-2.2.17/init/main.cTue Mar 27 16:01:03 2001
@@ -132,6 +132,10 @@
kdev_t real_root_dev;
#endif
+#if CONFIG_IP_PNP
+extern int __init ip_auto_config(void);
+#endif
+
int root_mountflags = MS_RDONLY;
char *execute_command;
@@ -863,6 +863,9 @@
while (pid != wait(&i));
if (MAJOR(real_root_dev) != RAMDISK_MAJOR
|| MINOR(real_root_dev) != 0) {
+#if CONFIG_IP_PNP
+ ip_auto_config();
+#endif
error = change_root(real_root_dev,"/initrd");
if (error)
printk(KERN_ERR "Change root to /initrd: "
--- linux/net/ipv4/ipconfig.c Wed May 9 00:05:43 2001
+++ linux/net/ipv4/ipconfig.c.new Wed May 9 00:05:41 2001
@@ -823,7 +823,7 @@
* IP Autoconfig dispatcher.
*/
-static int __init ip_auto_config(void)
+int __init ip_auto_config(void)
{
if (!ic_enable)
return 0;
Re: reproducable oops with 2.4.0-test9/reiserfs-3.6.17
from the quill of Chris Mason <[EMAIL PROTECTED]> on scroll <1368.972144523@coffee> > > --On 10/15/00 03:19:17 -0700 "Brian J. Murrell" ><[EMAIL PROTECTED]> wrote: > > > During the cpio I get: > > > > kernel BUG at highmem.c:221! > > invalid operand: > > CPU:0 > > EIP:0010:[kunmap_high+28/120] > > Sigh, kunmap works a little better when you send it a page. Try this: Thanks for the response Chris!! Unfortunately, that BUG might have been a red herring. After applying your patch I get very much the same thing still during the cpio. strace of cpio during the copy confirms that it is in "close()" that this bombs. Oct 21 12:53:07 pc kernel: ReiserFS version 3.6.18 Oct 21 12:54:14 pc kernel: Unable to handle kernel NULL pointer dereference at virtual address 0014 Oct 21 12:54:14 pc kernel: printing eip: Oct 21 12:54:14 pc kernel: c0163dcf Oct 21 12:54:14 pc kernel: *pde = Oct 21 12:54:14 pc kernel: Oops: Oct 21 12:54:14 pc kernel: CPU:0 Oct 21 12:54:14 pc kernel: EIP:0010:[create_virtual_node+687/1216] Oct 21 12:54:14 pc kernel: EFLAGS: 00010213 Oct 21 12:54:14 pc kernel: eax: ebx: 000f ecx: c5ab99ec edx: 0ef8 Oct 21 12:54:14 pc kernel: esi: edi: c163704c ebp: c1637000 esp: c5ab9884 Oct 21 12:54:14 pc kernel: ds: 0018 es: 0018 ss: 0018 Oct 21 12:54:14 pc kernel: Process cpio (pid: 819, stackpage=c5ab9000) Oct 21 12:54:14 pc kernel: Stack: c1637000 c163704c 0ef8 0030 c0f02300 0002 Oct 21 12:54:14 pc kernel:c0efc018 c5ab99ec c0f02300 c01654cd c5ab99ec Oct 21 12:54:14 pc kernel:c005b380 c015dbd0 c5ab9df4 c6900600 1ee0 1000da5d 0ef8 Oct 21 12:54:14 pc kernel: Call Trace: [ip_check_balance+877/2912] [do_balance_mark_leaf_dirty+80/112] [journal_mark_dirty+667/688] [fix_nodes+211/1008] [tasklet_hi_action+54/96] [journal_mark_dirty+667/688] [reiserfs_insert_item+137/272] Oct 21 12:54:14 pc kernel:[indirect2direct+569/800] [reiserfs_cut_from_item+246/1056] [is_tree_node+76/112] [reiserfs_do_truncate+822/1136] [reiserfs_truncate_file+180/496] [devfsd_buf_size+8132/39500] [devfsd_buf_size+26735/39500] [reiserfs_file_release+437/816] Oct 21 12:54:14 pc kernel:[reiserfs_file_release+771/816] [devfsd_buf_size+8452/39500] [devfsd_buf_size+26735/39500] [file_read_actor+0/256] [fput+54/208] [filp_close+83/96] [sys_close+67/80] [system_call+51/64] Oct 21 12:54:14 pc kernel: Code: ff 50 14 89 c2 8b 5d 00 01 da 89 55 00 8b 5c 24 38 83 c4 10 Any other ideas? b. -- Brian J. Murrell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
reproducable oops with 2.4.0-test9/reiserfs-3.6.17
I have a 2.4.0-test9/reiserfs-3.6.17 (as well as various other patches which I can enumerate if you think it matters) system which is oopsing reproducably. The sequence to reproduce is: o make a reiserfs filesystem o mount it o run "find /usr -mount -depth | cpio -pvudm /mnt/reiserfs" to bulk copy data to it During the cpio I get: kernel BUG at highmem.c:221! invalid operand: CPU:0 EIP:0010:[kunmap_high+28/120] EFLAGS: 00210286 eax: 001d ebx: ecx: c284e000 edx: c618f7a0 esi: c284fbec edi: c284fe90 ebp: c284fc04 esp: c284fba0 ds: 0018 es: 0018 ss: 0018 Process cpio (pid: 8366, stackpage=c284f000) Stack: c02085af c0208791 00dd c3029000 c016e0d4 1000 c25a0c00 3000 0050 1000 0005 0033 4000 2000 0001 0004 0005 0033 3001 2000 0050 Call Trace: [tvecs+13279/49404] [tvecs+13761/49404] [indirect2direct+620/696] [maybe_indirect_to_direct+497/508] [reiserfs_cut_from_item+204/1072] [reiserfs_do_truncate+756/1028] [reiserfs_truncate_file+178/500] [devfsd_buf_size+9208/40928] [devfsd_buf_size+28810/40928] [reiserfs_file_release+818/852] [devfsd_buf_size+9570/40928] [devfsd_buf_size+28810/40928] [fput+56/208] [filp_close+92/100] [sys_close+67/84] [system_call+51/64] [startup_32+43/314] Code: 0f 0b 83 c4 0c 8d 76 00 8d 83 00 00 00 02 ba 00 cf 2a c0 c1 The "BUG" message and the oops happen at the same time. Is there anything more I can do to help track this down? b. -- Brian J. Murrell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
