LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 08-26-2019, 03:45 AM   #16
Exaga
Member
 
Registered: Nov 2012
Posts: 188

Rep: Reputation: 89

Quote:
Originally Posted by elyk View Post
This gives me /dev/root (I believe this happens when there is no initrd) and /dev/root does not exist. findmnt gives me better results:

Code:
# findmnt --target=/ --output=SOURCE --noheadings
/dev/mmcblk0p2
Quote:
Originally Posted by drmozes View Post
I was looking for the same tool as 'rdev' in busybox, but it seemed to involve multiple commands and trawling /dev.
I didn't know of findmnt - thanks!
Neither was I, aware of findmnt. Very cool.

Code:
root@torq:~# findmnt --target=/ --output=SOURCE --noheadings
/dev/mmcblk0p3
This method is much better. Thank you elyk. Thank you MoZes. <3

Slackware ARM Linux community teamwork!
 
Old 08-27-2019, 10:51 AM   #17
Exaga
Member
 
Registered: Nov 2012
Posts: 188

Rep: Reputation: 89
Quote:
Originally Posted by drmozes View Post
As I was looking at this, I unpacked "kernel_sarpi3". In its 'install/doinst.sh' you have:
Code:
# Start with a wild guess
rootdev='mmcblk0p3'
if [ -L dev/root ]; then
  rootdev=/dev/$(readlink dev/root)
...
I'm not sure this guesswork is necessary, but I haven't read the instructions or ever installed it.
For the Slackware installer, the target root file system is known because it's mounted under /var/log/mount (IIRC - it's something like that), and you could make the doinst.sh script automatically determine it, since installpkg doesn't chroot the execution of doinst.sh scripts.
OK. I've revised this code and I'll show you because I want your opinion. The damnedest thing is determining what the root / device is going to be; post-installation but pre-reboot. Can't use findmnt for that as it detects the current root device as 'rootfs' while still in the installer. The proper way I can see to do this is to invoke the /tag/README file to indicate the status of the running system.

So, I'm wanting to do this the most suitable way and eradicate all possibility of future problems on this issue. I've been playing with this code over the last day or so and tried all kinds of weird ways of setting up the system and testing with it. No problems at all as long as we're in a post-installation but pre-reboot state while in the installer. Installing on an already-installed Slackware ARM system works like a charm. If anybody wants to attempt to install SARPi packages outside of those two environments I'm not interested to know why or the results of doing so. lol

Here's the proposed doinst.sh code for the SARPi kernel-x.x.x package:

Code:
# Determine status of system 'rootdev' 
if [ -f /tag/README ] ; then 
  # Get 'rootdev' from /etc/fstab if in miniroot installer
  ROOTDEV=$(cat /mnt/etc/fstab | grep " / " | cut -d' ' -f1)
elif [ -b /dev/mmcblk0p2 ]; then
  # Get 'rootdev' via findmnt on installed system
  ROOTDEV=$(findmnt -n -o SOURCE /)
else
  # Assume the default 'rootdev' 
  ROOTDEV='/dev/mmcblk0p3'  
fi

# Write 'rootdev' to cmdline .new file
sed -i -e "s|@DEVROOT@|${ROOTDEV}|" boot/cmdline.txt.new
I'm not entirely happy using cat /mnt/etc/fstab | grep " / " | cut -d' ' -f1 like this, but it works. If you know a more suitable and assured way, of getting the 'rootdev' from a system [that's different from the currently running system] whose root device we want to know which hasn't been booted yet, I'll be very grateful.

Last edited by Exaga; 08-27-2019 at 10:57 AM. Reason: grammar
 
Old 08-28-2019, 08:39 PM   #18
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 217

Original Poster
Rep: Reputation: 34
Makes sense to me.

Could you grab whatever's currently mounted at /mnt for the install-time check, or is there any reason why it wouldn't be the rootdev?
 
Old 08-29-2019, 02:26 AM   #19
Exaga
Member
 
Registered: Nov 2012
Posts: 188

Rep: Reputation: 89
Quote:
Originally Posted by elyk View Post
Makes sense to me.

Could you grab whatever's currently mounted at /mnt for the install-time check, or is there any reason why it wouldn't be the rootdev?
I'm not 100% clear on what you mean or what it entails. During Slackware ARM installation /mnt directory is used by 'setup' to mount the target partition(s). Is there a way to find out from within the minirootfs and /mnt what the rootdev will be once the system has rebooted? Post-installation but pre-reboot; unless there is some other means by which the rootdev can be determined, this is the only way I can see to achieve it.

Code:
cat /mnt/etc/fstab | grep " / " | cut -d' ' -f1
Perhaps in my auld-skool way of thinking, and for Slackware ARM on the Raspberry Pi in particular it may not be so relevant, but in my mind 'mount' is not always an assured and/or totally robust solution. Especially when the root device is mounted from an external (USB) device. I'm sure you've had the "kernel panic - unable to mount root fs" error at some point in such cases. A number of methods might be used to ascertain the rootdev but which is the most acceptable and reliable? Using 'mount' in this way is the lesser of a few other questionable choices, in my opinion, and in most cases it should work. Though, I bet it wouldn't be too difficult to find examples of when it doesn't; as it was with your case and the existing code that is used for this purpose.

My conundrum is querying the existing system to find out what the root device will be once it's rebooted into a fully installed Slackware ARM system (i.e. not running from the miniroot installer). I cannot see any other way to achieve this than grabbing it from '/mnt/etc/fstab'. I hoped that MoZes might be able to offer some enlightenment and reflection on this issue. Or anybody else towards that end.
 
Old 08-29-2019, 04:31 AM   #20
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 850

Rep: Reputation: 639Reputation: 639Reputation: 639Reputation: 639Reputation: 639Reputation: 639
Quote:
Originally Posted by Exaga View Post
I'm not 100% clear on what you mean or what it entails. During Slackware ARM installation /mnt directory is used by 'setup' to mount the target partition(s). Is there a way to find out from within the minirootfs and /mnt what the rootdev will be once the system has rebooted?
Code:
sed -i -e "s:@ROOTDEV@:${rootdev}:" boot/cmdline.txt.new
What is this cmdline.txt for? does it set the Kernel parameters, so it'd expand to root=/dev/xxx ?

Quote:
My conundrum is querying the existing system to find out what the root device will be once it's rebooted into a fully installed Slackware ARM system (i.e. not running from the miniroot installer).
Btw, the "miniroot" is not related to the installer - the installer uses busybox to provide a light weight but well-featured environment. Some of the real Slackware packages are also present to fill gaps in busybox's offering, or to provide a full implementation.
In contrast, the miniroot has a number of the full packages installed and archived so that you don't need to use the installer, and can have a reasonably useful system that has network access, allowing you to build further upon it.

Quote:
I cannot see any other way to achieve this than grabbing it from '/mnt/etc/fstab'. I hoped that MoZes might be able to offer some enlightenment and reflection on this issue. Or anybody else towards that end.
I might be wrong here as I haven't touched that stuff in years, but you may be able to use findmnt even if it outputs a numerical value.
The error you quoted about not being able to find the root filesystem comes from the Kernel. As long as whatever file systems/volume systems are ready when the Kernel wants to enter the OS's file system, it ought to work. If you're using an initrd, all of that stuff would need to be in there or compiled into the Kernel.

On one of my systems:
Code:
prisere [rust] # df -h
Filesystem                  Size  Used Avail Use% Mounted on
/dev/root                   915G  518G  351G  60% /
Code:
prisere [rust] # findmnt --target=/ --output=SOURCE --noheadings
803
Code:
prisere [rust] # grep "8 " /proc/devices
128 ptm
188 ttyUSB
248 hpilo
  8 sd
 68 sd
128 sd
So we know it's a scsi device . Which one?

Code:
prisere [rust] # ls -la /dev/sd*
brw-rw---- 1 root disk 8,  0 Jul  9 06:57 /dev/sda
brw-rw---- 1 root disk 8,  1 Jul  9 06:57 /dev/sda1
brw-rw---- 1 root disk 8,  2 Jul  9 06:57 /dev/sda2
brw-rw---- 1 root disk 8,  3 Jul  9 06:57 /dev/sda3
brw-rw---- 1 root disk 8, 16 Jul  9 06:57 /dev/sdb
It's sda3 because its minor number is 3.

As "mount" confirms:

Code:
prisere [rust] # mount
/dev/sda3 on / type ext4 (rw)
And the Kernel boot parameter specifies the combination of major and minor numbers directly.

Code:
prisere [rust] # cat /proc/cmdline
auto BOOT_IMAGE=Linux ro root=803 vt.default_utf8=0

As long as those major and minor numbers don't change, it'd work. Unless you're moving your hardware around, they ought to remain the same - just as your root is always /dev/sda unless you move it around physically in the SCSI/SATA chain, or (I think) edit udev config to map it to be something else.

Other that that I don't have any other ideas.

Last edited by drmozes; 08-29-2019 at 04:33 AM.
 
1 members found this post helpful.
Old 08-29-2019, 12:21 PM   #21
Exaga
Member
 
Registered: Nov 2012
Posts: 188

Rep: Reputation: 89
Thanks for taking the time to reply on this issue.

Quote:
Originally Posted by drmozes View Post
Code:
sed -i -e "s:@DEVROOT@:${ROOTDEV}:" boot/cmdline.txt.new
What is this cmdline.txt for? does it set the Kernel parameters, so it'd expand to root=/dev/xxx ?
Yes, exactly. The cmdline.txt file contains kernel boot settings which override any settings specified in the kernel itself. The '@DEVROOT@' is a tag in the cmdline.txt.new file that will be replaced by ${ROOTDEV} which is a '/dev/xxx' value that's being determined by my proposed code.

Quote:
Originally Posted by drmozes View Post
Btw, the "miniroot" is not related to the installer - the installer uses busybox to provide a light weight but well-featured environment. Some of the real Slackware packages are also present to fill gaps in busybox's offering, or to provide a full implementation.
In contrast, the miniroot has a number of the full packages installed and archived so that you don't need to use the installer, and can have a reasonably useful system that has network access, allowing you to build further upon it.
Sure thing. I sometimes (and incorrectly) refer to your miniroot as the installer and vice versa because that's the main purpose for which SARPi uses/needs it. The minirootfs is great and I personally find it especially useful for getting out of multiple sticky situations.

Quote:
Originally Posted by drmozes View Post
I might be wrong here as I haven't touched that stuff in years, but you may be able to use findmnt even if it outputs a numerical value.
The error you quoted about not being able to find the root filesystem comes from the Kernel. As long as whatever file systems/volume systems are ready when the Kernel wants to enter the OS's file system, it ought to work. If you're using an initrd, all of that stuff would need to be in there or compiled into the Kernel.

As long as those major and minor numbers don't change, it'd work. Unless you're moving your hardware around, they ought to remain the same - just as your root is always /dev/sda unless you move it around physically in the SCSI/SATA chain, or (I think) edit udev config to map it to be something else.

Other that that I don't have any other ideas.
You're not wrong. I've gone down the numbers (i.e. /dev/block/) route and in my opinion it's just an extra-convoluted way of ascertaining the same information with no more, and certainly no less, accuracy. I can specify any 'root=/dev/xxx' I like in the kernel but it is undermined by the settings in cmdline.txt file. For instance, with '/dev/mmcblk0p3' set as root device in the kernel, here's a 'lsblk' output; post-installation but pre-reboot, and apres-installation/reboot. In this instance, I set the root partition intentionally as '/dev/mmcblk0p2' for Slackware ARM installation and first-boot testing. The block device MAJ:MIN are identical in both environments.

Code:
root@slackware:~# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    1  14.9G  0 disk /usb-stick
mmcblk0     179:0    0  29.2G  0 disk
|-mmcblk0p1 179:1    0 101.6M  0 part /mnt/boot
|-mmcblk0p2 179:2    0  28.1G  0 part /mnt
`-mmcblk0p3 179:3    0   980M  0 part [SWAP]

root@torq:~# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk0     179:0    0  29.2G  0 disk
├─mmcblk0p1 179:1    0 101.6M  0 part /boot
├─mmcblk0p2 179:2    0  28.1G  0 part /
└─mmcblk0p3 179:3    0   980M  0 part [SWAP]
Here's the 'cat fstab' | 'grep /' output; post-installation but pre-reboot, and apres-installation/reboot. The root device is identical in both environments.

Code:
root@slackware:~# cat /mnt/etc/fstab | grep " / " | cut -d' ' -f1
/dev/mmcblk0p2

root@torq:~# cat /etc/fstab | grep " / " | cut -d' ' -f1
/dev/mmcblk0p2
With the code I'm using it works, and has worked, like a charm throughout. It was the same on another test system where the root device I'd setup as '/dev/mmcblk0p5'. I don't presume to cater for and cover every possible scenario and setup or configuration. Just 99.9% of them. Which I think with the code I'm proposing it accommodates most users and I'm happy with that. I wasn't able to figure out a suitable 'findmnt' solution, if there is one.

Thanks again MoZes. Much appreciated.
 
Old 08-29-2019, 08:53 PM   #22
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 217

Original Poster
Rep: Reputation: 34
Quote:
Originally Posted by Exaga View Post
I'm not 100% clear on what you mean or what it entails.
I was thinking something like this, where we find the device that's mounted at /mnt:
Code:
if [ -f /tag/README ] ; then
  ROOTDEV=$(findmnt --target=/mnt --output=SOURCE --noheadings)
...
Unless there's some scenario where that's incorrect. Substitute that findmnt command with something equivalent if findmnt isn't available in the miniroot.


Another thought: The installation instructions tell you to run this:
Code:
ROOT=/mnt installpkg /rpi-extra/kernel* /rpi-extra/sarpi*
Is the ROOT environment variable propagated to doinst.sh? If so, then we could use $ROOT instead of "/mnt" to make it a little more robust.
 
Old 08-29-2019, 10:49 PM   #23
Exaga
Member
 
Registered: Nov 2012
Posts: 188

Rep: Reputation: 89
Quote:
Originally Posted by elyk View Post
I was thinking something like this, where we find the device that's mounted at /mnt:
Code:
if [ -f /tag/README ] ; then
  ROOTDEV=$(findmnt --target=/mnt --output=SOURCE --noheadings)
...
Unless there's some scenario where that's incorrect. Substitute that findmnt command with something equivalent if findmnt isn't available in the miniroot.
'findmnt' is available in the minirootfs. It just wouldn't play ball for me and no matter what command options I tried 'findmnt' wouldn't accept that '/mnt' was the root device. It would be nice if you could tell me you have tested this code yourself and can confirm it's efficacy. Since yesterday I have shut down the test systems and am back on the production-run again. Had you mentioned this 8-10 hours ago it could have easily been implemented and tested. 'findmnt' can use major:minor device numbers which would then bring MoZes' suggestion into play and that is a much better solution in my opinion. I'd prefer to use 'findmnt' rather than the 'mount' method.

Quote:
Originally Posted by elyk View Post
Another thought: The installation instructions tell you to run this:
Code:
ROOT=/mnt installpkg /rpi-extra/kernel* /rpi-extra/sarpi*
Is the ROOT environment variable propagated to doinst.sh? If so, then we could use $ROOT instead of "/mnt" to make it a little more robust.
When the packages are installed at the end of Slackware ARM installation the command used is: ROOT=/mnt installpkg yadda-yadda-yadda*

So yes.
 
Old 08-30-2019, 12:56 AM   #24
Exaga
Member
 
Registered: Nov 2012
Posts: 188

Rep: Reputation: 89
The next thing to test then is 'ROOT=/mnt findmnt' while running on the minifootfs...

[EDIT] OK. Thanks very much. You've inadvertently assisted me in solving more than one problem. It might have created more work though. I'm not sure what caused it yet.

The 'findmnt' [-options] command required is: findmnt --target=/mnt --output=SOURCE -o MAJ:MIN --noheadings

Here's some progressive output:

Code:
root@slackware:~# findmnt -s --fstab /mnt --evaluate
root@slackware:~# findmnt -s /mnt --evaluate
root@slackware:~# findmnt /mnt --evaluate
TARGET SOURCE         FSTYPE OPTIONS
/mnt   /dev/mmcblk0p5 ext4   rw,relatime
root@slackware:~# lsblk | grep -w "/mnt$"
`-mmcblk0p5 179:5    0    16G  0 part /mnt
root@slackware:~# df -h
Filesystem                Size      Used Available Use% Mounted on
devtmpfs                  8.0M         0      8.0M   0% /dev
tmpfs                     1.9G         0      1.9G   0% /dev/shm
/dev/mmcblk0p5           15.7G      6.9G      8.0G  46% /mnt
/dev/mmcblk0p4           11.8G     30.2M     11.1G   0% /mnt/tmp
devtmpfs                  8.0M         0      8.0M   0% /mnt/dev
devtmpfs                  8.0M         0      8.0M   0% /mnt/dev
root@slackware:~# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk0     179:0    0  29.2G  0 disk
|-mmcblk0p1 179:1    0 137.3M  0 part
|-mmcblk0p2 179:2    0     1G  0 part [SWAP]
|-mmcblk0p3 179:3    0     1K  0 part
|-mmcblk0p4 179:4    0    12G  0 part /mnt/tmp
`-mmcblk0p5 179:5    0    16G  0 part /mnt
root@slackware:~# findmnt --target=/mnt --output=SOURCE -o MAJ:MIN  --noheadings
179:5
This was not the same test system I'd used previously although it has been setup in the same way so that 'root=/dev/mmcblk0p5', just to be intentionally awkward and purposefully non-standard. I started over completely with a fresh installation and specifically tested with 'ROOT=/mnt findmnt /mnt' etc. Alas, it didn't make any difference. But, I did find in this instance that 'findmnt' is working as expected! Previously it would only find the '0:1' device RAM disk. I have no clue why and can only surmise that I've botched something on the old test system with all my fiddling around and jiggery-pokery which hasn't helped - only to further complicate matters. I'm hoping so anyway. Also, I was using the 'findmnt -s --fstab --target=/mnt [etc.]' command options and variations to source the root device, which still isn't working. While your advised command -options is working, as you can see.

[EDIT #2] The current code worked as expected but I'll change it to use 'findmnt' instead

Code:
Executing install script for sarpi4-hacks-4.0-armv7l-1_slackcurrent_29Aug19_sp1.txz.
Package sarpi4-hacks-4.0-armv7l-1_slackcurrent_29Aug19_sp1.txz installed.
 
root@slackware:~# cat /mnt/boot/cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 nofont root=/dev/mmcblk0p5 rootfstype=ext4 rootwait ro

Last edited by Exaga; 08-30-2019 at 04:30 AM.
 
Old 08-30-2019, 03:23 AM   #25
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 217

Original Poster
Rep: Reputation: 34
Sorry I'm not faster, $DAYJOB gets in the way.

I just tried this with success in the miniroot. Worked for several different partitions and filesystems.

Code:
dwc_otg.lpm_enable=0 console=tty1 nofont root=@ROOTDEV@ rootfstype=@ROOTFS@ rootwait ro
Code:
sed -i -e "s|@ROOTDEV@|$(findmnt --target=$ROOT/ --output=SOURCE --noheadings)|" \
       -e "s|@ROOTFS@|$(findmnt --target=$ROOT/ --output=FSTYPE --noheadings)|" boot/cmdline.txt.new
The "/" after $ROOT handles when $ROOT is blank. It's what installpkg does.

On a side note, with sarpi3-installer_slackcurrent_29Aug19_sp1.img.xz I was having problems reading from a USB flash drive while in the miniroot and couldn't get my modified package onto the pi. I could list and stat files on the USB drive, but cp and cat always failed. Reverted to an older copy I still had (27Jun19) and had no problems. Not sure if the regression is in the kernel or elsewhere.
 
Old 08-30-2019, 10:10 AM   #26
Exaga
Member
 
Registered: Nov 2012
Posts: 188

Rep: Reputation: 89
Quote:
Originally Posted by elyk View Post
Sorry I'm not faster, $DAYJOB gets in the way.

I just tried this with success in the miniroot. Worked for several different partitions and filesystems.

Code:
dwc_otg.lpm_enable=0 console=tty1 nofont root=@ROOTDEV@ rootfstype=@ROOTFS@ rootwait ro
Code:
sed -i -e "s|@ROOTDEV@|$(findmnt --target=$ROOT/ --output=SOURCE --noheadings)|" \
       -e "s|@ROOTFS@|$(findmnt --target=$ROOT/ --output=FSTYPE --noheadings)|" boot/cmdline.txt.new
The "/" after $ROOT handles when $ROOT is blank. It's what installpkg does.

On a side note, with sarpi3-installer_slackcurrent_29Aug19_sp1.img.xz I was having problems reading from a USB flash drive while in the miniroot and couldn't get my modified package onto the pi. I could list and stat files on the USB drive, but cp and cat always failed. Reverted to an older copy I still had (27Jun19) and had no problems. Not sure if the regression is in the kernel or elsewhere.
Thanks elyk. I've been testing too and trying to read more into 'findmnt' and how it works with the system. 'findmnt' invokes 'lsblk' and between them they do all the magic parsing, usually without the need for any additional commands or piping. It's a really dynamic command and I'm becoming quietly impressed with it. Thanks for sharing! It really doesn't matter with 'findmnt' if we use block device IDs, partIDs, UUIDs, or MAJ:MIN device values. I did find out that you can do polling with 'findmnt --poll' which is something i'm certainly going to look into at a later date. I think for the purpose I'll be using 'findmnt', your code is quite sufficient and calling on block devices is surely a much more reliable solution than querying 'mount'.

Code:
# Determine status of system 'rootdev' 
if [ -f /tag/README ] ; then 
  # Get 'rootdev' via findmnt if in miniroot installer
  ROOTDEV=$(findmnt --target=/mnt --output=SOURCE --noheadings)
elif [ -b /dev/mmcblk0p2 ]; then
  # Get 'rootdev' via findmnt on installed system
  ROOTDEV=$(findmnt -n -o SOURCE /)
else
  # Assume the default 'rootdev' 
  ROOTDEV='/dev/mmcblk0p3'  
fi
The problem(s) with the USB I'm guessing will be due to the fudging I had to do in order to get onboard bluetooth working on the RPi3 for those who requested it. I'm thinking making this possible has caused problems with other things. I have no problem going back to the way things were. In that event, if users want bluetooth they can install Raspbian and use their patched modules or deploy some common sense and buy a better supported USB bluetooth adapter.

I'll do some more testing on this RPi3 USB issue...
 
Old 08-30-2019, 11:44 AM   #27
Exaga
Member
 
Registered: Nov 2012
Posts: 188

Rep: Reputation: 89
Quote:
Originally Posted by elyk View Post
On a side note, with sarpi3-installer_slackcurrent_29Aug19_sp1.img.xz I was having problems reading from a USB flash drive while in the miniroot and couldn't get my modified package onto the pi. I could list and stat files on the USB drive, but cp and cat always failed. Reverted to an older copy I still had (27Jun19) and had no problems. Not sure if the regression is in the kernel or elsewhere.
It's a filesystem issue with the USB but I haven't tracked down what's causing it. My USB storage device '/dev/sda' is seen by the system but the vfat partition is messed up. However, during Slackware ARM setup when you select "Install from USB stick" it finds the USB device which contains the Slackware ARM source media, it's detected correctly as '/dev/sda1' and installs fine. I believe this issue may have been apparent since July (when I managed to get bluetooth working) and has been overlooked by me because I only test "Install from USB" and don't actually view the files on the USB device - i.e. because I already know what's on it. Currently 'fdisk -l /dev/sda' shows me this...

Code:
root@slackware:~# fdisk -l /dev/sda
Disk /dev/sda: 14.93 GiB, 16005464064 bytes, 31260672 sectors
Disk model: Atom USB Device
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x500a0dff

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sda1       1948285285 3650263507 1701978223 811.6G 6e unknown
/dev/sda2                0          0          0     0B 74 unknown
/dev/sda4         28049408   28049848        441 220.5K  0 Empty

Partition table entries are not in disk order.
I do not know what the hell this means. Although, I'd sure love a USB stick with 811.6Gb capacity. So hmmm. First I'll disable all the bluetooth modules, rebuild the kernel, and work from there.

[EDIOT] plus i did a 'cat /proc/filesystems' check to make sure the filesystems were actually present and correct. and they are.

Last edited by Exaga; 08-30-2019 at 12:10 PM.
 
Old 09-01-2019, 12:33 PM   #28
Exaga
Member
 
Registered: Nov 2012
Posts: 188

Rep: Reputation: 89
Quote:
Originally Posted by elyk View Post
On a side note, with sarpi3-installer_slackcurrent_29Aug19_sp1.img.xz I was having problems reading from a USB flash drive while in the miniroot and couldn't get my modified package onto the pi. I could list and stat files on the USB drive, but cp and cat always failed. Reverted to an older copy I still had (27Jun19) and had no problems. Not sure if the regression is in the kernel or elsewhere.
All SARPi [current] images have been fixed. Things to note...

* On the Raspberry Pi 3 & 3B+ : Bluetooth is not enabled.
* On the Raspberry Pi 4 : Bluetooth is enabled.
 
Old 09-02-2019, 02:30 PM   #29
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 217

Original Poster
Rep: Reputation: 34
Thanks! USB now works again.

Back to the original issue, any thoughts on a kernel-source package or supplement?
 
Old 09-03-2019, 02:39 AM   #30
Exaga
Member
 
Registered: Nov 2012
Posts: 188

Rep: Reputation: 89
Quote:
Originally Posted by elyk View Post
Thanks! USB now works again.

Back to the original issue, any thoughts on a kernel-source package or supplement?
Hmmm...

Quote:
Originally Posted by Exaga View Post
Which files are you referring to that you want to replace in the kernel?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] SARPi out of space in /boot elyk Slackware - ARM 7 08-14-2019 01:16 AM
[SOLVED] Slackware 14.2 Install mkinitrd ERROR: No /lib/modules/4.4.14-smp kernel modules tree found for kernel " 4.4.14-smp" laxware Slackware 4 01-04-2019 12:40 PM
SARPi website new URL - sarpi.co.uk Exaga Slackware - ARM 4 01-28-2018 06:36 PM
SARPi installer and packages using kernel 4.9.61 Exaga Slackware - ARM 1 11-19-2017 02:10 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 12:24 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration