From: DagB <dag@bakke.com>
To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [BUG] Device node major comes out wrong on HFS+ under linux
Date: Sat, 15 Oct 2011 20:04:08 +0200 [thread overview]
Message-ID: <4E99CB18.2080302@bakke.com> (raw)
Hi.
Executive summary:
/dev/null:
osx: crw-rw-rw- 1 root wheel 1, 3 Oct 13 04:12 null
linux: crw-rw-rw- 1 root root 16, 3 Oct 13 02:12 /dev/null
/dev/console:
osx: crw------- 1 root wheel 5, 1 Oct 13 04:12 console
linux: crw------- 1 root root 80, 1 Oct 13 02:12 /dev/console
/dev/sda4:
osx: brw-r----- 1 root wheel 8, 4 Oct 13 04:12 sda4
linux: brw-r----- 1 root root 128, 4 Oct 13 02:12 /dev/sda4
Details:
I am slowly figuring out how to boot linux on my shiny new macbook air.
The actual *booting* bit turns out to be incredibly easy with rEFIt,
keithp's macbook air tree, and mfleming's efi stub tree. (3.1.0-ish)
Just pop a suitable kernel somewhere rEFIt can see it, and off you go.
No mucking with bootloaders or repartitioning with esoteric tools and
options. Slick. Got to use a built-in kernel command line, though.
Shrinking the existing OSX HFS+ partition and adding another for a linux
root fs from within OSX also turned out to be a breeze.
I decided to give HFS+ a go for the root fs, just for a POC.
(I'll make an initramfs for making a sane fs. Would be cooler to do
everything from within OSX, and just reboot straight into Linux.)
Untarring a root fs on a my new HFS+ filesystem was straightforward. I
*do* get a warning from OSX' tar when creating the devicenodes, but the
nodes are created with the correct perms and major/minor.
tar: qtn_file_apply_to_path(./dev/console): Operation not permitted
results in (when viewed from OSX):
crw------- 1 root wheel 5, 1 Oct 13 04:12 dev/console
which nicely reflects what the source filesystem has.
Booting a linux kernel (with init=/bin/sh) results in:
crw------- 1 root wheel 80, 1 Oct 13 02:12 /dev/console
Clearly a Major bug. ("ka-pisch".....)
Looks like an endianness issue at hand here:
1 p
1
16 p
10000
5 p
101
80 p
1010000
8 p
1000
128 p
10000000
Good thing I didn't end up trying to dial out through my HDD....
Anyone care to squash this bug, please?
Dag B
next reply other threads:[~2011-10-15 18:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-15 18:04 DagB [this message]
2011-10-18 6:25 ` [BUG] Device node major comes out wrong on HFS+ under linux Thomas Meyer
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=4E99CB18.2080302@bakke.com \
--to=dag@bakke.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.