Let me guess... you are using devfs in 2.4, and /dev is empty if devfs
is not mounted.
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> On Thu, Mar 10, 2005 at 03:10:12PM +0100, Andreas Tille <til...@rki.de> wrote:
>> ERROR: Removing 'trm290': Device or resource busy
>> ERROR: Removing 'vis82cxxx': Device or resource busy
>> pivot_root: No such file or directory
>> /sbin/init: 432: cannot open dev/console: No such file
>> Kernel panic - not syncing: Attempt to kill init!
>
> Let me guess... you are using devfs in 2.4, and /dev is empty if devfs
> is not mounted.
Sorry, I did nothing but installing Debian from scratch and installing
several kernel-image-2.6.x packages afterwards. I did no fiddling around with
devfs whatever (to be honest I do not even have an idea why I should if
everything would work fine).
The only hint Google was able to reveal was a broken initrd which is not
able to handle SATA - but as I said, I tried to disable SATA for exactly
this reason (perhaps I failed but this does not explain why 2.4.x works).
Please tell me what I should check and report to follow your idea.
Kind regards
Andreas.
--
http://fam-tille.de
mkinitrd -v /boot/initrd-2.6.x-x.img 2.6.x-x
make sure to add this line to the grube menue.lst:
initrd /boot/initrd-2.6.x-x.img
On Fri, 11 Mar 2005 02:01:42 +1100, Paul Hampson wrote
> On Thu, Mar 10, 2005 at 03:10:12PM +0100, Andreas Tille wrote:
> > Hi,
>
> > I've got a new Dell machine which I was able to install with Kernel 2.4.
27.
> > It has a SATA drive but I disabled SATA in BIOS according to the manuals.
> > All I write in the following has this SATA disabled BIOS setting.
>
> > As I said kernel 2.4.27 works fine. I attach a dmesg and syslog to this
> > mail.
>
> > I tried to upgrade to a 2.6.x kernel but failed always with kernel_panic.
> > I tried 2.6.8, 2.6.8 and 2.6.10 (here -1-386 and -1-686 versions) and
> > all failed with the same result:
>
> > pivot_root: No such file or directory
> > /sbin/init: 432: cannot open dev/console: No such file
> > Kernel panic - not syncing: Attempt to kill init!
>
> > ata: 0x1f0 IDE port busy
> > ata1: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15
> > ata1: dev 0 ATAPI, max UDMA/33
> > ata1: dev 1 ATAPI, max UDMA/33
> > ata1: dev 0 configured for UDMA/33
> > ata1: dev 1 configured for UDMA/33
> > scsi0 : ata_piix
> > elevator: using anticipatory as default io scheduler
> > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> > ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
> > ide0: I/O resource 0x1F0-0x1F7 not free.
> > ide0: ports already in use, skipping probe
> > ide1: I/O resource 0x170-0x177 not free.
> > ide1: ports already in use, skipping probe
>
> This is your problem here. You made your initrd under 2.4.27, where your
> devices where /dev/hd?. However, 2.6 with the initrd has loaded them
> with the SATA driver, and sees them via /dev/sd?.
>
> I think you're going to have to manuall edit your initrd and fstab to
> deal with the change in device name between versions.
>
> Alternatively, pull ata_piix driver out of the initrd, and see if the
> ide driver will load and run your disks.
>
> However, that first line (IDE port busy) worries me a little, since
> it seems neither driver is actually claiming the port itself.
>
> If you want to experiment, there's a command you can put on the Linux
> kernel command line to break into the initrd before it actually does
> anything, and you can see what devices exist and drivers and whatnot.
>
> I can't remember the command though. -_-
>
> --
> -----------------------------------------------------------
> Paul "TBBle" Hampson, MCSE
> 8th year CompSci/Asian Studies student, ANU
> The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
> Paul.H...@Anu.edu.au
>
> "No survivors? Then where do the stories come from I wonder?"
> -- Capt. Jack Sparrow, "Pirates of the Caribbean"
>
> This email is licensed to the recipient for non-commercial
> use, duplication and distribution.
> -----------------------------------------------------------
--
Have fun!
> On Thu, 10 Mar 2005, Jacob S wrote:
>
> > Which version of the Debian-Installer did you use? We had similar
> > symptoms on a new Dell recently at work and had to grab the latest
> > daily build to get a working version. I can check on the exact date
> > of the daily build we used, if you want.
> On my desk I see only a CD with the hand written text "Sarge RC 2" and
> thus I'm relatively sure I took this one ...
> Are there any traces left in a logfile or something like that which
> contains the exact installer version?
I faintly remember hearing about an installer log, but I don't remember
where to find it. I just checked my docs and the installer we had
problems with was RC2. The daily build we used that worked for us was
from Feb. 23rd. I would assume that newer daily builds would work as
well.
HTH,
Jacob
> Which version of the Debian-Installer did you use? We had similar
> symptoms on a new Dell recently at work and had to grab the latest daily
> build to get a working version. I can check on the exact date of the
> daily build we used, if you want.
On my desk I see only a CD with the hand written text "Sarge RC 2" and thus
I'm relatively sure I took this one ...
Are there any traces left in a logfile or something like that which contains
the exact installer version?
Kind regards
It seems that you ran into the "SATA is now supported by the SCSI
driver" problem.
> Freeing unused kernel memory: 220k freed
> initrd-tools: 0.1.77
> vesafb: probe of vesafb0 failed with error -6
> NET: Registered protocol family 1
> SCSI subsystem initialized
> ACPI: PCI interrupt 0000:00:1f.2[C] -> GSI 20 (level, low) -> IRQ 169
> ata: 0x1f0 IDE port busy
> ata1: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15
> ata1: dev 0 ATAPI, max UDMA/33
> ata1: dev 1 ATAPI, max UDMA/33
> ata1: dev 0 configured for UDMA/33
> ata1: dev 1 configured for UDMA/33
> scsi0 : ata_piix
At this time the libata based driver is loaded for your harddisk
> elevator: using anticipatory as default io scheduler
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ide0: I/O resource 0x1F0-0x1F7 not free.
> ide0: ports already in use, skipping probe
> ide1: I/O resource 0x170-0x177 not free.
> ide1: ports already in use, skipping probe
and the 'old' IDE-Driver cannot be loaded any more.
disable one of these two conflicting drivers, but notice that you'll
need scsi disk support for the libata driver and the devices will change
from hd?? to sd??
--
Jörg Friedrich
There are only 10 types of people:
Those who understand binary and those who don't.
> mkinitrd -v /boot/initrd-2.6.x-x.img 2.6.x-x
I guess you mean here "s/-v/-o/", right?
Well, I did so
mkinitrd -o /boot/initrd.img-2.6.10-1-686 2.6.10-1-686
(under
# uname -a
Linux wr-linux03 2.4.27-1-386 #1 Wed Dec 1 19:43:08 JST 2004 i686 GNU/Linux
) but nothing changed. The hint with the initrd problem was given when
trying to get SATA work - but this will be only my next step once I switch
SATA on in BIOS ...
> make sure to add this line to the grube menue.lst:
>
> initrd /boot/initrd-2.6.x-x.img
Sure - I did not changed the default grub boot menu which is created by the
kernel package. Not now - later, if the default Debian kernel works I
normally go without an initial ramdisk.
Kind regards
Andreas.
> On Thu, 10 Mar 2005, Mike Hommey wrote:
>
> > On Thu, Mar 10, 2005 at 03:10:12PM +0100, Andreas Tille
> > <til...@rki.de> wrote:
> >> ERROR: Removing 'trm290': Device or resource busy
> >> ERROR: Removing 'vis82cxxx': Device or resource busy
> >> pivot_root: No such file or directory
> >> /sbin/init: 432: cannot open dev/console: No such file
> >> Kernel panic - not syncing: Attempt to kill init!
> >
> > Let me guess... you are using devfs in 2.4, and /dev is empty if
> > devfs is not mounted.
> Sorry, I did nothing but installing Debian from scratch and installing
> several kernel-image-2.6.x packages afterwards. I did no fiddling
> around with devfs whatever (to be honest I do not even have an idea
> why I should if everything would work fine).
>
> The only hint Google was able to reveal was a broken initrd which is
> not able to handle SATA - but as I said, I tried to disable SATA for
> exactly this reason (perhaps I failed but this does not explain why
> 2.4.x works).
Which version of the Debian-Installer did you use? We had similar
symptoms on a new Dell recently at work and had to grab the latest daily
build to get a working version. I can check on the exact date of the
daily build we used, if you want.
HTH,
Jacob
I've recently had those problems also on a Dell server, using SATA too. The
fine guys from #gpul helped me a lot on this. Basically, what happened to me
is that kernel 2.4 mapped the SATA drive as /dev/hdc and kernel 2.6 mapped it
to /dev/sda
So I booted using the installer with the linux26 option, followed the
installation until the HD partitioning screen, jotted down the hard disk
device (/dev/sda), switched to console 2 and mounted the partition. Then I
changed /etc/fstab and /boot/grub/menu.lst acordingly. Everything worked fine
when I rebooted.
That's what I did on the same symptoms and worked for me.
--
temp: http://temp.roncero.org
Out: 17.69 ºC -- In: 19.38 ºC
> it worked. I really regard this problem as serious because it
> probably leaves people with SATA hardware with an unbootable system
> after kernel-image updates, because the kernel image packages just
> reinsert "root=/dev/hda?" into grub's menu.lst. Any idea how to
> solve this problem?
...by using partition labels in fstab?
Jubal
--
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ]
''When in doubt, tell the truth.''
-- Mark Twain
> I've recently had those problems also on a Dell server, using SATA too. The
> fine guys from #gpul helped me a lot on this. Basically, what happened to me
> is that kernel 2.4 mapped the SATA drive as /dev/hdc and kernel 2.6 mapped it
> to /dev/sda
Well, after doing an
sed -i "s/hda/sda/" /etc/fstab
__AND__
switching BIOS from "conventional" (=no SATA) to "normal" (=SATA)
__AND__
changing grub boot menu from
kernel /boot/vmlinuz-2.6.10-1-686 root=/dev/hda3 ro
to
kernel /boot/vmlinuz-2.6.10-1-686 root=/dev/sda3 ro
it worked. I really regard this problem as serious because it probably
leaves people with SATA hardware with an unbootable system after kernel-image
updates, because the kernel image packages just reinsert "root=/dev/hda?"
into grub's menu.lst . Any idea how to solve this problem?
Is there any solution for swap partitions since they do not support
labels, AFAIK.
Knoppix does something with scanning all harddrives for swap-partitions,
but this cannot support swap priorities
--
Jörg Friedrich
There are only 10 types of people:
Those who understand binary and those who don't.
>> it worked. I really regard this problem as serious because it
>> probably leaves people with SATA hardware with an unbootable system
>> after kernel-image updates, because the kernel image packages just
>> reinsert "root=/dev/hda?" into grub's menu.lst. Any idea how to
>> solve this problem?
>
> ...by using partition labels in fstab?
Sorry, I do not know anything about partition labels but if this is
the solution it should be done in the installer and if this works in
Grub menu.lst this should be done here as well.
Kind regards
Andreas.
By using swapfiles instead?
--
-----------------------------------------------------------------
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.
"War is an ugly thing, but not the ugliest of things. The decayed
and degraded state of moral and patriotic feeling which thinks
that nothing is worth war is much worse. The person who has
nothing for which he is willing to fight, nothing which is more
important than his own personal safety, is a miserable creature,
and has no chance of being free unless made or kept so by the
exertions of better men than himself."
John Stuart Mill
> Miros/law Baran schrieb am Freitag, 11. März 2005 um 12:55:09 +0100:
> > 11.03.2005 pisze Andreas Tille (til...@rki.de):
> > > it worked. I really regard this problem as serious because it
> > > probably leaves people with SATA hardware with an unbootable
> > > system after kernel-image updates, because the kernel image
> > > packages just reinsert "root=/dev/hda?" into grub's menu.lst. Any
> > > idea how to solve this problem?
> > ...by using partition labels in fstab?
> Is there any solution for swap partitions since they do not support
> labels, AFAIK.
The mkswap version from unstable (util-linux version 2.12p-2) supports
labels, the sarge one (util-linux 2.12-10) does not. Well, that's a
pity.
Best regards,
Jubal
--
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ]
''He was so narrow minded he could see through a keyhole with both
eyes...''
And btw. the kernel has no support for mounting rootfs by label or uuid.
AFAIK RedHat uses a patch to support it.
The updates do _what_? Rather than changing that entry in grub's
list, find the section like this:
## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specifiv kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
# kopt=root=/dev/ide/host0/bus0/target0/lun0/part5 ro
and change that last line to be: (Assuming your 2.4 kernel is 2.4.27)
# kopt=root=/dev/sda3 ro
# kopt_2_4_27=root=/dev/hda3 ro
and run update-grub. That should autogenerate the grub-used sections
-- the ones without any '#' in front, after
## ## End Default Options ##
And future 2.6 installs will get the right device (the sda one)
and if you install any further 2.4 kernels you'll have to make
another "# kopt_2_4_xx=root=/dev/hda3 ro" line and rerun update-grub.
You can check the output in the lower section, and make sure it's
generating sensible grub entries.
The use labels for the rest of your data partitions, and... I dunno,
put both /dev/hda3 and /dev/sda3 in your swap list? Let your 2.4
kernel boot without swap until you manually activate it? Solve to
taste, and serve with a side of "I hope that helps".
^_^
Hmm. This assumes you're using update-grub and the Debian-supplied/
maintained grub/menu.lst. If not, then... well, don't lose your paddle.
I gave some of the relevant people in the d-i team an education on the
benefits of filesystem labels, to to the point where partman will create
filesystems with a label, however I didn't manage to convince them to mount
by the label in /etc/fstab
regards
Andrew
--
linux.conf.au 2005 - http://linux.conf.au/ - Birthplace of Tux
April 18th to 23rd - http://linux.conf.au/ - LINUX
Canberra, Australia - http://linux.conf.au/ - Get bitten!
>> Sorry, I do not know anything about partition labels but if this is
>> the solution it should be done in the installer and if this works in
>> Grub menu.lst this should be done here as well.
>
> I gave some of the relevant people in the d-i team an education on the
> benefits of filesystem labels, to to the point where partman will create
> filesystems with a label, however I didn't manage to convince them to mount
> by the label in /etc/fstab
Well, may be it sounds convincible to file RC bugs for beeing left with
an unbootable system on SATA machines? But I did not tried with RC3
candidates and I will not have the chance to do this installation
tests with my main working horse ...
Kind regards
Andreas.
package: partman
Cheers,
FJP
I don't know if my opinion counts but I _did_ notice that d-i creates
labels, and at the same time broke my parallel Red-Hat FC2 installation,
which all of soudain tried to use my debian root partition (LABEL=/) as
its own root partition, without luck of course, and with a lot of really
strange error messages.
It took me quite a while to figure out the problem, so here is the
message: labels do only properly work at install time, if no other
system is using them as well.
(and, no, I didn't think about posting a bug, but I can do. Against
which package actually?)
Thanks, Eric
Andrew Pollock wrote:
> On Fri, Mar 11, 2005 at 01:20:00PM +0100, Andreas Tille wrote:
>
>>On Fri, 11 Mar 2005, Miros/law Baran wrote:
>>
>>
>>>>it worked. I really regard this problem as serious because it
>>>>probably leaves people with SATA hardware with an unbootable system
>>>>after kernel-image updates, because the kernel image packages just
>>>>reinsert "root=/dev/hda?" into grub's menu.lst. Any idea how to
>>>>solve this problem?
>>>
>>>...by using partition labels in fstab?
>>
>>Sorry, I do not know anything about partition labels but if this is
>>the solution it should be done in the installer and if this works in
>>Grub menu.lst this should be done here as well.
>>
>
>
> I gave some of the relevant people in the d-i team an education on the
> benefits of filesystem labels, to to the point where partman will create
> filesystems with a label, however I didn't manage to convince them to mount
> by the label in /etc/fstab
>
> regards
>
> Andrew
>
--
Gewalt ist die letzte Zuflucht der Inkompetenz.
Violence is the Last Resort of the Incompetent.
Gwalt jest ostatnem schronieniem niekompetencji.
La violence est le dernier refuge de l'incompetence.
~ Isaac Asimov