I use grml 1.1 but wanted to test the new 2008.11 version. I noticed 2 very annoying features: When it reads "Searching for grml file, this might take a few seconds" in reality it takes 3:30 minutes before the program continues. But only to stop again at "Waiting for /dev to be fully populated" for about 30 seconds.
How can I avoid these stops in execution? I tried all the no....options (noautoconfig, nodhcp, noquick) but without any success. Any ideas?
Hubert
You can try noudev but it may leave other problems Moss
On 23/01/2009, Hubert Gabler loipersb@aon.at wrote:
I use grml 1.1 but wanted to test the new 2008.11 version. I noticed 2 very annoying features: When it reads "Searching for grml file, this might take a few seconds" in reality it takes 3:30 minutes before the program continues. But only to stop again at "Waiting for /dev to be fully populated" for about 30 seconds.
How can I avoid these stops in execution? I tried all the no....options (noautoconfig, nodhcp, noquick) but without any success. Any ideas?
Hubert _______________________________________________ Grml mailing list - Grml@mur.at http://lists.mur.at/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://grml.supersized.org/
The only other thing I can think of is to edit /etc/runlevel.conf and prevent any services from starting that you do not want.
Best Wishes Moss
On Sat, Jan 24, 2009 at 01:10:55PM +0100 or thereabouts, Hubert Gabler wrote:
moss@mythic-beasts.com schrieb:
You can try noudev but it may leave other problems Moss
The only difference using noudev was that execution stops for 2:15 minutes instead of 3:30. Thank you for trying to help! Hubert _______________________________________________ Grml mailing list - Grml@mur.at http://lists.mur.at/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://grml.supersized.org/
Hubert Gabler schrieb:
I use grml 1.1 but wanted to test the new 2008.11 version. I noticed 2 very annoying features: When it reads "Searching for grml file, this might take a few seconds" in reality it takes 3:30 minutes before the program continues.
When you have it booted and cat /proc/partitions, how many entries are displayed there?
How many entries are in the /sys/block/ directory?
What filesystems are on your partitions?
Since it scans all devices for the grml file (which could be either on an USB or on a CDROM), slow external devices or partitions that need some time for mounting can slow this process down here.
But I never had more than a few (~30) seconds delay at that point, so it must be something in your setup.
But only to stop again at "Waiting for /dev to be fully populated" for about 30 seconds.
Yeah, I noticed this delay as well. No idea why it got that slow in the latest version. OTOH, as I use grml mainly as a rescue disk, I prefer a 30 seconds delay to work around some hardware issues (if that was the reason for the delay) to a GRML that might not boot on the hardware where I need it.
You might use noudev instead, but that will break automatic detection of external devices and some other things (so I would only use it if the machine freezes or reboots at that stage).
Michael
Michael Schierl schrieb:
When you have it booted and cat /proc/partitions, how many entries are displayed there?
major minor #blocks name
8 0 488386584 sda 8 1 29366788 sda1 8 2 20972857 sda2 8 3 20972857 sda3 8 4 1 sda4 8 5 4008186 sda5 8 6 24418768 sda6 8 7 24418768 sda7 8 8 24418768 sda8 8 9 24418768 sda9 8 10 24418768 sda10 8 11 117194143 sda11 8 12 20972826 sda12 8 13 152802216 sda13 8 16 312571224 sdb 8 17 205527546 sdb1 8 18 56629125 sdb2 8 19 25205985 sdb3 8 20 1 sdb4 8 21 25205953 sdb5 8 32 312571224 sdc 8 33 25599546 sdc1 8 34 25599577 sdc2 8 35 25599577 sdc3 8 36 235769940 sdc4 7 0 671248 loop0
All ext3, except sda1,12,13 and sdb2 which are NTFS
How many entries are in the /sys/block/ directory?
loop0@ loop5@ ram10@ ram15@ ram2@ ram24@ ram29@ ram5@ sda@ loop1@ loop6@ ram11@ ram16@ ram20@ ram25@ ram3@ ram6@ sdb@ loop2@ loop7@ ram12@ ram17@ ram21@ ram26@ ram30@ ram7@ sdc@ loop3@ ram0@ ram13@ ram18@ ram22@ ram27@ ram31@ ram8@ sr0@ loop4@ ram1@ ram14@ ram19@ ram23@ ram28@ ram4@ ram9@
I'm afraid I have to stay with grml 1.1 and miss the new features of 2008.11
Hubert
* Hubert Gabler loipersb@aon.at [090125 01:59]:
Michael Schierl schrieb:
When you have it booted and cat /proc/partitions, how many entries are displayed there?
major minor #blocks name
[ snip lots of partitions ]
I don't remember; but did anybody already mention the boot option "noautoconfig"?
Greetings, J"o!
* Hubert Gabler loipersb@aon.at [20090123 18:18]:
I use grml 1.1 but wanted to test the new 2008.11 version. I noticed 2 very annoying features: When it reads "Searching for grml file, this might take a few seconds" in reality it takes 3:30 minutes before the program continues. But only to stop again at "Waiting for /dev to be fully populated" for about 30 seconds.
How can I avoid these stops in execution? I tried all the no....options (noautoconfig, nodhcp, noquick) but without any success. Any ideas?
Some further tips:
* If you know the device name where grml is booting from try booting via: "grml bootfrom=/dev/sda1" (assuming the /dev/sda1 is your CD/DVD device booting grml). Does this improve your bootup time? If so we could spot the device which takes just to long for scanning.
* Blacklist modules: when booting finished check out dmesg output and if there any noteable error/warning messages and try to blacklist probably involved modules booting using: "grml blacklist=modulename[,module2]" - though I'm not sure whether this really helps in your case as you already tried the noudev bootoption.
The 3:30min are definitely too much and I'm interested in resolving your issue.
regards, -mika-
Michael Prokop schrieb:
Some further tips:
- If you know the device name where grml is booting from try booting via: "grml bootfrom=/dev/sda1" (assuming the /dev/sda1 is your CD/DVD device booting grml). Does this improve your bootup time? If so we could spot the device which takes just to long for scanning.
After the usual 3:30 delay it read "mounted live system on /dev/scd0" so I tried (as you suggested) grml bootfrom=/dev/scd0 but this did not help, sorry.
- Blacklist modules: when booting finished check out dmesg output and if there any noteable error/warning messages
There are several error messages like this: a) many lines saying sr 6:0:1:0: [sr0] Sense Key: Medium Error [current] sr 6:0:1:0: [sr0] Add. Sense: L-EC uncorrectable error
b) many lines like this Buffer I/O error on device sr0 end_request: I/O error, dev sr0, sector 1380478
c) ck804xrom ck804xrom_init_one(): Unable to register resource 0x00000000ff000000-0x00000000ffffffff - kernel bug?
d) an endless flow of lines like CFI: Found no ck804xrom@ ff.......... at location zero JEDEC: Found no .....
Maybe this gives you a hint. BTW I run Lenny, Sid and Fedora 10 on my system without any problems.
MfG, Hubert
* Hubert Gabler loipersb@aon.at [20090203 15:13]:
Michael Prokop schrieb:
- If you know the device name where grml is booting from try booting via: "grml bootfrom=/dev/sda1" (assuming the /dev/sda1 is your CD/DVD device booting grml). Does this improve your bootup time? If so we could spot the device which takes just to long for scanning.
After the usual 3:30 delay it read "mounted live system on /dev/scd0" so I tried (as you suggested) grml bootfrom=/dev/scd0 but this did not help, sorry.
Ok
- Blacklist modules: when booting finished check out dmesg output and if there any noteable error/warning messages
There are several error messages like this: a) many lines saying sr 6:0:1:0: [sr0] Sense Key: Medium Error [current] sr 6:0:1:0: [sr0] Add. Sense: L-EC uncorrectable error
b) many lines like this Buffer I/O error on device sr0 end_request: I/O error, dev sr0, sector 1380478
[...]
This looks like a broken CD.
Please check the CD using 'readcd -c2scan dev=/dev/cdrom'.
regards, -mika-
Michael Prokop schrieb:
Please check the CD using 'readcd -c2scan dev=/dev/cdrom'.
You were right, Mika! "The following 2 sectors could not be read correctly: 345117 345118"
I burned a new CD and now it works! Thanks for your assistance, Hubert
participants (6)
-
Hubert Gabler -
J�rg W�lke -
Maurice McCarthy -
Michael Prokop -
Michael Schierl -
moss＠mythic-beasts.com