Bug 212751 - initscripts complaints "Missing major number ..."
initscripts complaints "Missing major number ..."
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-28 14:36 EDT by Michal Jaegermann
Modified: 2014-03-16 23:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-16 19:48:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2006-10-28 14:36:50 EDT
Description of problem:
After an update to initscripts-8.46-1 the following shows up in boot
messages:

Setting hostname localhost.localdomain:                    [  OK  ]
Missing major number for persistent device.
Couldn't create ioctl argument.
last_lba(): I don't know how to handle files with mode 41ed
read error, sector 0
read error, sector 1
read error, sector 29
Missing major number for persistent device.
Couldn't create ioctl argument.

Reverting to initscripts-8.45.3-1 makes these messages to go away.

Looking at differences in /etc/init.d/rc.sysinit from both versions
the above is a result of difference in dmraid setup.  Actually I am
getting mesages like the above from running

    /sbin/kpartx -a -p p "/dev/mapper/$dmname"

when "$dmname" is empty.  If I am executing the whole 'if ... fi"
corresponding block on an already running system then this works
so that would mean that setting "$dmname" in a startup context fails.
I am not sure right now why.

OTOH there is this bit above the quoted line:

   [ -n "$dmname" ] && continue

which does not seem to make a sense here.  It looks to me that the
condition is reversed and '-z' was meant instead of '-n'.  Even if
correct my test script that way then I am ending up running, when
not in a startup,

   /sbin/kpartx -a -p p /dev/mapper/pdc_cjfeejidea
   
(I have actually one disk with a raid signature) which is not causing
any problems.

With '[ -z "$dmname" ] && continue' in rc.sysinit I do not see qouted
messages but if I am not running kpartx that is not so surprising.

Version-Release number of selected component (if applicable):
initscripts-8.46-1

How reproducible:
always
Comment 1 Bill Nottingham 2006-10-30 12:12:33 EST
If you change it back to dmraid from dmraid.static, does it start behaving
again? (And if so, that's really wrong...)
Comment 2 Michal Jaegermann 2006-10-31 23:47:33 EST
> If you change it back to dmraid from dmraid.static, does it start
> behaving again?

If you can call it "behaving". :-)  The catch is that /sbin/dmraid
is using libz.so.1 from /usr; so if /usr is not available yet then
"for x ..." loop below has nothing to do and /sbin/kpartx never
runs with "/dev/mapper/" partition and the the problem is hidden. :-)
If you try the later you will always get complaints like stated.

As I can see it the only way to correct that is disallow
"/dev/mapper/" partition, i.e reverse a test for 'continue'.
Then I see no problems - static or no static.

Sorry for a delay.  You caught me with this question in a wrong
moment.
Comment 3 Bill Nottingham 2007-04-16 19:48:49 EDT
This should be fixed in the current update initscripts.
Comment 4 Bill Nottingham 2007-04-16 19:49:18 EDT
This should be fixed in the current update initscripts, or rawhide. Please
reopen if it's not.

Note You need to log in before you can comment on or make changes to this bug.