From: Hendrik Boom <hendrik@topoi.pooq.com>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: Installation problems
Date: Sun, 15 Jul 2007 19:37:57 +0000 (UTC) [thread overview]
Message-ID: <f7dt2k$d3e$2@sea.gmane.org> (raw)
In-Reply-To: 200707142000.47469.mike@gaima.co.uk
On Sat, 14 Jul 2007 20:00:47 +0100, Mike Williams wrote:
> On Saturday 14 July 2007 18:53:27 Hendrik Boom wrote:
>> Very interesting. It gets further with the dolvm2 pernel option (I
>> specified udev first for good measure, as indicated in the howto, and it
>> got further. However, it still fails to handle
>> /dev/mapper/lovesong-gentoo properly. fsck complains about it, and I get
>> to type "shell" for a shell. There I find that
>> /dev/mapper/lovesong-mapper does not exost (as testified by ls), but that
>> it is nonetheless mounted on / (as testified by mount).
>
> OK, that's not exactly what I expected to happen, but I guess the initrd/ramfs
> has the same udev setup as the full system so either the udev and
> the "proper" LVM path could be used.
> I prefer using the "proper" LVM paths, as early udevs won't create the other
> nodes and later ones may also not do so (udev is pretty stable now, so I
> realise it's highly unlikely).
>
> udev path == /dev/mapper/VG-LV
> "proper" LVM path == /dev/VG/LV
>
>> This suggests that (a) it was mounted, and (b) something else was mounted
>> over the path to /dev/mapper/lovesong-mapper afterward. So something is
>> clearly finding /dev/lovesong/mapper, and then making it inaccessible.
>
> a and b, the initrd/ramfs is mounted as / from ram by the kernel after it's
> booted, the initrd/ramfs does it's stuff, then "pivots" the / device to the
> real_root device on the kernel command line.
> The / device you specify in fstab is never actually mounted, as to read it /
> needs to be mounted, so the kernel or initrd/ramfs does it based on the
> kernel arguements.
> As a workaround you can make checkfs not attempt an fsck on the / device. In
> fstab set the final column on the / entry to 0, it's almost certainly 1. This
> number defines the order in which devices are fsck'd, 0 means don't do
> anything.
As another workaround I could just continue using Debian etch. I probably
have the time to get it fixed right.
>
>> By the way, I didn't find a /dev/VG/ directory either.
>
> No /dev/lovesong/ ? Assuming your VolumeGroup is actually called
> lovesong.
Yes, there is a /dev/lovesong, on both Debian and gentoo, and even a
/dev/lovesong/gentoo! (confusion existed because I once installed a
Debian system that actually called its newly created volume group "VG".) So
I have changed all references to /dev/mapper/lovesong-gentoo in the
menu.lst so they say /dev/lovesong/gentoo. I *still* get fsck complaining
about /dev/mapper/lovesong-gentoo, which still does not exits.
Where is it getting that name?
(thinks)
AH! From gentoo's /etc/fstab! Will fix and report back.
-- hendrik
--
gentoo-user@gentoo.org mailing list
next prev parent reply other threads:[~2007-07-15 19:46 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-13 19:19 [gentoo-user] Installation problems Hendrik Boom
2007-07-13 21:49 ` ds
2007-07-14 11:18 ` [gentoo-user] " Hendrik Boom
2007-07-14 12:31 ` Mick
2007-07-14 12:28 ` [gentoo-user] " Mike Williams
2007-07-14 17:53 ` [gentoo-user] " Hendrik Boom
2007-07-14 19:00 ` Mike Williams
2007-07-15 19:37 ` Hendrik Boom [this message]
2007-07-15 21:00 ` Hendrik Boom
2007-07-15 21:42 ` Mike Williams
2007-07-17 16:03 ` Hendrik Boom
2007-07-17 16:17 ` Hendrik Boom
2007-07-17 18:44 ` Mike Williams
2007-07-17 19:43 ` Mick
2007-07-18 11:33 ` Hendrik Boom
2007-07-18 17:27 ` Neil Bothwick
2007-07-18 20:22 ` Mike Williams
-- strict thread matches above, loose matches on Subject: below --
2020-10-02 6:01 [gentoo-user] installation problems Jude DaShiell
2020-10-02 8:41 ` Neil Bothwick
2020-10-02 8:53 ` Dale
2020-10-02 12:09 ` Rich Freeman
2020-10-02 12:30 ` Dale
2020-10-02 13:09 ` [gentoo-user] " Grant Edwards
2020-10-02 13:25 ` Dale
2020-10-02 14:43 ` Grant Edwards
2020-10-02 15:50 ` Neil Bothwick
2020-10-02 16:53 ` Dale
2020-10-02 13:07 ` Grant Edwards
2020-10-02 13:23 ` Peter Humphrey
2020-10-02 13:32 ` John Covici
2020-10-02 13:38 ` Rich Freeman
2020-10-02 13:51 ` John Covici
2020-10-02 14:45 ` Rich Freeman
2020-10-02 15:47 ` Neil Bothwick
2020-10-02 17:06 ` John Covici
2020-10-02 18:05 ` Neil Bothwick
2020-10-03 7:37 ` Jude DaShiell
2020-10-03 8:59 ` Michael
2020-10-03 11:57 ` Rich Freeman
2020-10-02 13:35 ` Rich Freeman
2020-10-02 17:05 ` Dale
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='f7dt2k$d3e$2@sea.gmane.org' \
--to=hendrik@topoi.pooq.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox