Re: current linus bk, error mounting root
On Mon, Mar 21, 2005 at 07:53:15PM -0500, Jon Smirl wrote: > Here is fedora's initrd nash script from my system. I modified it with > the sleep lines. > > It already is creating the /dev node with 'mkrootdev /dev/root' > I don't think udev is even running yet. Something else is causing this. > > echo "Loading libata.ko module" > insmod /lib/libata.ko > echo "Loading ata_piix.ko module" > insmod /lib/ata_piix.ko > echo "Loading raid1.ko module" > insmod /lib/raid1.ko > /sbin/udevstart > raidautorun /dev/md0 > >>>echo Sleep 1 > >>>sleep 1 > echo Creating root device > mkrootdev /dev/root > umount /sys Care to look at what mkrootdev does? thanks, greg k-h - 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: current linus bk, error mounting root
On Mon, Mar 21, 2005 at 08:14:29PM -0500, Kyle Moffett wrote: > On Mar 21, 2005, at 19:19, Andrew Morton wrote: > >Jon Smirl <[EMAIL PROTECTED]> wrote: > >>Jens is right that this is a user space issue, but how many people are > >>going to find this out the hard way when their root drives stop > >>mounting. Since no one is complaining I have to assume that most > >>kernel developers have their root device drivers built into the > >>kernel. I was loading mine as a module since for a long time Redhat > >>was not shipping kernels with SATA built in. > > > >I don't agree that this is a userspace issue. It's just not sane for a > >driver to be in an unusable state for an arbitrary length of time after > >modprobe returns. > > What about if I'm booting from a USB drive? That's a different issue, as you stated. There are other patches floating around that address this. thanks, greg k-h - 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: current linus bk, error mounting root
On Mon, Mar 21, 2005 at 07:57:04PM -0500, Jon Smirl wrote: > On Mon, 21 Mar 2005 16:49:36 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > > Jon, what distro are you using? > > Up2date Fedore Core 3 Ok, sounds like a distro issue, try filing a bug in their bugzilla :) thanks, greg k-h - 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: current linus bk, error mounting root
On Mar 21, 2005, at 19:19, Andrew Morton wrote: Jon Smirl <[EMAIL PROTECTED]> wrote: Jens is right that this is a user space issue, but how many people are going to find this out the hard way when their root drives stop mounting. Since no one is complaining I have to assume that most kernel developers have their root device drivers built into the kernel. I was loading mine as a module since for a long time Redhat was not shipping kernels with SATA built in. I don't agree that this is a userspace issue. It's just not sane for a driver to be in an unusable state for an arbitrary length of time after modprobe returns. What about if I'm booting from a USB drive? In that case, because of the asynchrony of USB probing, it may take 1 or 2 seconds for my attached hub to power on, wake up, boot its embedded microprocessor, etc before it will respond to signals. In such a case, as far as the root hub can tell, there are _no_ external devices for a couple seconds, and that's ignoring that my external USB bootdrive may _also_ need time to "boot" before it will be accessible, and that's only once its parent hub has become available. I think that the kernel needs some kind of wait-for-device API that is accessible from kernel-space for the simple boot sequence, perhaps just waiting for a specific kobject to be detected and complete initialization. For an initrd/initramfs in userspace, dnotify on sysfs (For the static /dev case), or dnotify on /dev (For the udev case) should allow it to detect when the device is available. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - 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: current linus bk, error mounting root
On Mon, 21 Mar 2005 16:49:36 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > The distros that use udev have already all worked out these issues with > their init scripts and such, so it shouldn't be an issue anymore. > > Jon, what distro are you using? The mkinitrd script is broken for up2date Fedore Core 3. udev is not building the sata device in time. The script does: '/sbin/udevstart', 'raidautorun /dev/md0'. I just checked and the sata volumes are missing out of my array. This script used to work and changes after 2.6.11 have thrown off the timing so that it doesn't work anymore. echo "Loading libata.ko module" insmod /lib/libata.ko echo "Loading ata_piix.ko module" insmod /lib/ata_piix.ko echo "Loading raid1.ko module" insmod /lib/raid1.ko /sbin/udevstart raidautorun /dev/md0 echo Creating root device mkrootdev /dev/root umount /sys echo Mounting root filesystem mount -o defaults --ro -v -t ext3 /dev/root /sysroot mount -t tmpfs --bind /dev /sysroot/dev echo Switching to new root switchroot /sysroot umount /initrd/dev -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
On Mon, 21 Mar 2005 16:49:36 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > Jon, what distro are you using? Up2date Fedore Core 3 -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
On Mon, Mar 21, 2005 at 04:43:18PM -0800, Andrew Morton wrote: > Greg KH <[EMAIL PROTECTED]> wrote: > > > > > I don't agree that this is a userspace issue. It's just not sane for a > > > driver to be in an unusable state for an arbitrary length of time after > > > modprobe returns. > > > > It is a userspace issue. If you have a static /dev there are no > > problems, right? If you use udev, you need to wait for the device node > > to show up, it will not be there right after modprobe returns. > > OK, that's different. > > (grumble, mutter) Heh, the sound people went through the same grumblings a few months ago :) > It would be very convenient, tidy and sane if we _could_ arrange for > modprobe to block until the device node appears though. I think devfs can > do that ;) devfs _can_ do that, as it waits on the register block device to create the node. All udev can do is act apon the call to hotplug as fast as it can (in the correct order). The kernel issues the call and then returns, causing modprobe to return. The distros that use udev have already all worked out these issues with their init scripts and such, so it shouldn't be an issue anymore. Jon, what distro are you using? thanks, greg k-h - 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: current linus bk, error mounting root
Here is fedora's initrd nash script from my system. I modified it with the sleep lines. It already is creating the /dev node with 'mkrootdev /dev/root' I don't think udev is even running yet. Something else is causing this. echo "Loading libata.ko module" insmod /lib/libata.ko echo "Loading ata_piix.ko module" insmod /lib/ata_piix.ko echo "Loading raid1.ko module" insmod /lib/raid1.ko /sbin/udevstart raidautorun /dev/md0 >>>echo Sleep 1 >>>sleep 1 echo Creating root device mkrootdev /dev/root umount /sys echo Mounting root filesystem mount -o defaults --ro -v -t ext3 /dev/root /sysroot mount -t tmpfs --bind /dev /sysroot/dev echo Switching to new root switchroot /sysroot umount /initrd/dev -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
On Mon, 21 Mar 2005 16:38:08 -0800, Greg KH <[EMAIL PROTECTED]> wrote: > On Mon, Mar 21, 2005 at 04:19:25PM -0800, Andrew Morton wrote: > > > > (Adds lots of cc's. I trust that's OK). > > > > Jon Smirl <[EMAIL PROTECTED]> wrote: > > > > > > No, I think Jens wants all of the distributions to fix it. I have > > > filed a bug with Fedora on it. > > > > > > Something changed in the timing for loading drivers during boot. You > > > used to be able to do: > > > modprobe ata_piix > > > mount /dev/sda1 > > You can't do that on any udev based system reliably. That has _never_ > been true. You might just have been getting lucky in the past. > mkinitrd in Fedora needs to be modified to wait for the device. Maybe something like a nash command like wait /dev/sda1. > > > Now you have to do this: > > > modprobe ata_piix > > > sleep 1 > > > mount /dev/sda1 > > That's still racy. Rely on the /etc/dev.d/ notifier to be able to tell > you when you can mount your device, that is what it is there for. > > This is a udev issue, not a kernel issue, there's nothing we can do in > the kernel about it (well, except for the obvious thing of giving udev > lots of hints and making it easier for it to work properly and faster, > which we have been doing over the past months.) > > > > I suspect the problem is that udev doesn't get a chance to run anymore. > > > The sleep 1 allows it to run and it creates /dev/sda1. > > > Build ata_piix in and the problem goes away too. > > > > > > Jens is right that this is a user space issue, but how many people are > > > going to find this out the hard way when their root drives stop > > > mounting. Since no one is complaining I have to assume that most > > > kernel developers have their root device drivers built into the > > > kernel. I was loading mine as a module since for a long time Redhat > > > was not shipping kernels with SATA built in. > > > > I don't agree that this is a userspace issue. It's just not sane for a > > driver to be in an unusable state for an arbitrary length of time after > > modprobe returns. > > It is a userspace issue. If you have a static /dev there are no > problems, right? If you use udev, you need to wait for the device node > to show up, it will not be there right after modprobe returns. > > thanks, > > greg k-h > -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
Greg KH <[EMAIL PROTECTED]> wrote: > > > I don't agree that this is a userspace issue. It's just not sane for a > > driver to be in an unusable state for an arbitrary length of time after > > modprobe returns. > > It is a userspace issue. If you have a static /dev there are no > problems, right? If you use udev, you need to wait for the device node > to show up, it will not be there right after modprobe returns. OK, that's different. (grumble, mutter) It would be very convenient, tidy and sane if we _could_ arrange for modprobe to block until the device node appears though. I think devfs can do that ;) - 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: current linus bk, error mounting root
On Mon, Mar 21, 2005 at 04:19:25PM -0800, Andrew Morton wrote: > > (Adds lots of cc's. I trust that's OK). > > Jon Smirl <[EMAIL PROTECTED]> wrote: > > > > No, I think Jens wants all of the distributions to fix it. I have > > filed a bug with Fedora on it. > > > > Something changed in the timing for loading drivers during boot. You > > used to be able to do: > > modprobe ata_piix > > mount /dev/sda1 You can't do that on any udev based system reliably. That has _never_ been true. You might just have been getting lucky in the past. > > Now you have to do this: > > modprobe ata_piix > > sleep 1 > > mount /dev/sda1 That's still racy. Rely on the /etc/dev.d/ notifier to be able to tell you when you can mount your device, that is what it is there for. This is a udev issue, not a kernel issue, there's nothing we can do in the kernel about it (well, except for the obvious thing of giving udev lots of hints and making it easier for it to work properly and faster, which we have been doing over the past months.) > > I suspect the problem is that udev doesn't get a chance to run anymore. > > The sleep 1 allows it to run and it creates /dev/sda1. > > Build ata_piix in and the problem goes away too. > > > > Jens is right that this is a user space issue, but how many people are > > going to find this out the hard way when their root drives stop > > mounting. Since no one is complaining I have to assume that most > > kernel developers have their root device drivers built into the > > kernel. I was loading mine as a module since for a long time Redhat > > was not shipping kernels with SATA built in. > > I don't agree that this is a userspace issue. It's just not sane for a > driver to be in an unusable state for an arbitrary length of time after > modprobe returns. It is a userspace issue. If you have a static /dev there are no problems, right? If you use udev, you need to wait for the device node to show up, it will not be there right after modprobe returns. thanks, greg k-h - 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: current linus bk, error mounting root
(Adds lots of cc's. I trust that's OK). Jon Smirl <[EMAIL PROTECTED]> wrote: > > No, I think Jens wants all of the distributions to fix it. I have > filed a bug with Fedora on it. > > Something changed in the timing for loading drivers during boot. You > used to be able to do: > modprobe ata_piix > mount /dev/sda1 > > Now you have to do this: > modprobe ata_piix > sleep 1 > mount /dev/sda1 > > I suspect the problem is that udev doesn't get a chance to run anymore. > The sleep 1 allows it to run and it creates /dev/sda1. > Build ata_piix in and the problem goes away too. > > Jens is right that this is a user space issue, but how many people are > going to find this out the hard way when their root drives stop > mounting. Since no one is complaining I have to assume that most > kernel developers have their root device drivers built into the > kernel. I was loading mine as a module since for a long time Redhat > was not shipping kernels with SATA built in. I don't agree that this is a userspace issue. It's just not sane for a driver to be in an unusable state for an arbitrary length of time after modprobe returns. - 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: current linus bk, error mounting root
On Tue, Mar 15 2005, Jon Smirl wrote: > Is this problem still being tracked? > > I have figured out a work around of adding a 1 second pause in nash > after the ata_piix driver is loaded. Something has changed in the > driver initialization timing such that later stages of boot try to > access the driver before the driver has created the device without the > pause. > > I am using Fedora Core 3 un modified except for the addition of the 1 > second pause. If the /dev showup timing is a problem, you were just lucky that it worked before and I don't consider it a kernel issue. -- Jens Axboe - 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: current linus bk, error mounting root
Is this problem still being tracked? I have figured out a work around of adding a 1 second pause in nash after the ata_piix driver is loaded. Something has changed in the driver initialization timing such that later stages of boot try to access the driver before the driver has created the device without the pause. I am using Fedora Core 3 un modified except for the addition of the 1 second pause. On Thu, 10 Mar 2005 17:29:19 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Mar 10 2005, Jon Smirl wrote: > > On Thu, 10 Mar 2005 17:01:55 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > > > what are the major/minor numbers of /dev/root? > > > > > > If I boot on a working system it is 8,5 > > I see no /dev/sda detected in your system from the dmesg. Ahh this is > where it panics on loading ata_piix I suppose, can't you capture that > panic with the serial console as well? > > -- > Jens Axboe > > -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
On Sat, 12 Mar 2005 18:15:30 +0500, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: > Jon Smirl wrote: > > > Here's a big clue, if I build ata_piix in I can boot. If it is a > > module I can't. The console output definitely shows that the module is > > being loaded. > > Of course I am not an expert here, but I want to rule out some trivial > userspace things first. > > Some time ago Greg KH said that even when the modprobe command returns, there > is no guarantee that the module finished hardware detection. By rebuilding > ata_piix as a non-module, you changed the timeline. > > Could you please, for debugging, recompile ata_piix as a module again, but add > a "sleep 5" before the mkrootdev command? If that works, a bug (race) is > officially in userspace. > > Sorry if all of the above is in fact just meaningless noise. sleep 5 before mkrootdev fixes it. Attached is working dmesg with module and sleep. ata_piix had been working as a module for over a year so something recent disturbed the timing. > > -- > Alexander E. Patrakov > -- Jon Smirl [EMAIL PROTECTED] dmesg Description: Binary data
Re: current linus bk, error mounting root
Jon Smirl wrote: > Here's a big clue, if I build ata_piix in I can boot. If it is a > module I can't. The console output definitely shows that the module is > being loaded. Of course I am not an expert here, but I want to rule out some trivial userspace things first. Some time ago Greg KH said that even when the modprobe command returns, there is no guarantee that the module finished hardware detection. By rebuilding ata_piix as a non-module, you changed the timeline. Could you please, for debugging, recompile ata_piix as a module again, but add a "sleep 5" before the mkrootdev command? If that works, a bug (race) is officially in userspace. Sorry if all of the above is in fact just meaningless noise. -- Alexander E. Patrakov - 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: current linus bk, error mounting root
On Thu, 10 Mar 2005 19:11:37 -0800, Matt Mackall <[EMAIL PROTECTED]> wrote: > On Thu, Mar 10, 2005 at 01:52:59PM -0500, Jon Smirl wrote: > > Here's a big clue, if I build ata_piix in I can boot. If it is a > > module I can't. The console output definitely shows that the module is > > being loaded. > > Can you post your config? The attached config works. If you change CONFIG_SCSI_ATA_PIIX to a module (make sure it is on initrd) it will fail. I have been running with CONFIG_SCSI_ATA_PIIX as a module since 2.5.30 or so. -- Jon Smirl [EMAIL PROTECTED] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11 # Thu Mar 10 17:53:22 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=15 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_CPUSETS is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODE is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_SCHED_SMT=y # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=m # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set # CONFIG_ACPI_CONTAINER is not set # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA
Re: current linus bk, error mounting root
On Thu, Mar 10, 2005 at 01:52:59PM -0500, Jon Smirl wrote: > Here's a big clue, if I build ata_piix in I can boot. If it is a > module I can't. The console output definitely shows that the module is > being loaded. Can you post your config? -- Mathematics is the supreme nostalgia of our time. - 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: current linus bk, error mounting root
Here's a big clue, if I build ata_piix in I can boot. If it is a module I can't. The console output definitely shows that the module is being loaded. -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
I see: Loading libata.ko module Loading ata_piix.ko module ACPI: PCI interupt :00:1f.2[A] -> GSI 18 (level, low) -> IRQ 169 ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE12 bmdma 0xFEA0 irq 169 ata2: SATA max UDMA/133 cmd 0xFE20 ctl 0xFE32 bmdma 0xFEA0 irq 169 then raid autorun, one of the raid partitions is on /dev/sda No panic on ata_piix load. The panix is on killing init, it is the standard panix from not having a root device. I just built it in instead as a module, I'll try that next and see if says anything different. - Hide quoted text - On Thu, 10 Mar 2005 17:29:19 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Mar 10 2005, Jon Smirl wrote: > > On Thu, 10 Mar 2005 17:01:55 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > > > what are the major/minor numbers of /dev/root? > > > > > > If I boot on a working system it is 8,5 > > I see no /dev/sda detected in your system from the dmesg. Ahh this is > where it panics on loading ata_piix I suppose, can't you capture that > panic with the serial console as well? > > -- > Jens Axboe > > - Hide quoted text - -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
On Thu, Mar 10 2005, Jon Smirl wrote: > On Thu, 10 Mar 2005 17:01:55 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > > what are the major/minor numbers of /dev/root? > > > If I boot on a working system it is 8,5 I see no /dev/sda detected in your system from the dmesg. Ahh this is where it panics on loading ata_piix I suppose, can't you capture that panic with the serial console as well? -- Jens Axboe - 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: current linus bk, error mounting root
On Thu, 10 Mar 2005 17:01:55 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > what are the major/minor numbers of /dev/root? If I boot on a working system it is 8,5 mkrootdev is a nash command mkrootdev path Makes path a block inode for the device which should be mounted as root. To determine this device nash uses the device sug- gested by the root= kernel command line argument (if root=LABEL is used devices are probed to find one with that label). If no root= argument is available, /proc/sys/kernel/real-root-dev provides the device number. I already tried switching from the label syntax to /dev/sda5 without effect. -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
On Thu, Mar 10 2005, Jon Smirl wrote: > Here's what it is doing... looks like the first mount is failing > > echo Creating root device > mkrootdev /dev/root > umount /sys > echo Mounting root filesystem > mount -o defaults --ro -t ext3 /dev/root /sysroot > mount -t tmpfs --bind /dev /sysroot/dev > echo Switching to new root > switchroot /sysroot > umount /initrd/dev what are the major/minor numbers of /dev/root? -- Jens Axboe - 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: current linus bk, error mounting root
Here's what it is doing... looks like the first mount is failing echo Creating root device mkrootdev /dev/root umount /sys echo Mounting root filesystem mount -o defaults --ro -t ext3 /dev/root /sysroot mount -t tmpfs --bind /dev /sysroot/dev echo Switching to new root switchroot /sysroot umount /initrd/dev On Thu, 10 Mar 2005 16:48:31 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Mar 10 2005, Jon Smirl wrote: > > On Thu, 10 Mar 2005 16:31:51 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > > > On Thu, Mar 10 2005, Jon Smirl wrote: > > > > LABEL=/ / ext3defaults > > > > 1 1 > > > > label / is on /dev/sda6 > > > > > > > > Creating root device > > > > Mounting root filesystem > > > > mount: error 6 mounting ext3 > > > > > > if 6 is the errno, it looks like it is trying to open a device that does > > > not exist (ENXIO). Can you up the verbosity of those commands, I'd like > > > to see what it is doing exactly. > > > > Jeff, how can I up the verbosity? This is on Fedora Core 3 but before > > user space is up. Is there some way to tell the boot ramdisk to > > display more info? > > Perhaps you can mount the initrd and change the script to echo the > commands before executing them? Then boot with the modified initrd. > > -- > Jens Axboe > > -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
On Thu, Mar 10 2005, Jon Smirl wrote: > On Thu, 10 Mar 2005 16:31:51 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 10 2005, Jon Smirl wrote: > > > LABEL=/ / ext3defaults1 > > > 1 > > > label / is on /dev/sda6 > > > > > > Creating root device > > > Mounting root filesystem > > > mount: error 6 mounting ext3 > > > > if 6 is the errno, it looks like it is trying to open a device that does > > not exist (ENXIO). Can you up the verbosity of those commands, I'd like > > to see what it is doing exactly. > > Jeff, how can I up the verbosity? This is on Fedora Core 3 but before > user space is up. Is there some way to tell the boot ramdisk to > display more info? Perhaps you can mount the initrd and change the script to echo the commands before executing them? Then boot with the modified initrd. -- Jens Axboe - 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: current linus bk, error mounting root
On Thu, 10 Mar 2005 16:31:51 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Mar 10 2005, Jon Smirl wrote: > > LABEL=/ / ext3defaults1 1 > > label / is on /dev/sda6 > > > > Creating root device > > Mounting root filesystem > > mount: error 6 mounting ext3 > > if 6 is the errno, it looks like it is trying to open a device that does > not exist (ENXIO). Can you up the verbosity of those commands, I'd like > to see what it is doing exactly. Jeff, how can I up the verbosity? This is on Fedora Core 3 but before user space is up. Is there some way to tell the boot ramdisk to display more info? > > -- > Jens Axboe > > -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
On Thu, Mar 10 2005, Jon Smirl wrote: > LABEL=/ / ext3defaults1 1 > label / is on /dev/sda6 > > Creating root device > Mounting root filesystem > mount: error 6 mounting ext3 if 6 is the errno, it looks like it is trying to open a device that does not exist (ENXIO). Can you up the verbosity of those commands, I'd like to see what it is doing exactly. -- Jens Axboe - 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: current linus bk, error mounting root
LABEL=/ / ext3defaults1 1 label / is on /dev/sda6 Creating root device Mounting root filesystem mount: error 6 mounting ext3 mount: error 2 mounting none Switching to new root Switchroot: mount failed 22 umount /initrd/dev failed: 2 This is what is left on the screen when the boot fails. There is a another line about failed to mount root machine halted. I am still broken with using the Linus bk tree as of when I wrote this mail. That should be all of bk6 plus anything that came in this morning. On Thu, 10 Mar 2005 08:50:53 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > On Wed, Mar 09 2005, Jon Smirl wrote: > > On Wed, 9 Mar 2005 22:09:26 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > > > probably not worth the bother, looks like barrier problems. get the > > > serial console running instead and send the full output, I'll take a > > > look in the morning. > > > > serial console boot output attached. > > Hmm ok, nothing of interest there. What does the mount error 6 and 2 > from your original mail mean? I need some more info on what fails > specifically. What mount options are used? What partition is mounted (is > it md or hdaX)? > > I'm not sure -bk5 had the follow up fix patch for the barrier rework, > you should probably just retry with -bk6 first. > > -- > Jens Axboe > > -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
On Wed, Mar 09 2005, Jon Smirl wrote: > On Wed, 9 Mar 2005 22:09:26 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > > probably not worth the bother, looks like barrier problems. get the > > serial console running instead and send the full output, I'll take a > > look in the morning. > > serial console boot output attached. Hmm ok, nothing of interest there. What does the mount error 6 and 2 from your original mail mean? I need some more info on what fails specifically. What mount options are used? What partition is mounted (is it md or hdaX)? I'm not sure -bk5 had the follow up fix patch for the barrier rework, you should probably just retry with -bk6 first. -- Jens Axboe - 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: current linus bk, error mounting root
On Wed, 9 Mar 2005 22:09:26 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote: > probably not worth the bother, looks like barrier problems. get the > serial console running instead and send the full output, I'll take a > look in the morning. serial console boot output attached. > > -- > Jens Axboe > > -- Jon Smirl [EMAIL PROTECTED] Linux version 2.6.11-bk5 ([EMAIL PROTECTED]) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #3 SMP Wed Mar 9 18:36:46 EST 2005 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3ff74000 (usable) BIOS-e820: 3ff74000 - 3ff76000 (ACPI NVS) BIOS-e820: 3ff76000 - 3ff97000 (ACPI data) BIOS-e820: 3ff97000 - 4000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fecf - fecf1000 (reserved) BIOS-e820: fed2 - fed9 (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000fe710 DMI 2.3 present. ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:2 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:2 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 4000:bec0) Built 1 zonelists Kernel command line: ro root=LABEL=/ console=ttyS0 Initializing CPU#0 CPU 0 irqstacks, hard=c03b3000 soft=c03b1000 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 2793.222 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1034896k/1048016k available (1576k kernel code, 12396k reserved, 963k data, 188k init, 130512k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Security Framework v1.0.0 initialized Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09 per-CPU timeslice cutoff: 1462.56 usecs. task migration cache decay timeout: 2 msecs. Booting processor 1/1 eip 3000 CPU 1 irqstacks, hard=c03b4000 soft=c03b2000 Initializing CPU#1 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel P4/Xeon Extended MCE MSRs (12) available CPU1: Thermal monitoring enabled CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09 Total of 2 processors activated (11091.96 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=-1 checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs checking if image is initramfs... it is Freeing initrd memory: 318k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfba5e, last bus=2 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050211 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 6 7 9 10 11 12 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 15) SCSI subsystem initialized PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a rep
Re: current linus bk, error mounting root
On Wed, Mar 09 2005, Jon Smirl wrote: > On Wed, 09 Mar 2005 15:31:10 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: > > Well, there are no changes in libata from bk4 to present. The only > > thing I see in the -bk4-bk5 increment diff that's immediately noticeable > > is the barrier stuff. > > bk4 works > bk5 is broken > > Where are these *.key files? Maybe I can do some more divide and > conquer in bitkeeper. probably not worth the bother, looks like barrier problems. get the serial console running instead and send the full output, I'll take a look in the morning. -- Jens Axboe - 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: current linus bk, error mounting root
Jon Smirl wrote: On Wed, 09 Mar 2005 12:16:44 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: Jon Smirl wrote: Something in the last 24hrs in linus bk broke my ability to mount root: Creating root device Mounting root filesystem mount: error 6 mounting ext3 mount: error 2 mounting none Switching to new root Switchroot: mount failed 22 umount /initrd/dev failed: 2 If I back off a day everything works again. Root is on Intel ICH5 SATA drive. dmesg output? Can you verify that -bk4 works, and -bk5 breaks? bk4 works. I don't have a serial port hooked up so there is no way to get dmesg, but I don't see anything obvious on the screen scrolling by. I'll check bk5 next. It would be much more convenient if the bkN releases were tagged in Linus bk. Well, there are no changes in libata from bk4 to present. The only thing I see in the -bk4-bk5 increment diff that's immediately noticeable is the barrier stuff. Jeff - 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: current linus bk, error mounting root
On Wed, 09 Mar 2005 15:31:10 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: > Well, there are no changes in libata from bk4 to present. The only > thing I see in the -bk4-bk5 increment diff that's immediately noticeable > is the barrier stuff. bk4 works bk5 is broken Where are these *.key files? Maybe I can do some more divide and conquer in bitkeeper. -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
Jon Smirl wrote: On Wed, 09 Mar 2005 12:16:44 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: Jon Smirl wrote: Something in the last 24hrs in linus bk broke my ability to mount root: Creating root device Mounting root filesystem mount: error 6 mounting ext3 mount: error 2 mounting none Switching to new root Switchroot: mount failed 22 umount /initrd/dev failed: 2 If I back off a day everything works again. Root is on Intel ICH5 SATA drive. dmesg output? Can you verify that -bk4 works, and -bk5 breaks? bk4 works. I don't have a serial port hooked up so there is no way to get dmesg, but I don't see anything obvious on the screen scrolling by. I'll check bk5 next. It would be much more convenient if the bkN releases were tagged in Linus bk. No need for tags, that's what the *.key file is for. Jeff - 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: current linus bk, error mounting root
Jon Smirl wrote: On Wed, 09 Mar 2005 12:16:44 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: Jon Smirl wrote: Something in the last 24hrs in linus bk broke my ability to mount root: Creating root device Mounting root filesystem mount: error 6 mounting ext3 mount: error 2 mounting none Switching to new root Switchroot: mount failed 22 umount /initrd/dev failed: 2 If I back off a day everything works again. Root is on Intel ICH5 SATA drive. dmesg output? Can you verify that -bk4 works, and -bk5 breaks? bk4 works. I don't have a serial port hooked up so there is no way to get dmesg, but I don't see anything obvious on the screen scrolling by. I'll check bk5 next. It would be much more convenient if the bkN releases were tagged in Linus bk. Yes, and name them -preN instead. ;) I had a slightly different problem mounting root with an earlier -mm, which was fixed by setting CONFIG_BASE_FULL=y. I saw that option enter the Linus tree recently, so that might be something you could try. Steven - 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: current linus bk, error mounting root
On Wed, 09 Mar 2005 12:16:44 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: > Jon Smirl wrote: > > Something in the last 24hrs in linus bk broke my ability to mount root: > > > > Creating root device > > Mounting root filesystem > > mount: error 6 mounting ext3 > > mount: error 2 mounting none > > Switching to new root > > Switchroot: mount failed 22 > > umount /initrd/dev failed: 2 > > > > If I back off a day everything works again. > > > > Root is on Intel ICH5 SATA drive. > > dmesg output? > > Can you verify that -bk4 works, and -bk5 breaks? bk4 works. I don't have a serial port hooked up so there is no way to get dmesg, but I don't see anything obvious on the screen scrolling by. I'll check bk5 next. It would be much more convenient if the bkN releases were tagged in Linus bk. > > Jeff > > -- Jon Smirl [EMAIL PROTECTED] - 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: current linus bk, error mounting root
Jon Smirl wrote: Something in the last 24hrs in linus bk broke my ability to mount root: Creating root device Mounting root filesystem mount: error 6 mounting ext3 mount: error 2 mounting none Switching to new root Switchroot: mount failed 22 umount /initrd/dev failed: 2 If I back off a day everything works again. Root is on Intel ICH5 SATA drive. dmesg output? Can you verify that -bk4 works, and -bk5 breaks? Jeff - 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/
current linus bk, error mounting root
Something in the last 24hrs in linus bk broke my ability to mount root: Creating root device Mounting root filesystem mount: error 6 mounting ext3 mount: error 2 mounting none Switching to new root Switchroot: mount failed 22 umount /initrd/dev failed: 2 If I back off a day everything works again. Root is on Intel ICH5 SATA drive. -- Jon Smirl [EMAIL PROTECTED] - 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/
