public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
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



  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