Re: Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
| But i still got the error about can finding vg_maingroup which i | believe is my main filesystem. I strongly suspect that you are trying to boot a kernel which does not include LVM support. (Partly because I had very similar problems in upgrading to 2.6.29 from 2.6.22 and this was the reason). The way that LVM support is handled in the kernel has changed. There is a separate section in the configuration menu: under Device Drivers, in a subsection called Multiple Devices Driver Support. In there (apart from all of the Raid options) there is an option called Device Mapper Support (if you configure it as a module it's called dm-mod). If this option is not enabled (as a module or otherwise) the kernel cannot boot a system whose root directory is on an LVM module. Jim -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
On Fri, Apr 3, 2009 at 2:27 PM, thveillon.debian thveillon.deb...@googlemail.com wrote: Joey L wrote : I think i did everything and this is a standard configuration - I did not do anything too crazy ! Again - all this is software raid --- the /boot is raid1 and the other volumes are software raid5 The Raid5 has LVM filesystems. here is fdisk -l : thor:/home/mjh# fdisk -l Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 36 289138+ fd Linux raid autodetect /dev/sda2 37 60801 488094862+ fd Linux raid autodetect [...snip long partitions list] On the mdadm --detail --scan --verbose : thor:/home/mjh# mdadm --detail --scan --verbose ARRAY /dev/md0 level=raid1 num-devices=2 spares=3 UUID=8a435040:c6f27178:02026e74:21deb7ac devices=/dev/sda1,/dev/sdb1,/dev/sdc1,/dev/sdd1,/dev/sde1 ARRAY /dev/md1 level=raid5 num-devices=4 spares=1 UUID=f60a4f26:891a29c2:8dbe0712:bd7a69ac devices=/dev/sda2,/dev/sdb2,/dev/sdc2,/dev/sdd2,/dev/sde2 Ok, so all partitions are of fd type, and you sure have plenty of spares on the first array ! I have to say that even not overtired ;-) I am short of ideas about what could be going wrong here. You could check that md-raid* are compiled as modules (m) in the kernel egrep -i '(raid|_md_)' /boot/config-2.6.29 Check for the initramfs scripts: ls /usr/share/initramfs-tools/scripts/local-top/ you should see at least mdadm and lvm2 Outside of this I don't know. If it boots fine with the old kernel then superblocks are fine on the arrays members, it must be a difference in kernel config or initrd. Sorry, I can't think of anything else right now, can't you spot anything else in dmesg a bit more verbose than failed to assemble all arrays ? A controller initialization problem ? Sorry - never saw your reply - I ran the command and got this: thor:~# egrep -i '(raid|_md_)' /boot/config-2.6.29 CONFIG_RAID_ATTRS=m CONFIG_BLK_DEV_3W__RAID=m CONFIG_SCSI_AACRAID=m CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m CONFIG_MEGARAID_LEGACY=m CONFIG_MEGARAID_SAS=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m CONFIG_MD_RAID5_RESHAPE=y CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m and this : thor:~# ls /usr/share/initramfs-tools/scripts/local-top/ lvm mdadm mdrun udev_helper Should make lvm part of the kernel ? thanks mjh
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
Joey L wrote : I think i did everything and this is a standard configuration - I did not do anything too crazy ! Again - all this is software raid --- the /boot is raid1 and the other volumes are software raid5 The Raid5 has LVM filesystems. here is fdisk -l : thor:/home/mjh# fdisk -l Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 36 289138+ fd Linux raid autodetect /dev/sda2 37 60801 488094862+ fd Linux raid autodetect [...snip long partitions list] On the mdadm --detail --scan --verbose : thor:/home/mjh# mdadm --detail --scan --verbose ARRAY /dev/md0 level=raid1 num-devices=2 spares=3 UUID=8a435040:c6f27178:02026e74:21deb7ac devices=/dev/sda1,/dev/sdb1,/dev/sdc1,/dev/sdd1,/dev/sde1 ARRAY /dev/md1 level=raid5 num-devices=4 spares=1 UUID=f60a4f26:891a29c2:8dbe0712:bd7a69ac devices=/dev/sda2,/dev/sdb2,/dev/sdc2,/dev/sdd2,/dev/sde2 Ok, so all partitions are of fd type, and you sure have plenty of spares on the first array ! I have to say that even not overtired ;-) I am short of ideas about what could be going wrong here. You could check that md-raid* are compiled as modules (m) in the kernel egrep -i '(raid|_md_)' /boot/config-2.6.29 Check for the initramfs scripts: ls /usr/share/initramfs-tools/scripts/local-top/ you should see at least mdadm and lvm2 Outside of this I don't know. If it boots fine with the old kernel then superblocks are fine on the arrays members, it must be a difference in kernel config or initrd. Sorry, I can't think of anything else right now, can't you spot anything else in dmesg a bit more verbose than failed to assemble all arrays ? A controller initialization problem ? Tom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
make-kpkg -rfakeroot --initrd --revision=custom.1.0 kernel_image sudo dpkg -i ../linux-image-2.6.29custom1.0_deb Maybe that should sort things out. Let me know if you face further problems. Sorry - i tried to run that command but it gave an error - something that rfakeroot is not a command..so i had to look at the man pages and came up with: make-kpkg --rootcmd fakeroot --initrd --revision=custom.1.1 kernel_image that is the exact command. and then did: sudo dpkg -i ../linux-image-2.6.29custom1.0_deb But i still got the error about can finding vg_maingroup which i believe is my main filesystem. I should tell you that i have a mirrored boot drive and then i have a raid5 setup where the rest of the operating system is on. I did go into the /boot directory and deleted the previous files: config-2.6.29 initrd.img-2.6.29 System.map-2.6.29 vmlinuz-2.6.29 and then ran: make-kpkg --rootcmd fakeroot --initrd --revision=custom.1.1 kernel_image dpkg -i ../linux-image-2.6.29custom1.0_deb as is. Is there a way to differeniate between the different kernels i am building - but using the same version?? thanks
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
Joey L a écrit : make-kpkg -rfakeroot --initrd --revision=custom.1.0 kernel_image sudo dpkg -i ../linux-image-2.6.29custom1.0_deb Maybe that should sort things out. Let me know if you face further problems. Sorry - i tried to run that command but it gave an error - something that rfakeroot is not a command..so i had to look at the man pages and came up with: make-kpkg --rootcmd fakeroot --initrd --revision=custom.1.1 kernel_image that is the exact command. and then did: sudo dpkg -i ../linux-image-2.6.29custom1.0_deb But i still got the error about can finding vg_maingroup which i believe is my main filesystem. I should tell you that i have a mirrored boot drive and then i have a raid5 setup where the rest of the operating system is on. I did go into the /boot directory and deleted the previous files: config-2.6.29 initrd.img-2.6.29 System.map-2.6.29 vmlinuz-2.6.29 and then ran: make-kpkg --rootcmd fakeroot --initrd --revision=custom.1.1 kernel_image dpkg -i ../linux-image-2.6.29custom1.0_deb as is. Is there a way to differeniate between the different kernels i am building - but using the same version?? thanks fakeroot make-kpkg --initrd --append-to-version -mykernel --revision 1 kernel-image kernel-headers Change the mykernel string and revision number to differentiate your builds. You are booting from a lvm it seems, maybe with root on lvm. Do you have a separate /boot ? Anyway, I take that you have everything needed installed (lvm2 ?) and your kernel is configured with lvm support. Another point to check is change in device naming between 2.6.18 and 2.6.29, it's likely that any hd* will become sd* with the new kernel, so change your /etc/fstab and /boot/grub/menu.lst and /boot/grub/device.map accordingly. Tom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
fakeroot make-kpkg --initrd --append-to-version -mykernel --revision 1 kernel-image kernel-headers Change the mykernel string and revision number to differentiate your builds. You are booting from a lvm it seems, maybe with root on lvm. Do you have a separate /boot ? Anyway, I take that you have everything needed installed (lvm2 ?) and your kernel is configured with lvm support. Another point to check is change in device naming between 2.6.18 and 2.6.29, it's likely that any hd* will become sd* with the new kernel, so change your /etc/fstab and /boot/grub/menu.lst and /boot/grub/device.map accordingly. Tom - thanks for the reply - Do you think that is the issue ??? I am running mirrored drives for /boot. I can not boot off of lvm. I have the rest of my drives on software raid5 and i have created lvm volume groups and put my / filesystem allong with everything else on them. Do you think the issue is that between the 2.6.18 kernel and the 2.6.29 kernel - there was a change in the drive naming convention where the hd* are now sd* ??? I am concerned if i try to change it, the system will not boot. When compiling the kernel...does this stuff not happen automatically ??? thanks
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
On Thu, Apr 2, 2009 at 1:28 PM, Joey L mjh2...@gmail.com wrote: fakeroot make-kpkg --initrd --append-to-version -mykernel --revision 1 kernel-image kernel-headers Change the mykernel string and revision number to differentiate your builds. You are booting from a lvm it seems, maybe with root on lvm. Do you have a separate /boot ? Anyway, I take that you have everything needed installed (lvm2 ?) and your kernel is configured with lvm support. Another point to check is change in device naming between 2.6.18 and 2.6.29, it's likely that any hd* will become sd* with the new kernel, so change your /etc/fstab and /boot/grub/menu.lst and /boot/grub/device.map accordingly. Tom - thanks for the reply - Do you think that is the issue ??? I am running mirrored drives for /boot. I can not boot off of lvm. I have the rest of my drives on software raid5 and i have created lvm volume groups and put my / filesystem allong with everything else on them. Do you think the issue is that between the 2.6.18 kernel and the 2.6.29 kernel - there was a change in the drive naming convention where the hd* are now sd* ??? I am concerned if i try to change it, the system will not boot. When compiling the kernel...does this stuff not happen automatically ?? I am also getting messeges that raid or array failed to assemble all arrays ?? This array is working fine under the old kernel - the 2.6.18 ... Is there somehting special in the command that i have to run for an array configuraiton with lvm thanks
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
Joey L wrote : Tom - thanks for the reply - Do you think that is the issue ??? I am running mirrored drives for /boot. I can not boot off of lvm. I have the rest of my drives on software raid5 and i have created lvm volume groups and put my / filesystem allong with everything else on them. [...]pasted here from lower by me because it relates to the same problem I am also getting messeges that raid or array failed to assemble all arrays ?? This array is working fine under the old kernel - the 2.6.18 ... Is there somehting special in the command that i have to run for an array configuraiton with lvm So you need raid1, raid456 and md_mod loaded at boot time. I use Grub2 which can load those modules even before the initrd is loaded, so if you're using grub legacy you're going to boot from one of the disks in the array, have the initrd loaded, and with it must come along raid1, raid456 and md_mod modules to assemble the arrays. I think installing mdadm should trigger the inclusion of the modules in the initrd, but if in doubt add raids and md_mod to /etc/initramfs-tools/modules echo -e raid1\nmd_mod\nraid456 /etc/initramfs-tools/modules and rebuild your initrd update-initramfs -u -k kernelversion where the kernelversion string is the target kernel version (2.6.29-mykernel), or $(uname -r) for the running kernel, or all for any possible kernel in the known universe ;-) It's also a good idea to have the partition type of the arrays members set to fd (raid-autodetect) if it's already done. I don't use lvm, but I think the important thing is to get your arrays up, the lvm initialization is done through /etc/init.d/lvm I believe. Do you think the issue is that between the 2.6.18 kernel and the 2.6.29 kernel - there was a change in the drive naming convention where the hd* are now sd* ??? I am concerned if i try to change it, the system will not boot. When compiling the kernel...does this stuff not happen automatically ??? A change occurred in kernel 2.6.19 and up which triggers the naming convention to shift from hd* to sd* for most configurations. Since several configuration files relies on this naming convention it's a good idea to check (fstab, mtab, menu.lst and device.map). A good way around this in fstab, mtab and menu.lst is using labels or UUID. It doesn't (at least always) happen automatically in my painful experience ! If you change that (hd* to sd*) and try to boot on the old kernel, you're heading to a nice black screen... Use UUID's or labels to avoid the need to shift configuration files in between boot attempts. thanks Hope it helps. Tom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
On Thu, Apr 2, 2009 at 5:22 PM, thveillon.debian thveillon.deb...@googlemail.com wrote: Joey L wrote : Tom - thanks for the reply - Do you think that is the issue ??? I am running mirrored drives for /boot. I can not boot off of lvm. I have the rest of my drives on software raid5 and i have created lvm volume groups and put my / filesystem allong with everything else on them. [...]pasted here from lower by me because it relates to the same problem I am also getting messeges that raid or array failed to assemble all arrays ?? This array is working fine under the old kernel - the 2.6.18 ... Is there somehting special in the command that i have to run for an array configuraiton with lvm So you need raid1, raid456 and md_mod loaded at boot time. I use Grub2 which can load those modules even before the initrd is loaded, so if you're using grub legacy you're going to boot from one of the disks in the array, have the initrd loaded, and with it must come along raid1, raid456 and md_mod modules to assemble the arrays. I think installing mdadm should trigger the inclusion of the modules in the initrd, but if in doubt add raids and md_mod to /etc/initramfs-tools/modules echo -e raid1\nmd_mod\nraid456 /etc/initramfs-tools/modules and rebuild your initrd update-initramfs -u -k kernelversion where the kernelversion string is the target kernel version (2.6.29-mykernel), or $(uname -r) for the running kernel, or all for any possible kernel in the known universe ;-) It's also a good idea to have the partition type of the arrays members set to fd (raid-autodetect) if it's already done. I don't use lvm, but I think the important thing is to get your arrays up, the lvm initialization is done through /etc/init.d/lvm I believe. Do you think the issue is that between the 2.6.18 kernel and the 2.6.29 kernel - there was a change in the drive naming convention where the hd* are now sd* ??? I am concerned if i try to change it, the system will not boot. When compiling the kernel...does this stuff not happen automatically ??? A change occurred in kernel 2.6.19 and up which triggers the naming convention to shift from hd* to sd* for most configurations. Since several configuration files relies on this naming convention it's a good idea to check (fstab, mtab, menu.lst and device.map). A good way around this in fstab, mtab and menu.lst is using labels or UUID. It doesn't (at least always) happen automatically in my painful experience ! If you change that (hd* to sd*) and try to boot on the old kernel, you're heading to a nice black screen... Use UUID's or labels to avoid the need to shift configuration files in between boot attempts. Tom - thanks for the points..but need more help !! please I did as you said - 1. echo -e raid1\nmd_mod\nraid456 /etc/initramfs-tools/modules 2. update-initramfs -u -k 2.6.29 and i saw that the modules all loaded successfully. But i still got the error that it was unable to assemble all arrays. am i missing something ??? here are my other files: fstab: # file system mount point type options dump pass proc/proc procdefaults0 0 /dev/mapper/vg_main-lv_root / ext3 defaults,errors=remount-ro 0 1 /dev/mapper/vg_main-bk_data /data ext3 defaults,errors=remount-ro 0 1 /dev/mapper/vg_main-lv_music /music ext3 defaults,errors=remount-ro 0 1 /dev/md0/boot ext3defaults0 2 /dev/mapper/vg_main-lv_swap noneswapsw 0 0 /dev/hda/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 # usbfs /proc/bus/usb usbfs auto0 0 # USB for vmware/vbox # none /proc/bus/usb usbfs devgid=5002,devmode=664 0 0 mtab: /dev/mapper/vg_main-lv_root / ext3 rw,errors=remount-ro 0 0 tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0 proc /proc proc rw,noexec,nosuid,nodev 0 0 sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0 procbususb /proc/bus/usb usbfs rw 0 0 udev /dev tmpfs rw,mode=0755 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0 /dev/mapper/vg_main-bk_data /data ext3 rw,errors=remount-ro 0 0 /dev/mapper/vg_main-lv_music /music ext3 rw,errors=remount-ro 0 0 /dev/md0 /boot ext3 rw 0 0 menu.lst: title Debian GNU/Linux, kernel 2.6.29 (single-user mode) root(hd0,0) kernel /vmlinuz-2.6.29 root=/dev/mapper/vg_main-lv_root ro single initrd /initrd.img-2.6.29 savedefault title Debian GNU/Linux, kernel 2.6.18-6-amd64 root(hd0,0) kernel /vmlinuz-2.6.18-6-amd64 root=/dev/mapper/vg_main-lv_root ro initrd /initrd.img-2.6.18-6-amd64 savedefault title Debian GNU/Linux, kernel 2.6.18-6-amd64 (single-user mode) root(hd0,0) kernel
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
Joey L wrote : Tom - thanks for the points..but need more help !! please I did as you said - 1. echo -e raid1\nmd_mod\nraid456 /etc/initramfs-tools/modules 2. update-initramfs -u -k 2.6.29 and i saw that the modules all loaded successfully. But i still got the error that it was unable to assemble all arrays. am i missing something ??? here are my other files: fstab: # file system mount point type options dump pass proc/proc procdefaults0 0 /dev/mapper/vg_main-lv_root / ext3 defaults,errors=remount-ro 0 1 /dev/mapper/vg_main-bk_data /data ext3 defaults,errors=remount-ro 0 1 /dev/mapper/vg_main-lv_music /music ext3 defaults,errors=remount-ro 0 1 /dev/md0/boot ext3defaults0 2 /dev/mapper/vg_main-lv_swap noneswapsw 0 0 /dev/hda/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 # usbfs /proc/bus/usb usbfs auto0 0 # USB for vmware/vbox # none /proc/bus/usb usbfs devgid=5002,devmode=664 0 0 mtab: /dev/mapper/vg_main-lv_root / ext3 rw,errors=remount-ro 0 0 tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0 proc /proc proc rw,noexec,nosuid,nodev 0 0 sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0 procbususb /proc/bus/usb usbfs rw 0 0 udev /dev tmpfs rw,mode=0755 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0 /dev/mapper/vg_main-bk_data /data ext3 rw,errors=remount-ro 0 0 /dev/mapper/vg_main-lv_music /music ext3 rw,errors=remount-ro 0 0 /dev/md0 /boot ext3 rw 0 0 menu.lst: title Debian GNU/Linux, kernel 2.6.29 (single-user mode) root(hd0,0) kernel /vmlinuz-2.6.29 root=/dev/mapper/vg_main-lv_root ro single initrd /initrd.img-2.6.29 savedefault title Debian GNU/Linux, kernel 2.6.18-6-amd64 root(hd0,0) kernel /vmlinuz-2.6.18-6-amd64 root=/dev/mapper/vg_main-lv_root ro initrd /initrd.img-2.6.18-6-amd64 savedefault title Debian GNU/Linux, kernel 2.6.18-6-amd64 (single-user mode) root(hd0,0) kernel /vmlinuz-2.6.18-6-amd64 root=/dev/mapper/vg_main-lv_root ro single initrd /initrd.img-2.6.18-6-amd64 savedefault I see nothing that strikes me as odd in your conf, outside of the fact that you only have a single user entry for your new kernel. I think you need to add lvm mapper module to the initrd, echo dm-mod to /etc/initramfs-tools/modules like you did for md-mod and raid's modules, and rebuild an initrd. Also, are your raided partitions identified as fd filesystem ? Maybe the output of fdisk -l and mdadm --detail --scan --verbose would help us understand your layout better. Tom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
thveillon.debian wrote : I see nothing that strikes me as odd in your conf, outside of the fact that you only have a single user entry for your new kernel. I think you need to add lvm mapper module to the initrd, echo dm-mod to /etc/initramfs-tools/modules like you did for md-mod and raid's modules, and rebuild an initrd. Also, are your raided partitions identified as fd filesystem ? Maybe the output of fdisk -l and mdadm --detail --scan --verbose would help us understand your layout better. Tom Sorry, please ignore my advice to load dm-mod in the initrd, reading the whole thread I saw you are running on software raid only, so it's not needed at all, only md-mod. It's getting late in UK time zone... Tom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
On Thu, Apr 2, 2009 at 8:13 PM, thveil...@gmail.com thveil...@gmail.comwrote: thveillon.debian wrote : I see nothing that strikes me as odd in your conf, outside of the fact that you only have a single user entry for your new kernel. I think you need to add lvm mapper module to the initrd, echo dm-mod to /etc/initramfs-tools/modules like you did for md-mod and raid's modules, and rebuild an initrd. Also, are your raided partitions identified as fd filesystem ? Maybe the output of fdisk -l and mdadm --detail --scan --verbose would help us understand your layout better. Tom Sorry, please ignore my advice to load dm-mod in the initrd, reading the whole thread I saw you are running on software raid only, so it's not needed at all, only md-mod. It's getting late in UK time zone... I understand that it is getting late in the UK - I will wait till you wake or unless anybody on this listserv can lend a helping hand. I think i did everything and this is a standard configuration - I did not do anything too crazy ! Again - all this is software raid --- the /boot is raid1 and the other volumes are software raid5 The Raid5 has LVM filesystems. here is fdisk -l : thor:/home/mjh# thor:/home/mjh# thor:/home/mjh# fdisk -l Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 36 289138+ fd Linux raid autodetect /dev/sda2 37 60801 488094862+ fd Linux raid autodetect Disk /dev/sdb: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 36 289138+ fd Linux raid autodetect /dev/sdb2 37 60801 488094862+ fd Linux raid autodetect Disk /dev/sdc: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdc1 * 1 36 289138+ fd Linux raid autodetect /dev/sdc2 37 60801 488094862+ fd Linux raid autodetect Disk /dev/sdd: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdd1 * 1 36 289138+ fd Linux raid autodetect /dev/sdd2 37 60801 488094862+ fd Linux raid autodetect Disk /dev/sde: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sde1 * 1 36 289138+ fd Linux raid autodetect /dev/sde2 37 60801 488094862+ fd Linux raid autodetect Disk /dev/md0: 295 MB, 295960576 bytes 2 heads, 4 sectors/track, 72256 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk /dev/md0 doesn't contain a valid partition table Disk /dev/md1: 1499.4 GB, 1499427176448 bytes 2 heads, 4 sectors/track, 366071088 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk /dev/md1 doesn't contain a valid partition table Disk /dev/dm-0: 536.8 GB, 536870912000 bytes 255 heads, 63 sectors/track, 65270 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/dm-0 doesn't contain a valid partition table Disk /dev/dm-1: 6442 MB, 6442450944 bytes 255 heads, 63 sectors/track, 783 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/dm-1 doesn't contain a valid partition table Disk /dev/dm-2: 536.8 GB, 536870912000 bytes 255 heads, 63 sectors/track, 65270 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/dm-2 doesn't contain a valid partition table Disk /dev/dm-3: 419.1 GB, 419191324672 bytes 255 heads, 63 sectors/track, 50963 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/dm-3 doesn't contain a valid partition table On the mdadm --detail --scan --verbose : thor:/home/mjh# thor:/home/mjh# thor:/home/mjh# thor:/home/mjh# mdadm --detail --scan --verbose ARRAY /dev/md0 level=raid1 num-devices=2 spares=3 UUID=8a435040:c6f27178:02026e74:21deb7ac devices=/dev/sda1,/dev/sdb1,/dev/sdc1,/dev/sdd1,/dev/sde1 ARRAY /dev/md1 level=raid5 num-devices=4 spares=1 UUID=f60a4f26:891a29c2:8dbe0712:bd7a69ac devices=/dev/sda2,/dev/sdb2,/dev/sdc2,/dev/sdd2,/dev/sde2
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
On Thu, Apr 02, 2009 at 09:29:05PM -0400, Joey L wrote: On Thu, Apr 2, 2009 at 8:13 PM, thveil...@gmail.com thveil...@gmail.comwrote: thveillon.debian wrote : [snip] Sorry, please ignore my advice to load dm-mod in the initrd, reading the whole thread I saw you are running on software raid only, so it's not needed at all, only md-mod. It's getting late in UK time zone... I understand that it is getting late in the UK - I will wait till you wake or unless anybody on this listserv can lend a helping hand. I think i did everything and this is a standard configuration - I did not do anything too crazy ! Again - all this is software raid --- the /boot is raid1 and the other volumes are software raid5 The Raid5 has LVM filesystems. what I usually do in situations like this is have the initamfs drop out to busybox (before it attempts to load root) and then you get to have a play around and see what initrd can see and what it can't see [snip] -- I would say the best moment of all was when I caught a 7.5 pound largemouth bass in my lake. - George W. Bush 05/07/2006 on his best moment in office (in an interview with a German newspaper) signature.asc Description: Digital signature
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
On Wed, Apr 1, 2009 at 3:53 PM, Joey L wrote: I am running debian etch with - Linux thor 2.6.18-6-amd64 #1 SMP Thu Dec 25 21:08:54 UTC 2008 x86_64 GNU/Linux ; I am running this with Raid 5 and LVM. I would like to update to 2.6.29 ; I found this article but i am little stuck, can you help ? I guess I can. :-) The steps are: 1. apt-get install kernel-package ncurses-dev fakeroot wget bzip2 2. wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2 3. tar xjf linux-2.6.29.tar.bz2 cd linux-2.6.29/ 4.make menuconfig make-kpkg clean fakeroot make-kpkg --revision=custom.1.0 kernel_image You might want to do add --initrd to the list of arguments to build the ramdisk, which would load the modules required to mount your drives and read the files etc. That should solve the problem. But i am getting an error that it can not find or mount the filesystem. If i reboot again and choose the older config, everything is back to normal and i am working with the old kernel. Can anyone assist ??? Please let me know if this helps. -- Kumar -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
make-kpkg clean fakeroot make-kpkg --revision=custom.1.0 kernel_image You might want to do add --initrd to the list of arguments to build the ramdisk, which would load the modules required to mount your drives and read the files etc. That should solve the problem. Thanks for getting back to me, but do i make the line look like this : fakeroot make-kpkg --revision=custom.1.0 kernel_image --initrd and then execute : *dpkg -i kernel-image-2.6.29_custom.1.0_i386.deb **cd /boot/ mkinitrd -o /boot/initrd.img-2.6.29 2.6.29 thanks..for your help ! *
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
On Thu, Apr 02, 2009 at 12:29:32AM -0400, Joey L wrote: You might want to do add --initrd to the list of arguments to build the ramdisk, which would load the modules required to mount your drives and read the files etc. That should solve the problem. Thanks for getting back to me, but do i make the line look like this : fakeroot make-kpkg --revision=custom.1.0 kernel_image --initrd** and then execute : dpkg -i kernel-image-2.6.29_custom.1.0_i386.deb cd /boot/ mkinitrd -o /boot/initrd.img-2.6.29 2.6.29 True, that will not necessitate a recompile. But, the next time you build your kernel, just use make-kpkg -rfakeroot --initrd --revision=custom.1.0 kernel_image Also, to easily make an initramfs, I use update-initramfs as follows: sudo update-initramfs -c -v 2.6.29 HTH. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
On Thu, Apr 2, 2009 at 12:46 AM, Kumar Appaiah a.ku...@alumni.iitm.ac.inwrote: On Thu, Apr 02, 2009 at 12:29:32AM -0400, Joey L wrote: You might want to do add --initrd to the list of arguments to build the ramdisk, which would load the modules required to mount your drives and read the files etc. That should solve the problem. Thanks for getting back to me, but do i make the line look like this : fakeroot make-kpkg --revision=custom.1.0 kernel_image --initrd** and then execute : dpkg -i kernel-image-2.6.29_custom.1.0_i386.deb cd /boot/ mkinitrd -o /boot/initrd.img-2.6.29 2.6.29 True, that will not necessitate a recompile. But, the next time you build your kernel, just use make-kpkg -rfakeroot --initrd --revision=custom.1.0 kernel_image Also, to easily make an initramfs, I use update-initramfs as follows: sudo update-initramfs -c -v 2.6.29 HTH. Sorry - i get error when i run : sudo update-initramfs -c -v 2.6.29 Can you tell me what i exactly need to run - just getting a little lost. 1. make-kpkg -rfakeroot --initrd --revision=custom.1.0 kernel_image 2. mkinitrd -o /boot/initrd.img-2.6.29 2.6.29 is that it ???
Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29
On Thu, Apr 02, 2009 at 01:15:02AM -0400, Joey L wrote: True, that will not necessitate a recompile. But, the next time you build your kernel, just use make-kpkg -rfakeroot --initrd --revision=custom.1.0 kernel_image Also, to easily make an initramfs, I use update-initramfs as follows: sudo update-initramfs -c -v 2.6.29 HTH. Sorry - i get error when i run :* sudo update-initramfs -c -v 2.6.29 Can you tell me what i exactly need to run - just getting a little lost. 1. make-kpkg -rfakeroot --initrd --revision=custom.1.0 kernel_image 2. mkinitrd -o /boot/initrd.img-2.6.29 2.6.29 is that it ??? Oh, no! All you need to run is make-kpkg -rfakeroot --initrd --revision=custom.1.0 kernel_image sudo dpkg -i ../linux-image-2.6.29custom1.0_deb Maybe that should sort things out. Let me know if you face further problems. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
