https://bugzilla.novell.com/show_bug.cgi?id=440337
User robin.listas@telefonica.net added comment
https://bugzilla.novell.com/show_bug.cgi?id=440337#c3
Carlos Robinson changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
Info Provider|robin.listas@telefonica.net |
--- Comment #3 from Carlos Robinson 2008-11-03 04:32:07 MDT ---
Mmmmm... see:
NOT_nimrodel:~ # grep /boot /proc/mounts
/dev/hda6 /boot ext2 rw,noatime,nodiratime,errors=continue,user_xattr,acl 0 0
/dev/hdd2 /otros/boot_d1 ext2 rw,noatime,nodiratime,errors=continue 0 0
/dev/hdd3 /otros/boot_d2 ext2 rw,noatime,nodiratime,errors=continue 0 0
/dev/hda7 /otros/boot_a2 ext2
rw,noatime,nodiratime,errors=continue,user_xattr,acl 0 0
/dev/hda8 /otros/boot_a3 ext2
rw,noatime,nodiratime,errors=continue,user_xattr,acl 0 0
/dev/hda8 /boot ext2 rw,noatime,nodiratime,errors=continue,user_xattr,acl 0 0
Notice that it contains both /dev/hda6 (which belongs to the host) and
/dev/hda8, which belongs to the guest: ie, two /boot entries. In fact, the
guest contains an entry as /boot and another as /otros/boot_a3 which is
another name... (checking)
I have just removed the /otros/boot_a3 double entry. It doesn't seem to
affect.
Interestingly, /proc/mounts show different inside the chroot and out - ant it
is the same virtual file:
nimrodel:~ # grep /boot /proc/mounts
/dev/hda6 /boot ext2 rw,noatime,nodiratime,errors=continue,user_xattr,acl 0 0
/dev/hdd2 /otros/boot_d1 ext2 rw,noatime,nodiratime,errors=continue 0 0
/dev/hdd3 /otros/boot_d2 ext2 rw,noatime,nodiratime,errors=continue 0 0
/dev/hda7 /otros/boot_a2 ext2
rw,noatime,nodiratime,errors=continue,user_xattr,acl 0 0
/dev/hda8 /otros/test_d/boot ext2
rw,noatime,nodiratime,errors=continue,user_xattr,acl 0 0
Maybe the root of the problem is that the chroot should not have this line:
/dev/hda6 /boot ext2 rw,noatime,nodiratime,errors=continue,user_xattr,acl 0 0
but I think that is not possible, it is the same physical-virtual file. Curious
that hda8 change,though.
So it will not work.
The procedure to reproduce is: on a host system, which contains the current
stable version, which now is 11.0, I open an xterm, and run this script (adapt
it for your partitions):
#!/bin/bash
mount /otros/test_d/
mount /otros/test_d/boot/
mount --bind /proc /otros/test_d/proc
mount --bind /sys /otros/test_d/sys
mount --bind /dev /otros/test_d/dev
#cp -f /etc/resolv.conf /otros/test_d/etc/resolv.conf
echo
echo " Copy paste the next line to activate prompt change:"
echo "export PS1=$'\\[\E[1m\E[31m\\]NOT_\\h:\\w # \\[\E(B\E[m\\]'"
echo
chroot /otros/test_d/ /bin/bash --login
Where /otros/test_d/ is the factory partition, and /otros/test_d/boot/ its
boot partition (this is because factory resides on /dev/hdd14 which failed to
boot on its own; so I use a separate /boot on /dev/hda8).
Then I run "zypper dup" on that xterm. Factory update progresses, for hours,
some time days when it fails, while my main system is untouched and running
happily, and I can keep working ;-)
Notice that for me it is sufficient to know that hacking /etc/mtab is enough to
make the procedure work; I just have to add that to my preparation routine.
I opened the bugzilla because I (we) thougt there might be a bug somewhere, and
I'm not sure there is one. If the situation can be solved handling it in the
kernel installation scripts, I'll be happier, but not if it is a problem to
others. I believe I'm not the only one using the chroot trick, but perhaps the
correct thing is for us to edit mtab.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.