[Cooker] Kernel 2.6.24 booting harddisks as /dev/sdx, why?

[Steve Morris-5]

libATA was not used until the 2.6.25 kernels which was when the device
names changed to /dev/sdx. So why is kernel 2.6.24 now booting hard
disks on the motherboard ide ports as /dev/sdx? The slave hard disk on
the second ide port of my IT8212 pci card is still referenced as
/dev/hdd, presumably meaning the device cannot be referenced as
/dev/sdx, which also presumably means that the 2.6.26 kernels which do
not support /dev/hdx are not going to be able to handle this device,
which probably explains why the 2.6.26 kernels abort their boot process
when they try to detect this device. What can be done to rectify this
situation when removing the IT8212 card is not an option?

regards,
Steve


[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Felix Miata]

On 2008/07/17 22:29 (GMT+1000) Steve Morris apparently typed:

> libATA was not used until the 2.6.25 kernels which was when the device
> names changed to /dev/sdx. So why is kernel 2.6.24 now booting hard
> disks on the motherboard ide ports as /dev/sdx? The slave hard disk on
> the second ide port of my IT8212 pci card is still referenced as
> /dev/hdd, presumably meaning the device cannot be referenced as
> /dev/sdx, which also presumably means that the 2.6.26 kernels which do
> not support /dev/hdx are not going to be able to handle this device,
> which probably explains why the 2.6.26 kernels abort their boot process
> when they try to detect this device. What can be done to rectify this
> situation when removing the IT8212 card is not an option?

I think you'll find updating has somewhere along the way overwritten your
original 2.6.24 initrd, switching it from /dev/hdx to /dev/sdx. Legacy IDE
support remains in the 2.6.25 & 2.6.26 kernels. Just rebuild your initrds
with initrd --preload= appropriate legacy driver, and you'll be accessing /
on /dev/hdx instead of /dev/sdx, and your IT8212 should remain happy. To
install to /dev/hdx, noauto on cmdline still allowed to manually select which
ide driver to load first last I checked.
--
"Do not let the sun go down while you are still angry."
                                Ephesians 4:26 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/

[Steve Morris-5]

Felix Miata wrote:

> On 2008/07/17 22:29 (GMT+1000) Steve Morris apparently typed:
>
>  
>> libATA was not used until the 2.6.25 kernels which was when the device
>> names changed to /dev/sdx. So why is kernel 2.6.24 now booting hard
>> disks on the motherboard ide ports as /dev/sdx? The slave hard disk on
>> the second ide port of my IT8212 pci card is still referenced as
>> /dev/hdd, presumably meaning the device cannot be referenced as
>> /dev/sdx, which also presumably means that the 2.6.26 kernels which do
>> not support /dev/hdx are not going to be able to handle this device,
>> which probably explains why the 2.6.26 kernels abort their boot process
>> when they try to detect this device. What can be done to rectify this
>> situation when removing the IT8212 card is not an option?
>>    
>
> I think you'll find updating has somewhere along the way overwritten your
> original 2.6.24 initrd, switching it from /dev/hdx to /dev/sdx. Legacy IDE
> support remains in the 2.6.25 & 2.6.26 kernels. Just rebuild your initrds
> with initrd --preload= appropriate legacy driver, and you'll be accessing /
> on /dev/hdx instead of /dev/sdx, and your IT8212 should remain happy. To
> install to /dev/hdx, noauto on cmdline still allowed to manually select which
> ide driver to load first last I checked.
>  

Thanks Felix. The problem turned out to not be an overwriting of the

2.6.24 initrd, but the fact that the install of kernel
2.6.26-desktop-0.rc9.1mnb (which stuffed grub entries) linked the
symlinks initrd.img and initrd-desktop.img to its initrd, and booting
off the 2.6.24 kernel is not changing the symlinks to point to the
2.6.24 img files (system.map and config are being correctly changed), so
there is now a fundamental flaw in initrd processing in cooker.

regards,
Steve


[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Steve Morris-5]

Steve Morris wrote:

> Felix Miata wrote:
>> On 2008/07/17 22:29 (GMT+1000) Steve Morris apparently typed:
>>
>>  
>>> libATA was not used until the 2.6.25 kernels which was when the
>>> device names changed to /dev/sdx. So why is kernel 2.6.24 now
>>> booting hard disks on the motherboard ide ports as /dev/sdx? The
>>> slave hard disk on the second ide port of my IT8212 pci card is
>>> still referenced as /dev/hdd, presumably meaning the device cannot
>>> be referenced as /dev/sdx, which also presumably means that the
>>> 2.6.26 kernels which do not support /dev/hdx are not going to be
>>> able to handle this device, which probably explains why the 2.6.26
>>> kernels abort their boot process when they try to detect this
>>> device. What can be done to rectify this situation when removing the
>>> IT8212 card is not an option?
>>>    
>>
>> I think you'll find updating has somewhere along the way overwritten
>> your
>> original 2.6.24 initrd, switching it from /dev/hdx to /dev/sdx.
>> Legacy IDE
>> support remains in the 2.6.25 & 2.6.26 kernels. Just rebuild your
>> initrds
>> with initrd --preload= appropriate legacy driver, and you'll be
>> accessing /
>> on /dev/hdx instead of /dev/sdx, and your IT8212 should remain happy. To
>> install to /dev/hdx, noauto on cmdline still allowed to manually
>> select which
>> ide driver to load first last I checked.
>>  
> Thanks Felix. The problem turned out to not be an overwriting of the
> 2.6.24 initrd, but the fact that the install of kernel
> 2.6.26-desktop-0.rc9.1mnb (which stuffed grub entries) linked the
> symlinks initrd.img and initrd-desktop.img to its initrd, and booting
> off the 2.6.24 kernel is not changing the symlinks to point to the
> 2.6.24 img files (system.map and config are being correctly changed),
> so there is now a fundamental flaw in initrd processing in cooker.

Sorry Felix, I have just rebooted after changing the two symlinks to

point to the correct initrd file, and nothing has changed.
What module do I specify in the preload parm to get /dev/hdx
functionality back again.

regards,
Steve

>
> regards,
> Steve
>

[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Felix Miata]

On 2008/07/18 07:13 (GMT+1000) Steve Morris apparently typed:

> Sorry Felix, I have just rebooted after changing the two symlinks to
> point to the correct initrd file, and nothing has changed.

Nothing, even the timestamp on the 2.6.24 initrd? The symlinks are nothing
but conveniences to keep menu.lst lines shorter or reducing typing if using a
grub prompt. You can manually symlink to whatever you want, such as
initrd-2.6.24-4mdv-8212bak.img -> initrd-prev.img.

> What module do I specify in the preload parm to get /dev/hdx
> functionality back again.

Depends on motherboard chipset. If off Intel controller, its piix. If you're
booting directly off the IT8212 it's it821x. For NForce2, it's amd74xx. If
other AMD or VIA or other, you'll have probably to figure it out without my help.
--
"Do not let the sun go down while you are still angry."
                                Ephesians 4:26 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/

[Luiz Fernando N. Capitulino]

Em Fri, 18 Jul 2008 07:13:57 +1000
Steve Morris <samorris@...> escreveu:

| Steve Morris wrote:
| > Felix Miata wrote:
| >> On 2008/07/17 22:29 (GMT+1000) Steve Morris apparently typed:
| >>
| >>  
| >>> libATA was not used until the 2.6.25 kernels which was when the
| >>> device names changed to /dev/sdx. So why is kernel 2.6.24 now
| >>> booting hard disks on the motherboard ide ports as /dev/sdx? The
| >>> slave hard disk on the second ide port of my IT8212 pci card is
| >>> still referenced as /dev/hdd, presumably meaning the device cannot
| >>> be referenced as /dev/sdx, which also presumably means that the
| >>> 2.6.26 kernels which do not support /dev/hdx are not going to be
| >>> able to handle this device, which probably explains why the 2.6.26
| >>> kernels abort their boot process when they try to detect this
| >>> device. What can be done to rectify this situation when removing the
| >>> IT8212 card is not an option?
| >>>    
| >>
| >> I think you'll find updating has somewhere along the way overwritten
| >> your
| >> original 2.6.24 initrd, switching it from /dev/hdx to /dev/sdx.
| >> Legacy IDE
| >> support remains in the 2.6.25 & 2.6.26 kernels. Just rebuild your
| >> initrds
| >> with initrd --preload= appropriate legacy driver, and you'll be
| >> accessing /
| >> on /dev/hdx instead of /dev/sdx, and your IT8212 should remain happy. To
| >> install to /dev/hdx, noauto on cmdline still allowed to manually
| >> select which
| >> ide driver to load first last I checked.
| >>  
| > Thanks Felix. The problem turned out to not be an overwriting of the
| > 2.6.24 initrd, but the fact that the install of kernel
| > 2.6.26-desktop-0.rc9.1mnb (which stuffed grub entries) linked the
| > symlinks initrd.img and initrd-desktop.img to its initrd, and booting
| > off the 2.6.24 kernel is not changing the symlinks to point to the
| > 2.6.24 img files (system.map and config are being correctly changed),
| > so there is now a fundamental flaw in initrd processing in cooker.
| Sorry Felix, I have just rebooted after changing the two symlinks to
| point to the correct initrd file, and nothing has changed.
| What module do I specify in the preload parm to get /dev/hdx
| functionality back again.

 Man, either you have screwed up your system or you have triggered
a bug we are not aware of.

 I should also say that your reports are a bit confusing, at least
for me.

 Could you please, describe in a simple way what the first problem
you have got was?

 I have asked our QA team to begin a series of tests to try to
reproduce the problem you are reporting. They are going to try
all possible cases (alpha2 installs, upgrades, etc).

 Regards.

--
Luiz Fernando N. Capitulino

[Steve Morris-5]

Luiz Fernando N. Capitulino wrote:

> Em Fri, 18 Jul 2008 07:13:57 +1000
> Steve Morris <samorris@...> escreveu:
>
> | Steve Morris wrote:
> | > Felix Miata wrote:
> | >> On 2008/07/17 22:29 (GMT+1000) Steve Morris apparently typed:
> | >>
> | >>  
> | >>> libATA was not used until the 2.6.25 kernels which was when the
> | >>> device names changed to /dev/sdx. So why is kernel 2.6.24 now
> | >>> booting hard disks on the motherboard ide ports as /dev/sdx? The
> | >>> slave hard disk on the second ide port of my IT8212 pci card is
> | >>> still referenced as /dev/hdd, presumably meaning the device cannot
> | >>> be referenced as /dev/sdx, which also presumably means that the
> | >>> 2.6.26 kernels which do not support /dev/hdx are not going to be
> | >>> able to handle this device, which probably explains why the 2.6.26
> | >>> kernels abort their boot process when they try to detect this
> | >>> device. What can be done to rectify this situation when removing the
> | >>> IT8212 card is not an option?
> | >>>    
> | >>
> | >> I think you'll find updating has somewhere along the way overwritten
> | >> your
> | >> original 2.6.24 initrd, switching it from /dev/hdx to /dev/sdx.
> | >> Legacy IDE
> | >> support remains in the 2.6.25 & 2.6.26 kernels. Just rebuild your
> | >> initrds
> | >> with initrd --preload= appropriate legacy driver, and you'll be
> | >> accessing /
> | >> on /dev/hdx instead of /dev/sdx, and your IT8212 should remain happy. To
> | >> install to /dev/hdx, noauto on cmdline still allowed to manually
> | >> select which
> | >> ide driver to load first last I checked.
> | >>  
> | > Thanks Felix. The problem turned out to not be an overwriting of the
> | > 2.6.24 initrd, but the fact that the install of kernel
> | > 2.6.26-desktop-0.rc9.1mnb (which stuffed grub entries) linked the
> | > symlinks initrd.img and initrd-desktop.img to its initrd, and booting
> | > off the 2.6.24 kernel is not changing the symlinks to point to the
> | > 2.6.24 img files (system.map and config are being correctly changed),
> | > so there is now a fundamental flaw in initrd processing in cooker.
> | Sorry Felix, I have just rebooted after changing the two symlinks to
> | point to the correct initrd file, and nothing has changed.
> | What module do I specify in the preload parm to get /dev/hdx
> | functionality back again.
>
>  Man, either you have screwed up your system or you have triggered
> a bug we are not aware of.
>
>  I should also say that your reports are a bit confusing, at least
> for me.
>
>  Could you please, describe in a simple way what the first problem
> you have got was?
>
>  I have asked our QA team to begin a series of tests to try to
> reproduce the problem you are reporting. They are going to try
> all possible cases (alpha2 installs, upgrades, etc).
>
>  Regards.
>
>  

Sorry Luiz, here goes.

My first issue was highlighted by a 'df -h' command which provided the
following output:

df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb5              37G   33G  4.1G  89% /
/dev/hdd1             403M  2.8M  400M   1% /mnt/acronis
/dev/hdd5             2.0G  496M  1.6G  25% /mnt/interface
/dev/sda1              37G   33G  4.0G  90% /mnt/vista
none                  506M   28K  506M   1% /tmp

The two /dev/sdx disks are ide devices plugged into the ide ports on the
motherboard. As I am using the 2.6.24 kernel these should be /dev/hdx,
as libATA was not migrated to until kernel 2.6.5 onwards.

My second issue was the Felix suggested that the problem with the hard
disks being /dev/sdx instead of /dev/hdx was probably that the initrd
images had been overwritten. When I checked in /boot the initrd symlinks
were pointing at the initrds for kernel 2.6.26-desktop-0.rc9.1mnb even
though I was booting off the 2.6.24 kernel. The system.map and config
symlinks were correctly pointing at the 2.6.24 equivalents, but initrd
was not. I relinked the initrd symlinks to point to the 2.6.24
equivalents, but when I rebooted after this change the two motherboard
hard disks were still /dev/sdx.

My third problem was that the installation of the 2.6.26-9 kernel
changed all the (hd1,x) entries in grub's menu.lst to (hd2,x) hence grub
could not find anything. I also had a couple of entries for windows
systems in menu.lst which the kernel install removed as well.

regards,
Steve


[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Felix Miata]

On 2008/07/19 23:01 (GMT+1000) Steve Morris apparently typed:

> Luiz Fernando N. Capitulino wrote:

>>  Man, either you have screwed up your system or you have triggered
>> a bug we are not aware of.

>>  I should also say that your reports are a bit confusing, at least
>> for me.

>>  Could you please, describe in a simple way what the first problem
>> you have got was?

>>  I have asked our QA team to begin a series of tests to try to
>> reproduce the problem you are reporting. They are going to try
>> all possible cases (alpha2 installs, upgrades, etc).

> My first issue was highlighted by a 'df -h' command which provided the
> following output:

> df -h
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sdb5              37G   33G  4.1G  89% /
> /dev/hdd1             403M  2.8M  400M   1% /mnt/acronis
> /dev/hdd5             2.0G  496M  1.6G  25% /mnt/interface

The above has me puzzled. I'd expect the it8212 devices to start with hdc or
hde. Do you have the hdd HD slaved to an optical device? That's something I'd
never do, being far more trusting of a HD controller to optimally manage an
optical than the other way around.

> /dev/sda1              37G   33G  4.0G  90% /mnt/vista
> none                  506M   28K  506M   1% /tmp

Same size of both total and used for both / and Vista, and so little
freespace on both? Yikes.

> The two /dev/sdx disks are ide devices plugged into the ide ports on the
> motherboard. As I am using the 2.6.24 kernel these should be /dev/hdx,
> as libATA was not migrated to until kernel 2.6.5 onwards.

What motherboard manufacturer/model/chipset? (aka, is there one IDE channel,
or two, on the non-it8212 IDE controller?)

> My second issue was the Felix suggested that the problem with the hard
> disks being /dev/sdx instead of /dev/hdx was probably that the initrd
> images had been overwritten.

Exactly, and you've yet to answer my question. The symlinks probably have
nothing to do with the root problem, which is a mkinitrd behaving similarly
to https://qa.mandriva.com/show_bug.cgi?id=41825 where the switch from legacy
to libata is mishandled for your system's hardware configuration. The answer
should lie in the timestamps on the initrds. When was the 2.6.24 kernel
installed, and when was its last initrd timestamped? Do you have an initrd
backup for 2.6.24? If so, you need to try it.

> When I checked in /boot the initrd symlinks
> were pointing at the initrds for kernel 2.6.26-desktop-0.rc9.1mnb even
> though I was booting off the 2.6.24 kernel. The system.map and config
> symlinks were correctly pointing at the 2.6.24 equivalents, but initrd
> was not. I relinked the initrd symlinks to point to the 2.6.24
> equivalents, but when I rebooted after this change the two motherboard
> hard disks were still /dev/sdx.

When you get a good initrd/kernel combination, you should back them up
locally, adding special symlinks if that suits you, and a custom stanza in
menu.lst, so that errant installation scripts and config files don't kill
your ability to boot. Whatever non-expected names you assign to the backup
protects them against errant installation scripts rendering them useless. e.g.:

title Mandriva Cooker (2.6.24 w/ backup initrd)
kernel (hd0,22)/boot/vmlinuz-2.6.24-1mdv root=LABEL=hda05cooker vga=791 noresume
initrd (hd0,22)/boot/initrd-ok-2.6.24-1mdv.img

Note the LABEL= above. That's your ticket to no need to care what /dev name
is assigned to your / partition. Set it with tune2fs -L, use that label in
fstab and menu.lst, and the /dev assignment shouldn't matter, as long as you
don't need access to partitions >15 per HD.

> My third problem was that the installation of the 2.6.26-9 kernel
> changed all the (hd1,x) entries in grub's menu.lst to (hd2,x) hence grub
> could not find anything.

Everyone running alpha or beta OS versions should spend some time at a grub
prompt so as to understand how to bail from menu.lst errors without forcing a
rescue boot. As long as usable kernels and initrds exist somewhere grub can
find them, you can use the grub command line to load them and achieve a
normal init.
--
"Do not let the sun go down while you are still angry."
                                Ephesians 4:26 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/

[Steve Morris-5]

Felix Miata wrote:

>> My first issue was highlighted by a 'df -h' command which provided the
>> following output:
>>    
>> df -h
>> Filesystem            Size  Used Avail Use% Mounted on
>> /dev/sdb5              37G   33G  4.1G  89% /
>> /dev/hdd1             403M  2.8M  400M   1% /mnt/acronis
>> /dev/hdd5             2.0G  496M  1.6G  25% /mnt/interface
>>    
>
> The above has me puzzled. I'd expect the it8212 devices to start with hdc or
> hde. Do you have the hdd HD slaved to an optical device? That's something I'd
> never do, being far more trusting of a HD controller to optimally manage an
> optical than the other way around.
>
>  

On the IT8212 I have an optical device as the primary device on the

first port, and is the only device on that port, and I have a 2.5GB hard
disk as the slave device on the second port and it is the only device on
this port.
>> /dev/sda1              37G   33G  4.0G  90% /mnt/vista
>> none                  506M   28K  506M   1% /tmp
>>    
>
> Same size of both total and used for both / and Vista, and so little
> freespace on both? Yikes.
>
>  
The /mnt/vista mount is actually Windows XP and yes, it is actually
quite full. The / partition has had free space increased as there were
some old disk isos and a windows game that have been deleted to give me
13 GB free.
>> The two /dev/sdx disks are ide devices plugged into the ide ports on the
>> motherboard. As I am using the 2.6.24 kernel these should be /dev/hdx,
>> as libATA was not migrated to until kernel 2.6.5 onwards.
>>    
>
> What motherboard manufacturer/model/chipset? (aka, is there one IDE channel,
> or two, on the non-it8212 IDE controller?)
>
>  
I am not sure what the motherboard is, but I think it is a KTX400 with a
VIA chipset. The IT8212 has two IDE channels, it is actually a Raid card
with Raid capabilities removed.

>> My second issue was the Felix suggested that the problem with the hard
>> disks being /dev/sdx instead of /dev/hdx was probably that the initrd
>> images had been overwritten.
>>    
>
> Exactly, and you've yet to answer my question. The symlinks probably have
> nothing to do with the root problem, which is a mkinitrd behaving similarly
> to https://qa.mandriva.com/show_bug.cgi?id=41825 where the switch from legacy
> to libata is mishandled for your system's hardware configuration. The answer
> should lie in the timestamps on the initrds. When was the 2.6.24 kernel
> installed, and when was its last initrd timestamped? Do you have an initrd
> backup for 2.6.24? If so, you need to try it.
>
>  

I don't have a backup of the initrd, but issuing an ll /boot the 2.6.24

kernel has a timestamp of 2008-03-28 00:37, the associated initrd has a
timestamp of 2008-07-12 18:19 which matches the timestamp on
initrd-2.6.26-desktop-0.rc8.1mnb.img, so maybe the installation of the
2.6.26-rc8.1 kernel caused the 2.6.24 initrd to be overwritten. The
issue now is trying to find out what module needs to be preloaded for
the VIA chipset, as drakconf doesn't run because of issue with
understanding png formats since the last cooker update.

>> When I checked in /boot the initrd symlinks
>> were pointing at the initrds for kernel 2.6.26-desktop-0.rc9.1mnb even
>> though I was booting off the 2.6.24 kernel. The system.map and config
>> symlinks were correctly pointing at the 2.6.24 equivalents, but initrd
>> was not. I relinked the initrd symlinks to point to the 2.6.24
>> equivalents, but when I rebooted after this change the two motherboard
>> hard disks were still /dev/sdx.
>>    
>
> When you get a good initrd/kernel combination, you should back them up
> locally, adding special symlinks if that suits you, and a custom stanza in
> menu.lst, so that errant installation scripts and config files don't kill
> your ability to boot. Whatever non-expected names you assign to the backup
> protects them against errant installation scripts rendering them useless. e.g.:
>
> title Mandriva Cooker (2.6.24 w/ backup initrd)
> kernel (hd0,22)/boot/vmlinuz-2.6.24-1mdv root=LABEL=hda05cooker vga=791 noresume
> initrd (hd0,22)/boot/initrd-ok-2.6.24-1mdv.img
>
> Note the LABEL= above. That's your ticket to no need to care what /dev name
> is assigned to your / partition. Set it with tune2fs -L, use that label in
> fstab and menu.lst, and the /dev assignment shouldn't matter, as long as you
> don't need access to partitions >15 per HD.
>
>  

I will create backups once I get good copies, but I will have to use

UUID rather than LABEL as tune2fs will only place labels on unmounted
disks and I don't have any mechanism to unmount the root partition, as
tune2fs is not available on the Mandriva recovery facility on the boot cd.

>> My third problem was that the installation of the 2.6.26-9 kernel
>> changed all the (hd1,x) entries in grub's menu.lst to (hd2,x) hence grub
>> could not find anything.
>>    
>
> Everyone running alpha or beta OS versions should spend some time at a grub
> prompt so as to understand how to bail from menu.lst errors without forcing a
> rescue boot. As long as usable kernels and initrds exist somewhere grub can
> find them, you can use the grub command line to load them and achieve a
> normal init.
>  

I was able to recover from this via the menu.lst edit facility provided

by grub at the kernel select prompt, but the issue is that the kernel
install should not have changed them in the first place, nor should it
have removed the non-linux (windows) entries that were there as well.

regards,
Steve


[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Felix Miata]

On 2008/07/20 12:22 (GMT+1000) Steve Morris apparently typed:

> On the IT8212 I have an optical device as the primary device on the
> first port, and is the only device on that port, and I have a 2.5GB hard
> disk as the slave device on the second port and it is the only device on
> this port.

I have a motherboard with it8212 that needs some new caps. If successful with
replacement, I'll try a naked slave on it like you're doing, but they aren't
supposed to work properly that way. I'd move that HD to a primary if it was
mine even if it does work, unless I could see some doc that explains how
that's OK in contrast to other IDE controllers.

> I am not sure what the motherboard is, but I think it is a KTX400 with a
> VIA chipset.

That's almost certainly via82cxxx.

> The IT8212 has two IDE channels, it is actually a Raid card
> with Raid capabilities removed.

> I don't have a backup of the initrd, but issuing an ll /boot the 2.6.24
> kernel has a timestamp of 2008-03-28 00:37, the associated initrd has a
> timestamp of 2008-07-12 18:19 which matches the timestamp on
> initrd-2.6.26-desktop-0.rc8.1mnb.img, so maybe the installation of the
> 2.6.26-rc8.1 kernel caused the 2.6.24 initrd to be overwritten.

You don't need to install a new kernel to get your initrds rewritten. Any
number of upgrades to important things like udev and to silly things like
themes and boot splashes can cause those catastrophic rewrites. Lately it
seems many things are causing rewrites. If it was up to me, none but the
newest kernel's initrd would ever get rewritten automatically, and even then
I think there ought to be some warning or opt out offered.

> The
> issue now is trying to find out what module needs to be preloaded for
> the VIA chipset, as drakconf doesn't run because of issue with
> understanding png formats since the last cooker update.

See above.

> I will create backups once I get good copies, but I will have to use
> UUID rather than LABEL as tune2fs will only place labels on unmounted
> disks and I don't have any mechanism to unmount the root partition, as
> tune2fs is not available on the Mandriva recovery facility on the boot cd.

Any live CD with a normal toolset can be used to run tune2fs, and edit
menu.lst. I usually use Knoppix, as its creators are astute enough to include
MC and make recovery operations much easier, and without any need for a
working X.

> I was able to recover from this via the menu.lst edit facility provided
> by grub at the kernel select prompt,

If you've "recovered", I'm not sure I understand the reason for most of
what's in this thread. What exactly did you recover?
--
"Do not let the sun go down while you are still angry."
                                Ephesians 4:26 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/

[Andrey Borzenkov]

Felix Miata wrote:

>> I will create backups once I get good copies, but I will have to use
>> UUID rather than LABEL as tune2fs will only place labels on unmounted
>> disks


{pts/1}% mount | grep loop
/dev/loop0 on /home/bor/tmp/test type ext2 (rw)
{pts/1}% sudo tune2fs -l /dev/loop0 | grep 'volume name'
Filesystem volume name:   xxx
{pts/1}% sudo tune2fs -L YYY /dev/loop0
tune2fs 1.40.8 (13-Mar-2008)
{pts/1}% sudo tune2fs -l /dev/loop0 | grep 'volume name'
Filesystem volume name:   YYY

[Steve Morris-5]

Felix Miata wrote:

> On 2008/07/20 12:22 (GMT+1000) Steve Morris apparently typed:
>
>  
>> On the IT8212 I have an optical device as the primary device on the
>> first port, and is the only device on that port, and I have a 2.5GB hard
>> disk as the slave device on the second port and it is the only device on
>> this port.
>>    
>
> I have a motherboard with it8212 that needs some new caps. If successful with
> replacement, I'll try a naked slave on it like you're doing, but they aren't
> supposed to work properly that way. I'd move that HD to a primary if it was
> mine even if it does work, unless I could see some doc that explains how
> that's OK in contrast to other IDE controllers.
>
>  

I can't make the hard disk a primary as it doesn't have any jumpers on

it to switch it from a slave, and I can't find any in retail stores or
the local swap meet that will fit it so that I can make it a master. I
have not had any issues with its functionality until the 2.6.26 kernels
which seem to fail on this device (I will need to write down the kernel
invalid null pointer error message as a digital picture is unreadable).
As an aside to this on my motherboard ports I have 'optical drive, hard
disk' and 'optical drive, hard disk' which used to be the recommended
configuration.

>> I am not sure what the motherboard is, but I think it is a KTX400 with a
>> VIA chipset.
>>    
>
> That's almost certainly via82cxxx.
>
>  
>> The IT8212 has two IDE channels, it is actually a Raid card
>> with Raid capabilities removed.
>>    
>
>  
>> I don't have a backup of the initrd, but issuing an ll /boot the 2.6.24
>> kernel has a timestamp of 2008-03-28 00:37, the associated initrd has a
>> timestamp of 2008-07-12 18:19 which matches the timestamp on
>> initrd-2.6.26-desktop-0.rc8.1mnb.img, so maybe the installation of the
>> 2.6.26-rc8.1 kernel caused the 2.6.24 initrd to be overwritten.
>>    
>
> You don't need to install a new kernel to get your initrds rewritten. Any
> number of upgrades to important things like udev and to silly things like
> themes and boot splashes can cause those catastrophic rewrites. Lately it
> seems many things are causing rewrites. If it was up to me, none but the
> newest kernel's initrd would ever get rewritten automatically, and even then
> I think there ought to be some warning or opt out offered.
>
>  
>> The
>> issue now is trying to find out what module needs to be preloaded for
>> the VIA chipset, as drakconf doesn't run because of issue with
>> understanding png formats since the last cooker update.
>>    
>
> See above.
>  

Thanks Felix I will try rebuilding the 2.6.24 initrd with this.

>  
>> I will create backups once I get good copies, but I will have to use
>> UUID rather than LABEL as tune2fs will only place labels on unmounted
>> disks and I don't have any mechanism to unmount the root partition, as
>> tune2fs is not available on the Mandriva recovery facility on the boot cd.
>>    
>
> Any live CD with a normal toolset can be used to run tune2fs, and edit
> menu.lst. I usually use Knoppix, as its creators are astute enough to include
> MC and make recovery operations much easier, and without any need for a
> working X.
>
>  

I will have a look at this and see how it goes. I had already set the

root device to 'root=UUID' manually on all the 2.6.26 kernels, and left
the entry as 'root=/dev/hd5' on the 2.6.24 kernel because it was happy
with that (this enabled me to easily switch between the 2.6.24 kernel
and the 2.6.26 kernels when trying to test if they would boot), but the
install of the RC9.1 kernel appears to have overwritten the 2.6.24 entry
in menu.lst with 'root=UUID' as well.
>> I was able to recover from this via the menu.lst edit facility provided
>> by grub at the kernel select prompt,
>>    
>
> If you've "recovered", I'm not sure I understand the reason for most of
> what's in this thread. What exactly did you recover?
>  
I was able to use this edit facility to change all the (hd2,x) entries
back to (hd1,x) entries so that grub could actually boot.

[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Steve Morris-5]

Andrey Borzenkov wrote:

> Felix Miata wrote:
>
>  
>>> I will create backups once I get good copies, but I will have to use
>>> UUID rather than LABEL as tune2fs will only place labels on unmounted
>>> disks
>>>      
>
>
> {pts/1}% mount | grep loop
> /dev/loop0 on /home/bor/tmp/test type ext2 (rw)
> {pts/1}% sudo tune2fs -l /dev/loop0 | grep 'volume name'
> Filesystem volume name:   xxx
> {pts/1}% sudo tune2fs -L YYY /dev/loop0
> tune2fs 1.40.8 (13-Mar-2008)
> {pts/1}% sudo tune2fs -l /dev/loop0 | grep 'volume name'
> Filesystem volume name:   YYY
>
>  

Thanks Andre, when I tried that on / tune2fs came back to told me it

couldn't process a mounted device.

regards,
Steve

>
>  

[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Felix Miata]

On 2008/07/21 07:17 (GMT+1000) Steve Morris apparently typed:

> I can't make the hard disk a primary as it doesn't have any jumpers on
> it to switch it from a slave, and I can't find any in retail stores or
> the local swap meet that will fit it so that I can make it a master.

There should be some hole in the wall puter repair guy in your vicinity with
a bucket of them, or if he's typical, have them laying all around on the tops
of his work benches, or still installed on broken parts laying about for
robbing parts to fix other things.

All you need is to connect the two pins. Lacking a normal jumper, you could
just wrap the two pins several times with a strand of copper wire, and add a
tiny drop of solder or small piece of tape as a retainer.
--
"Do not let the sun go down while you are still angry."
                                Ephesians 4:26 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/

[Steve Morris-5]

Steve Morris wrote:

> Felix Miata wrote:
>>> My first issue was highlighted by a 'df -h' command which provided
>>> the following output:
>>>     df -h
>>> Filesystem            Size  Used Avail Use% Mounted on
>>> /dev/sdb5              37G   33G  4.1G  89% /
>>> /dev/hdd1             403M  2.8M  400M   1% /mnt/acronis
>>> /dev/hdd5             2.0G  496M  1.6G  25% /mnt/interface
>>>    
>>
>> The above has me puzzled. I'd expect the it8212 devices to start with
>> hdc or
>> hde. Do you have the hdd HD slaved to an optical device? That's
>> something I'd
>> never do, being far more trusting of a HD controller to optimally
>> manage an
>> optical than the other way around.
>>
>>  
> On the IT8212 I have an optical device as the primary device on the
> first port, and is the only device on that port, and I have a 2.5GB
> hard disk as the slave device on the second port and it is the only
> device on this port.
>>> /dev/sda1              37G   33G  4.0G  90% /mnt/vista
>>> none                  506M   28K  506M   1% /tmp
>>>    
>>
>> Same size of both total and used for both / and Vista, and so little
>> freespace on both? Yikes.
>>
>> &n