Development of 32 Bit WeeDog Void Linux Base

[rockedge]

I found on some systems that pmcputemp is not displaying the changing temp. values at all.
The fix on those machines has been to modify the /root/.config/pmcputemp/pmcputemprc file.
From :

Code: Select all

 /sys/devices/virtual/thermal/thermal_zone0/temp

to :

Code: Select all

/sys/devices/virtual/thermal/thermal_zone1/temp

Then pmcputemp began to display the changing temp. values in the tray indicator.

[wiak]

Hello @fredx181

After "Run /init as init process" is the creating and loading the /upper_changes directory and the /work directory also is created. When this runs successfully the output text is red and /upper_changes merged as the top layer.

This may be where to start debugging. I am going to attempt to re-create the boot failure.
Thanks for testing it out Fred.

My problem is that I don't get this issue on my current machine so nothing clear to debug. I'll try on some other machines I have. With WeeDog void the initrd rdshN debug breakpoints should work and help in the debug process. Long time since I looked at initrd/init script but I'll see if I can find where that Run /init message might be occurring. Very odd indeed that it self timeouts after as long as 15min. Presumably not finding the boot media for some reason, but in that case I wonder how it ever finds it... Bug finding is always beneficial though; helps make systems more rugged... for general wide range of machines.

[rockedge]

On some of the machines I tested on I had to use w_boot=/mnt/sdb2/WeeDog32-Void-2.2 until I figured out the w_bootfrom=UUID=04154b23-6616-40d7-b80d-52ac5f7126f8=/WeeDog32-Void-2.2 technique.

Code: Select all

title WeeDog32-Void-2.2 (initrd.gz)
  uuid 04154b23-6616-40d7-b80d-52ac5f7126f8
  kernel /WeeDog32-Void-2.2/vmlinuz  w_bootfrom=/mnt/sdb2/WeeDog32-Void-2.2
  initrd /WeeDog32-Void-2.2/initrd.gz

Here the the drawback is it has to be /mnt/sdb2 every time. But to debug it might be the way to go. Otherwise maybe try WeeDog32-Void-2.1, which uses the initramfs05.gz

Code: Select all

title WeeDog32-Void-2.2 (initrd.gz)
  uuid 04154b23-6616-40d7-b80d-52ac5f7126f8
  kernel /WeeDog32-Void-2.2/vmlinuz  w_bootfrom=UUID=04154b23-6616-40d7-b80d-52ac5f7126f8=/WeeDog32-Void-2.2
  initrd /WeeDog32-Void-2.2/initrd.gz

[wiak]

Just installed it to another old laptop. This time a 17in display Toshiba Satellite Pro P205-S6277 (manufactured around 2007 I think), but also a 64bit capable machine (Intel Core 2 Duo T5300 processor). It has an old Nvidia GeForce Go 7600 (G73M) graphics processor.

Once again booted without any issue and connected to my wifi network. Either of the following menu.lst stanza's worked for me. I don't know which, if any, is better. The first uuid line seems to be something to do with grub4dos, the more complicated UUID one is to do with WeeDogLinux init coding:

Code: Select all

title WeeDog32-Void-2.2a1 (initrd.gz)
  find --set-root uuid () afa4effa-e396-4872-b2d8-9648bf8e0a1b
  kernel /WeeDog32-Void-2.2/vmlinuz-5.9.13_1 w_bootfrom=UUID=afa4effa-e396-4872-b2d8-9648bf8e0a1b=/WeeDog32-Void-2.2
  initrd /WeeDog32-Void-2.2/initrd.gz

title WeeDog32-Void-2.2a2 (initrd.gz)
  uuid afa4effa-e396-4872-b2d8-9648bf8e0a1b
  kernel /WeeDog32-Void-2.2/vmlinuz-5.9.13_1 w_bootfrom=UUID=afa4effa-e396-4872-b2d8-9648bf8e0a1b=/WeeDog32-Void-2.2
  initrd /WeeDog32-Void-2.2/initrd.gz

I'll have to find some actual 32bit processor machine to see if that makes things trickier. I think I only have one such, my old Pentium M partly broken laptop, but I'm not sure what cupboard/box I have it gathering dust in...

What are the details of the machine you are testing this on Fred (and is it from usb stick or internal harddrive)?

EDIT: might be a usb driver/module issue/clash of course (currently I've just been testing installed to inbuilt harddrive). Currently the initrd/init auto loads some modules to pick up various usb specs (usb1,2 and 3 I think). Maybe older machine would like that not done? There is a kernel command line that can be used to tell initrd/init not to include a module (can't remember if it just excludes one selected module off the top of my head); I'll check for that.

EDIT2: It is one module you can either add or remove from the list initrd/init uses by default. To remove one named module, at menu.lst kernel line use: w_rmmodule=name_of_module (without the .ko extension). To add a module from those available in /lib/modules, at kernel line use w_addmodule=name_of_module. If machine is old it may be that I don't currently have module for usb1 used (I can't remember) or that usb3 module is clashing with earlier usb type - I'd have to check details of modules used by usb (I last discussed all that a year ago or thereabouts when rufwoof was having issues with usb3 and I needed to add a module to the overall initrd/init list to fix that; so I'll check that old discussion and any notes I may or may not have about it...). Meanwhile I've found my old Fujitsu Siemens Amilo Pentium M machine (which has broken hard drive and keyboard - I will try to get this WeeDog32 void booting on that via usb (it uses usb2).

[wiak]

Wow. I'm excited. Manged to boot on my old Fujitsu Siemens Amilo M1424 machine:

CPU 32bit Pentium M 740, which needs grub4dos menu.lst forcepae kernel line addition to work.
BIOS is from 2003, which is also when I think machine was first released.
That BIOS does NOT include/provide usb boot capability (which made things tricky for my test since its hard drive is badly corrupted and couldn't use that for the installation...).
Alas the hard drive is badly corrupted on my Amilo, but luckily the previous grub4dos bit still works from its hard disk. I cannot however install any distro onto that hard drive any more since too wrecked. I therefore put the WeeDog32 Void folder on usb. The Amilo has usb2 ports.

It booted as far as net_connect (wiakwifi configuration), but since wiakwifi wouldn't connect it then hung.

Fix was easy though. I rebooted my other WDL_Arch64 machine. Used filemanager to access the WeeDog32 Void folder on the usb and clicked on the 01firstrib_rootfs.sfs. That opens it up and allowed me to extract the etc/rc.local file in there. I then made a copy of that file in upper_changes/etc (on the usb - I didn't go to the trouble of rewriting the sfs - just used the upper_changes overlay to fix things), and edited it to comment out net_connect and set_time (just in case, I also commented out set_audio). Then I rebooted the old Amilo with that usb and it booted fine, without delay, straight to desktop.

I didn't have ethernet available to me so needed to get wiakwifi to connect. So whilst at the WeeDog32 Void desktop on the Amilo I simply used:

Code: Select all

geany /usr/local/bin/wiakwifi

to uncomment lines 9 and 10:

Code: Select all

wifi_driver="wext"
wpa_driver="-D${wifi_driver}"  # uncomment if specific required

I needed to do that for my old Amilo wifi card since it needs driver 'wext' and not the default otherwise used (whatever it is...).

Then wiakwifi successfully connected after entering following command in a terminal:

Code: Select all

wiakwifi reset

and providing the requested details of my wifi network.

Then I was able to post this message to the forum using Firefox 83 provided in WeeDog32 Void on the old Amilo usb install. It's okay in terms of responsiveness actually (to my surprise). Would be even better if installed to hard disk on the Amilo (rather than usb2) of course.

EDIT: the grub4dos menu.lst stanza used was like this:

Code: Select all

title WeeDog32-Void-2.2a2 (initrd.gz)
  uuid afa4effa-e396-4872-b2d8-9648bf8e0a1b
  kernel /WeeDog32-Void-2.2/vmlinuz-5.9.13_1 w_bootfrom=UUID=afa4effa-e396-4872-b2d8-9648bf8e0a1b=/WeeDog32-Void-2.2 forcepae
  initrd /WeeDog32-Void-2.2/initrd.gz

The old Amilo originally came with 512 MB RAM by the way. However, I upgraded that to its max of 1GB many years ago, so plenty for this experiment, and no doubt why it remains reasonably responsive even from usb2 install and with bang up to date Firefox...

wiak

[wiak]

I forgot to add that since the Amilo only had grub4dos part working, but no existing distro installed to its hard drive, I also had the issue of how to modify its menu.lst. Luckily, as history had it, I had an old copy of Puppy Linux 4.3.1 on a dusty cd, and the Fujitso Amilo can boot from CD... So I edited the menu.lst to add stanza for WeeDog32 Void using running Puppy Linux 4.3.1!

I would suggest, rockedge, that for your experimental iso tests you remove the calls to net_connect and set_time from rc.local and simply provide instuctions for once the system boots. Otherwise, if wiakwifi fails (which it certainly does on many older machines that also require driver 'wext' then the whole thing hangs. Better at this stage, therefore, to simply allow test to desktop and thereafter setting up internet connection (via ethernet or wifi) and then set_time, I'd say.

Things looking good to me overall though. Not sure why Fred's machine is hanging though. Need details about that machine. Perhaps some old machines simply don't like the modern kernel, or module clash like I said, which eventually resolved itself on Fred's machine??? (though old Amilo Pentium M 740 seemed to manage thus far anyway).

wiak

[fredx181]

@wiak and @rockedge

My machine is HP Compaq 6710b laptop, yes once it reaches the Desktop all seems to work fine (connect to ethernet, build menu, run firefox, all OK).
Frugal install on SSD harddisk, grub4dos bootloader used, my menu.lst entry:

Code: Select all

title WeeDog32-Void-2.2 (initrd.gz)
uuid 12e1e33f-47a6-4979-b13a-404e60f746b9
  kernel /WeeDog32-Void-2.2/vmlinuz-5.9.13_1  w_bootfrom=UUID=12e1e33f-47a6-4979-b13a-404e60f746b9=/WeeDog32-Void-2.2
  initrd /WeeDog32-Void-2.2/initrd.gz

I have many frugal installs on this partition, Puppy's, Dogs and a Weedog-Arch install, all booting fine (also running newest kernels OK, e.g. 5.10)
I will do some more testing later (e.g. install to USB, see if that makes a difference).
Here's a picture of what I see while hanging.

20201218_101637_764x573.jpg (112.33 KiB) Viewed 2212 times

Fred

[fredx181]

Ok, tried also now a frugal install on USB, same problem (as I could have expected), but....
For what it's worth: When booting from hardisk again, I found that pressing the ctrl key and holding it for a few seconds makes it go further in the boot process, I have no idea how/why

Fred

[wiak]

My machine is HP Compaq 6710b laptop, yes once it reaches the Desktop all seems to work fine (connect to ethernet, build menu, run firefox, all OK).
...
I have many frugal installs on this partition, Puppy's, Dogs and a Weedog-Arch install, all booting fine (also running newest kernels OK, e.g. 5.10)
...
Here's a picture of what I see while hanging.
20201218_101637_764x573.jpg

Fred

Hmmm. Most of the installations I make here are on HP Elitebook 2530p and the specs are not so different from your HP Compaq 6710b Fred. The only difference between the initrd.gz of WeeDog32 Void and WeeDog-Arch64 is, it seems to me, just the kernel/modules - very weird, especially since I'm not seeing any such hangs. And strange messages on your console just prior to the Run /init report line: for example, why is there anything about zswap??? I didn't/don't think that is used (not that I knew anyway). (EDIT: Shows how little I know - all these zswap lines and so on turned out to be pretty much the same on my system...) I've rarely seen a bug being the result of a bad md5sum, so this is probably useless:

Code: Select all

[root@bootstrap Downloads]# md5sum WeeDog32-Void-2.2.iso 
f9fda7623268bfa6046cd148c99d5702  WeeDog32-Void-2.2.iso

But that's the md5sum for the iso I'm using.

Even stranger that you use that machine for so many distros and no issue. Rockedge I hope you are not a member of Cozy Bears hackers and accidentally compromised Fred's HP Compaq via some SolarWinds auto-update. Certainly an interesting issue - wish I had the laptop here, but probably couldn't discover what is causing the problem by the looks of it...

If you add the following to the end of the grub menu.lst kernel line: w_rdsh0 w_rdsh1 w_rdsh2 w_rdsh3 w_rdsh4 w_rdsh5
breakpoints get inserted that cause the initrd/init to drop to a sh (enter to continue) at various points as the script progresses. It would be interesting to see if w_bootfrom media gets mounted on the way and if the overlay works (by default the overlay result ends up appearing at /mnt/layers/merged prior to the switch_root. So when w_rdsh4 breakpoint drops system to a shell, typing in ls -al /mnt/layers/merged should show the merged result of the overlays. But it looks like that stuff up to and including Run /init is way before the overlay anyway(??) - as if kernel not liked by your CPU maybe? (zswap, .fscrypt... what on earth is all that about). I'll need to reboot WDL_Void32 on this machine to see if I see any of these messages earlier in boot process. Will report back quickly thereafter.

[wiak]

So, turns out these messages you see before Run /init are pretty much the same as to be expected.

Only difference I get at that stage is that instead of your message:

sched_clock Marking stable...

I get message:

Unstable clock detected, switching default tracing clock to "global"

My boot messages also tell me that if I want to continue with "local" I should add to the grub kernel line:

trace_clock=local

I doubt it makes any difference, but you could also switch default tracing clock to "global" to see if makes a difference. In your case, since currently stable and thus staying local, you would add following to kernel line:

trace_clock=global

I imagine that will make no difference whatsoever though, but worth a try I suppose...

My screenshot (like yours) is attached (taken via android phone video of my booting system followed by screenshot of frames).

[rockedge]

Nah no hacker group for me. But while testing out the boot process, and I agree @wiak that it either there is a mechanism that can determine if net_connect and the other scripts relying on a network connection can and should run or be skipped and configured after the boot or just comment that out and have those functions completed after the desktop starts.

For fun on my test laptop (32 bit DELL INSPIRON E1505) I just used:

Code: Select all

xbps-install -u firefox

which updated firefox from version 83.0.2 to 84.0, to see how it goes. Which as I am posting from it, seems okay.

2020-12-18-141137_1680x1050_scrot.png (68.2 KiB) Viewed 2228 times

[rockedge]

To further diagnosis Fred's problem booting WeeDog32-Void, I am warming up an IBM ThinkPad T-42. Built in 2003 is 32 bit only has no hard drive and no battery since 2011. This machine runs all the 32 bit Puppy Linux's well, some with forcepae on the kernel command line.
So I will add the forcepae and see if it will boot WeeDog32-Void.

[wiak]

@fred

The attachment will likely not help, but I can't test it since I don't have the boot delay issue you have.

Could you kindly try rebooting but with the following seek_timeout.plug file (remove the dummy tar) placed in the same folder as the initrd.gz?

It will probably have no effect, but I'm just trying to nullify lines in initrd/init that cause 'setsid cttyhack sh' (just in case that is causing a hang, since I've seen some kernels not liking that hack). All the plug file does is unsets "debug" variable $2 (that's the idea anyway, and worked in simpler script test for that purpose). Probably nothing to do with the issue but who knows...? On the slim chance it did effect things, there would still be a delay I expect but hopefully much shorter. Otherwise, I have no idea and think just your system hates that kernel!

[rockedge]

The IBM T-42 ThinkPad is still booting WeeDog32-Void now for 10+ minutes so it looks like a good candidate for debugging the boot delay that fredx181 is experiencing. This T-42 also has only eth0 for connecting to a network.

Still looks like it's loading the SFS and not getting very far. This machine has 786 meg of RAM, which will run Puppy Linux Bionic32 surprisingly well. It needs the forcepae parameter added as does the Tahr-6.0.6 with a real time 32 bit kernel I compiled, but both run well and Tahr does really well both version 6.0.5 and 6.0.6.

Both Puppy Linux's are using pmedia=atahd which seems to work like pmedia=ataflash in this machine, and a 1 gig swap partition on this 8 gig USB stick.

I'll let it sit and see if anything happens. So far no errors to see.

[rockedge]

A convenient way to test ideas is to create /upper_changes manually inside the fresh WeeDog32-Void directory before the first boot. Adding then manually changes to the network_connect for example can be saved to /upper_changes and will then have effect on the boot process.

Surprise, Surprise!! The 2003 IBM T-42 finally booted! Connected via en2s1 to the network and htop reports 64 meg of RAM out of 740 meg.
Desktop works and is responsive and pretty quick. Firefox 83.0 works and is totally usable

• Pentium M 1.7 gigaherz CPU

• 740 meg RAM

• 8 gig USB stick drive

2020-12-18-173245_729x117_scrot.png (4.72 KiB) Viewed 2213 times

No hard drive and no battery.
I am going to turn on swapping and see how that goes. mtPaint seg faults though.
Now to time the reboot to actually see how long it takes.

[fredx181]

Tried the same as I have on latest DebianDogs in the init script, modprobe a lot more kernel modules.
Probably much more than needed, but works, and got positive reports from rcrsn51 in the DebianDog threads that it works well on several machines, booting ok also from emmc drive.
So rebuild the initrd.gz with below in init script and no delay for me anymore (initial RAM usage probably is a little higher).

Code: Select all

# Modules need loaded by initrd when using kernel from Void Linux
for m in overlay ablk_helper aes_i586 aes_x86_64 ahci amd64_edac_mod arc4 brd button cb710 cb710_mmc cciss cdrom crc16 crc32c_generic crc32_generic crc_itu_t cryptd crypto_simd DAC960 dm_mod dns_resolver drm drm_kms_helper ecb edac_core edac_mce_amd ehci_hcd ehci_pci exportfs ext2 ext4 f2fs fat fb_sys_fops ff_memless fscache fscrypto fuse gf128mulv gpio_generic grace hfs hfsplus hid hid_generic hid_keytouch hid_logitech hid_ortek hid_primax hid_roccat hid_roccat_arvo hid_roccat_common hid_roccat_isku hid_roccat_lua hid_roccat_ryos hid_roccat_savu hid_samsung hid_sunplus i2c_algo_bit i2c_hid ip6_udp_tunnel irqbypass isofs jbd2 joydev kms_helper kvm libahci libcrc32c libphy lockd loop lrw mbcache mmc_block mmc_core mptsas mptscsih mptspi mtip32xx mxm_wmi nbd nfnetlink nfs nfsv3 nfsv4 nf_tables nls_ascii nls_cp437 nls_iso8859_1 nls_utf8 ntfs nvme nvme_core ohci_hcd parport  scsi_mod scsi_transport_fc scsi_transport_sas scsi_transport_spi sdhci sdhci_acpi sdhci_pci sdhci_pltfm sdio_uart sd_mod sdricoh_cs sg soundcore squashfs sr_mod sunrpc sx8 syscopyarea sysfillrect sysimgblt tg3 thermal tifm_core tifm_sd tpm tpm_infineon tpm_tis tpm_tis_core uas udf udp_tunnel ufshcd uhci_hcd uio ums_alauda ums_datafab ums_eneub6250 ums_freecom ums_isd200 ums_jumpshot ums_realtek ums_sddr09 ums_sddr55 ums_usbat usb_common usbcore usbhid usb_storage vfat via_sdmmc vub300 wbsd wmi wmi_bmof xfs xhci_hcd xhci_pci xor xts xxhash zstd_decompresspata_acpi pata_ali pata_amd pata_artop pata_atiixp pata_atp867x pata_cmd64x pata_cs5536 pata_efar pata_hpt366 pata_hpt37x pata_it8213 pata_it821x pata_jmicron pata_marvell pata_mpiix pata_netcell pata_ns87410 pata_ns87415 pata_oldpiix pata_opti pata_pcmcia pata_pdc2027x pata_pdc202xx_old pata_rdc pata_rz1000 pata_sch pata_serverworks pata_sil680 pata_sis pata_triflex pata_via pcmcia pcmcia_core pcmcia_rsrc pdc_adma pppox pps_core psmouse ptp raid6_pq reiserfs rng_core sata_mv sata_nv sata_promise sata_qstor sata_sil sata_sil24 sata_sis sata_svw sata_sx4 sata_uli sata_via sata_vsc libata ata_generic ata_piix firewire_core firewire_ohci; do

EDIT: BTW, what do you think about what I wrote here (holding the ctrl key skipping the long delay):
viewtopic.php?p=12633#p12633
EDIT2: Tried with original initrd.gz suggestion from rockedge, added "seek_timeout.plug" to the frugal install folder and wiak's suggestion, added "w_rdsh0 w_rdsh1 w_rdsh2 w_rdsh3 w_rdsh4 w_rdsh5" to the kernel line.
Both had no effect, same delay, stuck at the "Run /init as init process".

Fred

[wiak]

Tried the same as I have on latest DebianDogs in the init script, modprobe a lot more kernel modules.
Probably much more than needed, but works, and got positive reports from rcrsn51 in the DebianDog threads that it works well on several machines, booting ok also from emmc drive.

Ah, okay, must not currently have the module your media device needs, but odd it manages to boot eventually.

Sure, I suppose I can extend the module list.

But prior to doing that, one other thing struck me, which I can test on my own HP. When I fitted an SSD drive to it, one of my distros struggled to boot (I can't remember the details but I think it just hung for long delay) but turned out I needed to change SATA Device Mode type from IDE type to AHCI in the HP computer BIOS. After that all worked - but most likely a different issue altogether so not applicable here - maybe extra modules is only solution - perhaps WeeDogArch64 had the driver built into the kernel and WeeDog32 Void kernel does not so some module load required (for some reason I suspect libcrc32c or some other crc file since issue was with both usb and your hard drive, but truly just guessing and I expect libcrc32c was loaded anyway as a dependency of some other loaded module.

[wiak]

Ok, tried also now a frugal install on USB, same problem (as I could have expected), but....
For what it's worth: When booting from hardisk again, I found that pressing the ctrl key and holding it for a few seconds makes it go further in the boot process, I have no idea how/why

Fred

Hmmm, I have no idea why that might be. But try that BIOS trick changing SATA Device Mode from IDE to AHCI (nah, don't think that will work - just grasping for ideas); this fixed a boot problem I had long ago when I changed my hard drive to SSD type. I guess the alternative would have been to use IDE sata device mode along with a different sata module than what distro initrd provided or, if not, would be interesting to know which exact module it was. Remember, you can alternatively also add single extra modules to the booting initrd via the kernel command line in WeeDog with w_addmodule=whatever (the problem being that requires you to identify which module was the offending/missing one).

It could also of course be the possibility that I've included some extra module that causes a problem with your system. For example, to get usb3 boot to work correctly on rufwoof's machine I think I included module uas. If that was causing a problem with other machine then it can be bypassed via kernel line argument w_rmmodule=uas (and similarly if it was a different extra module that caused the hang).

I'll compare that module list that worked for you with the existing one to see what differs (plus and minus).

EDIT: Here is something that really annoys me about module naming that I'm well used to having come across it before. Makes comparisons annoying/hard (e.g. unnecessarily having to use sed or tr in processing). It isn't very consistent since lib/modules seems to adopt either form. You can also run into problems when the lib/modules naming results in being seen differently by lsmod:
http://lkml.iu.edu/hypermail/linux/kern ... /0476.html

Dnia 27-12-2004, pon o godzinie 19:38 +0000, AJM napisał(a):
> I have compiled stock (kernel.org) 2.6.3 and 2.6.9 kernels which exhibit
> the following unusual behaviour on module loading: If the kernel module
> has a hyphen in its name, then this appears to be translated into an
> underscore by the kernel, such that, for example after "insmod 3w-xxxx",
> lsmod shows "3w_xxxx", "rmmod 3w-xxxx" fails but "rmmod 3w_xxxx" succeeds.

> Any suggestions as to why this is happening?

That convenience thing, look at man modprobe:

modprobe intelligently adds or removes a module from the Linux kernel:
note that for convenience,there is no difference between _ and
- in module names.

modprobe may be 'intelligent' but clearly rmmod isn't...

[wiak]

Hello again Fred,

I would find it useful, now that you are using a modified initrd for that Compaq of yours, when using rockedge WeeDog32 Void, if you could post me the after-boot lsmod result. Actually, if you could also post the after-boot lsmod result for the previous initrd used when booting that distro, it would be interesting to compare.

wiak

[wiak]

A convenient way to test ideas is to create /upper_changes manually inside the fresh WeeDog32-Void directory before the first boot. Adding then manually changes to the network_connect for example can be saved to /upper_changes and will then have effect on the boot process.

Surprise, Surprise!! The 2003 IBM T-42 finally booted!

Yes, manually using upper_changes in the way you describe is exactly what I do too.

That IBM T-42 also finally booting. Isn't that the weirdest thing that it somehow eventually manages. I can accept/understand that a missing module (or more) is what causes the issue, but how on earth does the machine eventually manage anyway (prior to any extra modules being added)!!! That's what surprises me most. I suppose some attempt failed because missing modules and attempt goes on till some crazy timeout and thereafter turns out module wasn't essential anyway so boots regardless in the end - stupid computers.

[rockedge]

It took the T-42 about 15-18 minutes to boot. Then works surprisingly well! Except mtPaint segmentation faulting. But overall really works and as fast as Bionic32 and the different Tahrpups

[fredx181]

Did some debugging (to have the option "w_debug=0" is great!) and found that the kernel module "ata_piixx" is the one that modprobe got stuck on, removed some modules from the (default) list to be "modprobed" and moved "ata_piixx" to last , with this in "init", booting goes fine, no delay anymore:

Code: Select all

for m in mbcache ext4 fat vfat fuse isofs nls_cp437 nls_iso8859-1 nls_utf8 reiserfs squashfs xfs libata ahci libahci sata_sil24 pdc_adma sata_qstor sata_sx4  sata_mv sata_nv sata_promise sata_sil sata_sis sata_svw sata_uli sata_via sata_vsc pata_ali pata_amd pata_artop pata_atiixp pata_atp867x pata_cmd64x pata_cs5520 pata_cs5530 pata_cs5536 pata_efar pata_hpt366 pata_hpt37x pata_it8213 pata_it821x pata_jmicron pata_marvell pata_netcell pata_ns87415 pata_oldpiix pata_pdc2027x pata_pdc202xx_old pata_rdc pata_sc1200 pata_sch pata_serverworks pata_sil680 pata_sis pata_triflex pata_via pata_mpiix pata_ns87410 pata_opti pata_rz1000 ata_generic loop cdrom hid hid_generic usbhid mptscsih mptspi mptsas tifm_core cb710 mmc_block mmc_core sdhci sdhci-pci wbsd tifm_sd cb710-mmc via-sdmmc vub300 sdhci-pltfm scsi_mod scsi_transport_spi scsi_transport_sas sd_mod sr_mod usbcore ehci-hcd ehci-pci ohci-hcd uhci-hcd xhci-pci xhci-hcd usb-storage uas ata_piix;do

Still mysterious to me that when holding "ctrl" key the booting goes fine with the old list, what does it do? It skips loading the "ata_piixx" module ?
(lsmod says after boot that it is loaded, btw)

@rockedge when you boot on your thinkpad, is the hang point same as for me ? "Run /init as init process"
If so, can you try modifying initrd.gz with above in init and see if that makes a difference ?

EDIT:

turned out I needed to change SATA Device Mode type from IDE type to AHCI in the HP computer BIOS

Had a look at that, but no such option in BIOS for my computer.

EDIT2: That the above module list works on my computer doesn't say that it works in general, if you ask me, I think there's something strange with this kernel.

Fred

[rockedge]

On the ThinkPad it seems to be the loading of firstrib_rootfs.sfs that is the delay. As far as I can tell at the moment, it begins to hang right at the beginning of the boot cycle. Once it reaches the point you are seeing, it boots clean through to the desktop.

I am interestingly looking at your discoveries Fred!

IMG_1094.JPG (39.24 KiB) Viewed 2207 times

took 22 minutes to boot just now from photo to desktop. But here is the desktop running well. I wonder about pushing and holding the CTRL key in this situation.

[fredx181]

On the ThinkPad it seems to be the loading of firstrib_rootfs.sfs that is the delay. As far as I can tell at the moment, it begins to hang right at the beginning of the boot cycle. Once it reaches the point you are seeing, it boots clean through to the desktop.

I am interestingly looking at your discoveries Fred!

IMG_1094.JPG

took 22 minutes to boot just now from photo to desktop. But here is the desktop running well. I wonder about pushing and holding the CTRL key in this situation.

Ok Rockedge, thanks, it seems that the start of the delay happens at much earlier point for you than for me, so probably modifying the initrd.gz doesn't work for you to decrease the delay.

Fred

[wiak]

found that the kernel module "ata_piixx" is the one that modprobe got stuck on

Interesting... I note from modules.dep that ata_piix doesn't have any module dependencies. I can only surmise that some other module that needed loaded didn't like ata_piix already being loaded (EDIT: no, that can't be the reason - you say that ata_piix is the one having trouble loading - it must may have tried to load while another clashing module was still in load process but okay once earlier module load completed), though that definitely seems like kernel module code issues since deadlocks are supposed to be avoided in code (I have come across old threads where module lockups occurred when two modules were modprobed at almost the same time, but kernel developers added some code to avoid that at the time. Luckily for me, I don't have any of these problems on the machines I've tested on thus far, but may well be a problem more generally though loading ata_piix might be worth making permanent since no issue with that.

I do have an initial delay much earlier, but less than 30 secs so nothing I thought about much since I often get minor delay at early stage for most distros I load. But it does seem rockedge's Thinkpad delay is likely before that module loading period. Yes, I forgot about w_debug being in there - as you know now it echos each module being loaded, so can identify hanging one - rockedge should try adding that to his kernel line before bootings to see if anything revealed.

As for the ctrl key 'fix' - my only guess is that that somehow causes minor delay between modules being loaded enough that deadlock avoided, but no doubt the reason for that mystery is nothing I'm imagining or postulating at all...

Oh well, Void is rolling distro - let's hope next release doesn't exhibit same issue.

EDIT2: From what you say Fred. Rather than changing the module list at all, adding the following onto grub menu.lst kernel line should work on your machine:

Code: Select all

w_rmmodule=ata_piix w_addmodule=ata_piix

since that prevents original modprobe of ata_piix but then modprobes it at the end.

wiak

[wiak]

On the ThinkPad it seems to be the loading of firstrib_rootfs.sfs that is the delay.

What happens if you use uncompressed firstrib_rootfs directory instead of 01firstrib_rootfs.sfs? i.e. Rename uncompressed firstrib_rootfs/ to 01firstrib_rootfs/ and disable loading of 01firstrib_rootfs.sfs by say renaming it to N01firstrib_rootfs.sfs.

I doubt any better, since as I say above I often get short early delay and that occurs well before rootfs getting loaded (even before modules being loaded). Does that Thinkpad have usb1 or usb2 interfaces? The initrd is pretty big the way we have it, which isn't much of a problem on usb2 but I guess would take a while to load in to RAM via usb1 (but not as long as delay you are mentioning I'm sure). But since it works with forcepae I imagine it also has usb2 ports by that model anyway.

[wiak]

Ridiculously, I keep hoping one of the laptops I boot this WDL Void32 from will have one of the big delays you have on certain machines. Alas, all four laptops tried thus far boot without complaint. This time booting from usb2 (machine has no hard drive) on emachines netbook which has N570 Intel Atom processor on it. No issues, posting from it (via wiakwifi wifi connection now). Runs perfectly fine, by the way, on this, which has a typical old netbook screen resolution of 1024x600 (had earlier upgraded it to 2GB RAM).

I think I have one last older machine, that may or may not be broken, to dig out of the cupboard to try. I think it is an older Toshiba Satellite, that has Celeron processor, but I can't remember off the top of my head. I do know it used to be a bit fussy about which distros could boot it, but I kind of remember it giving up the ghost entirely in the end. If I can find it and also its power supply I will soon know.

By the way, it strikes me that a 32 bit distro isn't intended for newer computers. Most any computer from the past ten years is likely to be 64bit capable, so I don't think such a recent kernel is the best fit anyway. Void must have some alternative kernel/modules that could surely be used instead and maybe without the boot delay issue?

[wiak]

Oh well, even the awful Toshiba Satellite 1130 heap of Intel Celeron Mobile rubbish (32bit) booted fine and without delay. Mtpaint did not segfault. This processor didn't actually need forcepae, but horrible machine anyway - falling to bits - not worth the electricity it uses to switch it on actually. But it worked okay with that WeeDog32 Void. How come none of my machines are willing to give me that nice 10min or more boot delay? I guess I'm lucky. The Tosh Sat 1130 also loads that ati_piix module but without issue using original initrd.gz.

I'll be interested to know if, using original initrd.gz, that kernel line suggestion works for you:

w_rmmodule=ati_piix w_addmodule=ati_piix

since, as I said, the effect of that will be to put ati_piix as last module loaded.

[fredx181]

Hi wiak,

I'll be interested to know if, using original initrd.gz, that kernel line suggestion works for you:

w_rmmodule=ati_piix w_addmodule=ati_piix

I tried that, same delay.

The module list that I previously posted had some modules removed (removing the 2>/dev/null from modprobe line showed me some not found in modules.dep, so removed them from list)
Did a lot of experimenting, and now I found that only one of them, pata_cs5535 is needed to remove, together with moving ata_piix to the end, I tried booting with original initrd.gz and this:

Code: Select all

w_rmmodule=pata_cs5535 w_rmmodule=ata_piix w_addmodule=ata_piix

But that didn't work out, I think only one module can be removed with this w_rmmodule= way ?

The list that I use now and works is:

Code: Select all

# Modules need loaded by initrd when using kernel from Void Linux
for m in mbcache aufs exportfs ext4 fat vfat fuse isofs nls_cp437 nls_iso8859-1 nls_utf8 reiserfs squashfs xfs libata ahci libahci sata_sil24 pdc_adma sata_qstor sata_sx4 sata_mv sata_nv sata_promise sata_sil sata_sis sata_svw sata_uli sata_via sata_vsc pata_ali pata_amd pata_artop pata_atiixp pata_atp867x pata_cmd64x pata_cs5520 pata_cs5530 pata_cs5536 pata_efar pata_hpt366 pata_hpt37x pata_it8213 pata_it821x pata_jmicron pata_marvell pata_netcell pata_ns87415 pata_oldpiix pata_pdc2027x pata_pdc202xx_old pata_rdc pata_sc1200 pata_sch pata_serverworks pata_sil680 pata_sis pata_triflex pata_via pata_isapnp pata_mpiix pata_ns87410 pata_opti pata_rz1000 ata_generic loop cdrom hid hid_generic usbhid mptscsih mptspi mptsas tifm_core cb710 mmc_block mmc_core sdhci sdhci-pci wbsd tifm_sd cb710-mmc via-sdmmc vub300 sdhci-pltfm scsi_mod scsi_transport_spi scsi_transport_sas sd_mod sr_mod usb-common usbcore ehci-hcd ehci-pci ohci-hcd uhci-hcd xhci-pci xhci-hcd usb-storage xts uas ata_piix;do

Only differences with original are: removed pata_cs5535, moved ata_piix to the end.
pata_cs5535 is one of the modules not found in modules.dep, does that have to do with it
Oh well... I wish I could explain why above is working for me, very frustrating!

Fred

[wiak]

pata_cs5535 is one of the modules not found in modules.dep, does that have to do with it

Yes, that's odd. If pata_cs5535 isn't in modules.dep that suggests it isn't available as one of the modules anyway, so modprobing it should do nothing anyway! So can't see why removing it from modules list should have any effect (except for the slight delay caused by attempting to modprobe a non-existent module failing I suppose). Oh well. Maybe an earlier kernel for 32bit machines would not result in this issue. I might in any case later amend the w_rmmodule and w_addmodule code to allow for more than one module in each such list for such tricky cases as this one; easy to arrange - had thought about doing it, though of course it is always painful finding what modules are causing issues whilst hoping to keep list as small as proves general purpose. On the whole the problem seems like a timing issue - really seems like a somewhat messed up kernel since the kernel is responsible for loading modules without deadlocks/delays occurring. As I mentioned, I came across a kernel discussion thread discussing a similar but different issue with module load timing causing deadlocks - it was recognised for that one that loading one of the modules much earlier fixed that particular problem but it was also agreed that that was just a fudge really and that the kernel code itself should make sure such deadlocks didn't occur - seems like this particular kernel isn't quite right in that regard.