Re: kubuntu vs fedora initrd init files

2009-02-23 Thread jackson byers
Mikkel,
one pure kubuntu on usb, no disk reordering.
I believe this is kubuntu 6.06 dapper, but done via debootstrap methods,
which i just followed recipe found on web in dec 2006.
It was first working on scsi, but then copied to usb

I had to revive it, bc my fc5copy files were in top dir on usb.
I redid the kubu debootstrap on usb; first set up on usb on dec22 2006
first mv'd out the fc5copy files to /mvfc5
2nd mv'd back kubu debootstrap files into top dir of usb
this booted fine, so my mv out and mv back  no problems,
and kubuntu is on sdc, no reordering of disks.

This may well not be what you wanted bc of the special debootstrap stuff
but it is a case that is "pure" kubuntu, on sdc1, no reordering


(I also currently have  kubuntu 6.06.1 LTS  from Install/live CD,
which I somehow managed to install on scsi, in sdb5, also in dec 2006
--it is an install, i am certainly not booting off of CD.
It still boots from scsi sdb5.
I was hoping to get this booting on usb, but so far it is failing,
in part bc of some glitches in my backup tools.)

here is data showing debootstrap version usb booting on sdc1

r...@kubu:/# uname -a
Linux kubu 2.6.15-26-386 #1 PREEMPT Thu Aug 3 02:52:00 UTC 2006 i686
GNU/Linux
r...@kubu:/#
I believe this kubuntu 6.06 dapper

r...@kubu:/mnt# df -kh
FilesystemSize  Used Avail Use% Mounted on
/dev/sdc1 233G   14G  220G   6% /
varrun   1014M   40K 1014M   1% /var/run
varlock  1014M  4.0K 1014M   1% /var/lock
udev 1014M  180K 1014M   1% /dev
devshm   1014M 0 1014M   0% /dev/shm
/dev/sda1  21G  6.5G   13G  34% /fc5hold
tmpfs1014M 0 1014M   0% /dev/shm
/dev/sdb1  99M   23M   72M  24% /mnt/sdb1
r...@kubu:/mnt#


r...@kubu:/# cat /proc/partitions
major minor  #blocks  name

   8 0   35843686 sda
   8 1   21494938 sda1
   8 23911827 sda2
   8 3   10434217 sda3
   816   35843686 sdb
   817 104391 sdb1
   8182048287 sdb2
   819 104422 sdb3
   820  1 sdb4
   8218193118 sdb5
   8228193118 sdb6
   823   17197551 sdb7
   832  244198584 sdc
   833  244196001 sdc1
 253 0   21494938 dm-0
 253 13911827 dm-1
 253 2   10434217 dm-2
 253 3 104391 dm-3
 253 42048287 dm-4
 253 5 104422 dm-5
 253 68193118 dm-6
 253 78193118 dm-7
 253 8   17197551 dm-8
 253 9  244196001 dm-9

cat /etc/fstab
/dev/sdc1/ reiserfs   defaults0 0
/dev/sda1/fc5hold  ext3   defaults1 2

devpts   /dev/ptsdevpts   gid=5,mode=620  0 0
tmpfs/dev/shm tmpfs   defaults0 0
proc /proc proc   defaults0 0
sysfs/sys sysfs   defaults0 0
/dev/sda2swap swapdefaults0 0
/dev/cdrom   /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0


from grub.conf :

title kubuntu dapper usb debootstrap
###   root (hd0,0)   pick up kernel,initrd from sda1,works
  root (hd1,0) ### sdb1, only kubufiles cp from kubuinstall,works
###  root (hd2,0) ### doesnt work
  kernel /boot/vmlinuz-2.6.15-26-386 ro root=/dev/sdc1
  initrd /boot/initrd.img-2.6.15-26-386


So, is this useful as proof that kubuntu does not reorder usb to sda?
or is this debootstrap business too tricky to say anything
about a pure standard install?

Jack
-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

Re: kubuntu vs fedora initrd init files,

2009-02-21 Thread jackson byers
Mikkel responded:
I have done it both ways - as a fresh install, and by taking a hard
drive with an installed OS, and putting it in an external USB case,
and the drive has always ended up as /dev/sda. This  is much less of
a problem if you are using LVM and/of partition labels then if you
are mounting partitions directly. (As long as your LVM names do not
collide! ie more then one VolGroup00.)

By far, the easiest is to do a fresh, expert install to a USB drive
- it will even do the proper Grub install so that you can boot off
the USB drive directly on any system that supports booting from a
USB drive. You can do this when moving an install to an external
case, but it is much easier doing it at install time.

Mikkel
---

Mikkel, I am sure you know the best way, but consider:
re LVM: I know nothing;
re partition labels: I have some but limited experience;
re fresh installs: very limited
   --my main fc5 was put on for me by a vendor in aug 06
--i did that kubuntu install (from a dvd? cant recall) late06,early 07
-- and some other knoppix-based things
re fresh, expert install to usb/or scsi:  I have no experience

I got into this bc Iwas trying to prepare for installing f9,f10
  on my scsi sda,sdb, and so backed up fc5 to my usb to make space on scsi.
 My usb is one large reiserfs partition ( set up by my vendor in 2006)
 (I am uncertain as to what tool to use to
  shrink that usb reiserfs partition without losing my backupdata,
  or even if that is possible. I would like more than one partition
  if I am going to get into doing installs to the usb)

Then, it was only bc I was frustrated it seemed completely
  to boot off my fc5copy on usb  ( could not find /dev/root...)
that i tried the kubuntu 2.6.26-386 kernel,initrd
and that worked!
 so then I got your advice re usb-storage etc,etc
 and i finally got it also working using the fc5 kernel,initrd.

So, all my recent experience is with doing the copy not a fresh install
so I will try that  with a usb copy of the kubuntu install.

If that succeeds, whatever the result sda or sdc,
then i will look into doing fresh, expert install to usb of f9 or f10

thanks much for your detailed responses
Jack
-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

Re: kubuntu vs fedora initrd init files

2009-02-20 Thread Mikkel L. Ellertson
Please do not post in HTML!

jackson byers wrote:
> Mikkel responded:
> To tell if Ubuntu does the same thing, you would have to do the same
> type of install. The reordering of the disks is because of two
> reasons. The first is because of the BIOS, and affects Grub. When
> you boot from a USB device, that device becomes BIOS drive 80, or
> Grub drive hd0. This is because what ever hard drive you boot from
> is automatically set to BIOS drive 80. This is also true when you
> tell the BIOS to boot from the second hard drive in the machine.
> 
> The other reason affects the kernel ordering. How the kernel assigns
> drives depends on the module loading order. Because you have to load
> the usb_storage module from the initrd, the USB drive is the first
> controller scanned. (There are ways to change that, but it not
> easy.) This affects any kernel, or distribution that uses modules.
> You run into the same thing when you install Ubuntu to a USB drive.
> That is why a USB install is only offered as an expert install.
> Mikkel
> --
> Mikkel,
> thanks for response. As is often the case, your response if full of info.
> I am trying to absorb it all.
>> To tell if Ubuntu does the same thing, you would have to do the same
>> type of install.
> First, let's be sure we are on same page.
> What I did was to boot a usbexternaldisk copy of main fc5.
> (this was not an anaconda install to the usbdisk)
> I did this 2ways, each with its own grub.conf stanza
> 1) using  kernel,initrd from a kubuntu 6.06 dapper
>this boots, disks are _not_ reordered   ie usb is seen as sdc
> 2) using the kernel,initrd of the fc5copy(same as in mainfc5)
>this boots, disks _are_ reordered   ie usb is seen as sda
> 
> But, my bios does not see the usb disk, so in _both_ cases
>  I copied the /boot files from the fc5copy into  sdb3 = (hd1,2)
> This makes it  some kind of usb/scsi hybrid  bc the /boot files are on sdb
> 
OK - On the systems I use, they offer the option to boot from a USB
device. I have used this to boot from USB memory drives, as well as
 USB hard drives. I have done a complete new install to a USB hard
drive as well. In all cases, the BIOS did not list the drive as an
internal hard drive, but it was able to boot from it, and it became
BIOS device 80, and Grub device hd0.

> So when you say "have to do same type of install"
> I think you mean, make a usbdisk copy of the kubuntu install (now on sdb5)
> and then use the kubuntu kernel,initrd to boot this.
> Then, if this again results in disks _not_ reordered,
> only then will be able to see "if ubuntu does the same thing".
> Correct me if I am not understanding you.
> 
Yes, this is what I mean. When you build an initrd so that you mount
the USB drive as your / partition, it will also set that as /dev/sda.

> this will take some time, but I want to go thru with it.
> I first have to mv the fc5copy out of the topdir of the usb(its one
> large partn)
> and have my backup scripts do the copy of the kubuntu install to
> topdir of usb.
> 
> Jack
> 
I have done it both ways - as a fresh install, and by taking a hard
drive with an installed OS, and putting it in an external USB case,
and the drive has always ended up as /dev/sda. This  is much less of
a problem if you are using LVM and/of partition labels then if you
are mounting partitions directly. (As long as your LVM names do not
collide! ie more then one VolGroup00.)

By far, the easiest is to do a fresh, expert install to a USB drive
- it will even do the proper Grub install so that you can boot off
the USB drive directly on any system that supports booting from a
USB drive. You can do this when moving an install to an external
case, but it is much easier doing it at install time.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!



signature.asc
Description: OpenPGP digital signature
-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

Re: kubuntu vs fedora initrd init files

2009-02-20 Thread jackson byers
Mikkel responded:
To tell if Ubuntu does the same thing, you would have to do the same
type of install. The reordering of the disks is because of two
reasons. The first is because of the BIOS, and affects Grub. When
you boot from a USB device, that device becomes BIOS drive 80, or
Grub drive hd0. This is because what ever hard drive you boot from
is automatically set to BIOS drive 80. This is also true when you
tell the BIOS to boot from the second hard drive in the machine.

The other reason affects the kernel ordering. How the kernel assigns
drives depends on the module loading order. Because you have to load
the usb_storage module from the initrd, the USB drive is the first
controller scanned. (There are ways to change that, but it not
easy.) This affects any kernel, or distribution that uses modules.
You run into the same thing when you install Ubuntu to a USB drive.
That is why a USB install is only offered as an expert install.
Mikkel
--
ikkel,
thanks for response. As is often the case, your response if full of info.
I am trying to absorb it all.
> To tell if Ubuntu does the same thing, you would have to do the same
> type of install.
First, let's be sure we are on same page.
What I did was to boot a usbexternaldisk copy of main fc5.
(this was not an anaconda install to the usbdisk)
I did this 2ways, each with its own grub.conf stanza
1) using  kernel,initrd from a kubuntu 6.06 dapper
   this boots, disks are _not_ reordered   ie usb is seen as sdc
2) using the kernel,initrd of the fc5copy(same as in mainfc5)
   this boots, disks _are_ reordered   ie usb is seen as sda

But, my bios does not see the usb disk, so in _both_ cases
 I copied the /boot files from the fc5copy into  sdb3 = (hd1,2)
This makes it  some kind of usb/scsi hybrid  bc the /boot files are on sdb

So when you say "have to do same type of install"
I think you mean, make a usbdisk copy of the kubuntu install (now on sdb5)
and then use the kubuntu kernel,initrd to boot this.
Then, if this again results in disks _not_ reordered,
only then will be able to see "if ubuntu does the same thing".
Correct me if I am not understanding you.

this will take some time, but I want to go thru with it.
I first have to mv the fc5copy out of the topdir of the usb(its one large
partn)
and have my backup scripts do the copy of the kubuntu install to
topdir of usb.

Jack
-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

Re: kubuntu vs fedora initrd init files

2009-02-20 Thread Mikkel L. Ellertson
jackson byers wrote:
> being way behind the current versions,
> of course I have no idea if this is relevant to f9,f10.
> But if kubuntu present version still behaves as i said, ie no reordering
> of disks
> while fedora f9,f10 probably still does  reorder the disks,
> then my question could well be of interest to f9,f10,
> for anyone looking to use usb external installs.
> e.g., learning how kubuntu manages to not reorder.
> 
> I do see occasional other msgs in this list from users in fc2,fc5,fc6,
> afaik there is no list rule that we cant ask questions on unsupported
> versions.
> Correct me if I am wrong.
> 
> the kernel version was given in my message
> I believe it came packaged in kubuntu 6.06  dapper
> 
> Jack
>
To tell if Ubuntu does the same thing, you would have to do the same
type of install. The reordering of the disks is because of two
reasons. The first is because of the BIOS, and affects Grub. When
you boot from a USB device, that device becomes BIOS drive 80, or
Grub drive hd0. This is because what ever hard drive you boot from
is automatically set to BIOS drive 80. This is also true when you
tell the BIOS to boot from the second hard drive in the machine.

The other reason affects the kernel ordering. How the kernel assigns
drives depends on the module loading order. Because you have to load
the usb_storage module from the initrd, the USB drive is the first
controller scanned. (There are ways to change that, but it not
easy.) This affects any kernel, or distribution that uses modules.
You run into the same thing when you install Ubuntu to a USB drive.
That is why a USB install is only offered as an expert install.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!



signature.asc
Description: OpenPGP digital signature
-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

Re: kubuntu vs fedora initrd init files

2009-02-20 Thread jackson byers
poc responded:

On Fri, 2009-02-20 at 11:16 -0800, jackson byers wrote:
> Here I comment on the differences between  kubuntu,fedora  initrd

Fedora Core 5? It would be nice to know if this is relevant to F9 and
F10. Plus you don't say what version of Kubuntu you used.

poc
--
being way behind the current versions,
of course I have no idea if this is relevant to f9,f10.
But if kubuntu present version still behaves as i said, ie no reordering of
disks
while fedora f9,f10 probably still does  reorder the disks,
then my question could well be of interest to f9,f10,
for anyone looking to use usb external installs.
e.g., learning how kubuntu manages to not reorder.

I do see occasional other msgs in this list from users in fc2,fc5,fc6,
afaik there is no list rule that we cant ask questions on unsupported
versions.
Correct me if I am wrong.

the kernel version was given in my message
I believe it came packaged in kubuntu 6.06  dapper

Jack
-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

Re: kubuntu vs fedora initrd init files

2009-02-20 Thread Patrick O'Callaghan
On Fri, 2009-02-20 at 11:16 -0800, jackson byers wrote:
> Here I comment on the differences between  kubuntu,fedora  initrd

Fedora Core 5? It would be nice to know if this is relevant to F9 and
F10. Plus you don't say what version of Kubuntu you used.

poc

-- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines


kubuntu vs fedora initrd init files

2009-02-20 Thread jackson byers
in the thread
"boot from backup copy of fc5 on usb external disk?"
i described my initial problems and final success

Here I comment on the differences between  kubuntu,fedora  initrd

I had success using two different kernel,initrd
1) obtained from a kubuntu install
stanza in grub.conf:
title FC5copy (2.6.15-26-386) usbfc5 /media/disk-1 (hd1,2)sdb3 rootusb
 root (hd1,2) ## sdb3
 kernel /boot/vmlinuz-2.6.15-26-386 ro root=LABEL=rootusb  rhgb quiet
 initrd /boot/initrd.img-2.6.15-26-386

This worked without any modifications on my part of the initrd init script
Moreover the disks were _not_ reordered

2)using my mainfc5
stanza in grub.conf:
title FC5copy (2.6.17-1.2174_FC5_usbrs4.sdb2sw.img)  /media/disk-1 (hd1,2)
  root (hd1,2)  ## sdb3
  kernel /boot/vmlinuz-2.6.17-1.2174_FC5 ro root=LABEL=rootusb  rhgb
quiet
  initrd /boot/initrd_usbrs4.sdb2sw.img

This also worked, but here I had to make modification of initrd init script
 both  on  "resume /dev/sdxx"
and on "mkrootdev -t reiserfs -o defaults,ro /dev/sdc1"

And here the disks _were_ reordered.
 usb originally sdc -> now sda
 first scsi originally sda now sdb
 second scsi originally sdb, now sdc
This reordering caused me much confusion almost to the point where
I was going to give up.

So, the kubuntu kernel,initrd worked with minimum of fuss
the fedora  kernel,initrd rqrd days of effort, confusion
  (in part bc of my perpetual noobie status)

Aside from the different results just noted
my additional point here is that the
initrd init files are almost completely different in the two cases.

case 2) fedora initrd-2.6.17-1.2174_FC5 (modified
toinitrd_usbrs4.sdb2sw.img)
[r...@bootp cleanrs3]# tail init
mkblkdevs
resume /dev/sdb2
echo Creating root device.
mkrootdev -t reiserfs -o defaults,ro /dev/sdc1
echo Mounting root filesystem.
mount /sysroot
echo Setting up other filesystems.
setuproot
echo Switching to new root and running init.
switchroot

case 1) kubuntu:  initrd.img-2.6.15-26-386
here the script is quite long; I will list the whole thing at the end.
I am not competent enough to try and edit this init;
as noted above, I didnt have to, it just worked.
This init has none of the fedora init structure
no use at all of
mkrootdev, sysroot, switchroot

googling "could not find /dev/root" gives a lot of msgs over
the past few years, all failing sysroot, switchroot,
and ending in kernel panic,
 mostly from redhat,fedora users.
I dont think I saw even one from ubuntu users--
that now is no surprise bc the ubuntu init file does its thing
in a different way.

Here is the init file from initrd.img-2.6.15-26-386
I would be interested in comments as to what it is doing;
and especially if anyone knows how it avoids reordering the disks.

[r...@bootp clean386]# cat init
#!/bin/sh

mkdir /sys
mkdir /proc
mkdir /tmp
mkdir -p /var/lock
mount -t sysfs none /sys
mount -t proc none /proc

# Note that this only becomes /dev on the real filesystem if udev's scripts
# are used; which they will be, but it's worth pointing out
mount -t tmpfs -o mode=0755 udev /dev
touch /dev/.initramfs-tools
mkdir /dev/.initramfs
mknod /dev/console c 5 1
mknod /dev/null c 1 3

# Export the dpkg architecture
export DPKG_ARCH=
. /conf/arch.conf

# Bring in the main config
. /conf/initramfs.conf
for i in conf/conf.d/*; do
[ -f ${i} ] && . ${i}
done
. /scripts/functions

# Parse command line options
export break=
export init=/sbin/init
export quiet=n
export readonly=y
export ROOT=
export resume=${RESUME}
export rootmnt=/root
export debug=
for x in $(cat /proc/cmdline); do
case $x in
init=*)
init=${x#init=}
;;
root=*)
ROOT=${x#root=}
case $ROOT in
LABEL=*)
ROOT="/dev/disk/by-label/${ROOT#LABEL=}"
;;
UUID=*)
ROOT="/dev/disk/by-uuid/${ROOT#UUID=}"
;;
esac
;;
nfsroot=*)
NFSROOT=${x#nfsroot=}
;;
boot=*)

BOOT=${x#boot=}
;;
resume=*)
resume=${x#resume=}
;;
quiet)
quiet=y
;;
ro)
readonly=y
;;
rw)
readonly=n
;;
debug)
debug=y
exec >/tmp/initramfs.debug 2>&1
set -x
;;
break=*)
break=${x#break=}
;;
break)
break=premount
;;
esac
done

depmod -a
maybe_break top

# Don't do log messages here to avoid confusing usplash
run_scripts /scripts/init-top

. /scripts/${BOOT}
parse_numeric ${ROOT}

maybe_break modules
log_begin_msg "Loading essential drivers..."
load_modules
log_end_msg

maybe_break premount
[ "$quiet" != "y" ] && log_begin_msg