3 TB (GPT), HD problem, impossible to identify a partition
3 TB (GPT), HD problem, impossible to identify a partition
I'm using Slacko 5.5 PAE, the problem is that "puppy universal installer" don't allow me to identify the installation partition correctly. Its shows "unknown" GUIDs as you can see in "puppyproblem.png" and the same name sdaGUID for all partitions is not useful. So I assumed that the same order of partitions (sda1,sda2,sda3 and sda4) are the same order showed in universal installer. WRONG!, I wipe out another linux installation instead (no important data lost). I need some help with this, thanks.
- Attachments
-
- puppyproblem.png
- Gparted, Universal Installer and blkid ouput
- (126.39 KiB) Downloaded 750 times
Seems that the probedisk and disktype commands are giving wrong output .
Could you post their's output, please ?
What i know is that probepart uses blkid output today to support other file systems on cd than iso9660 , which might have been wrongly cut . That output is necessary, too .
Could you post their's output, please ?
Code: Select all
probedisk
probedisk2
disktype /dev/sda
disktype /dev/sda1
disktype /dev/sda2
Code: Select all
probepart
probepart has a bug i think in this line :
should be
example output of mine :
Since Mr Kauler is mostly at home, I think he will detect it self earlier or later .
Code: Select all
FSTYPE="$(blkid -c /dev/$DEVICE | grep "$DEVICE"| awk '{print $NF}' |cut -f2 -d\")"
Code: Select all
FSTYPE=$(blkid -c /dev/null /dev/$DEVICE | grep -w "$DEVICE" | grep -o ' TYPE=".*" | cut -f2 -d'"')
Code: Select all
/dev/sdb1: UUID="5a126d47-065d-4eb6-baf9-dd7701bfe71a" TYPE="ext4" LABEL="boot"
Since Mr Kauler is mostly at home, I think he will detect it self earlier or later .
The size comes usually from
If that file contains more than one line, probably with extra non-numericals, it will screw things .
Code: Select all
cat /sys/block/sda1/size
Output of commands
Hi! I executed the commands, the ouput is in the attached file. Also I made a mistake, PuppyLinux don't ruined a Linux installation, just the GRUB. In fact, when the universal installer finished the copy, the files aren't copied and no error is thrown.
- Attachments
-
- output.tar.gz
- Plain text file with output of commands
- (1.19 KiB) Downloaded 550 times
souliaq,
Thanks for posting the output from the requested commands. They helped to identify the problem. Sorry that it's taken a while to get back to you.
puppyinstaller wasn't quite ready for the "Partition Name . . ." and "Partition GUID . . ." lines that disktype prints out when it encounters a GPT partition map.
The following small change should allow puppyinstaller to correctly identify your partitions.
Please make a backup of /usr/sbin/puppyinstaller, then open the original in a text editor.
Line 475 will currently look like this.
Make two changes to that line:
1. Add a space and -E just after grep.
2. Change '^Partition ' to '^Partition ..?:'
The line should then look like this:
(If you are not comfortable with editing your file, let me know and I'll post a version with the fix included.)
I have done some preliminary testing using your output from "disktype /dev/sda", but don't have a GPT drive, so can't test it thoroughly. So please let us know if this solves the problem for you.
Thanks for posting the output from the requested commands. They helped to identify the problem. Sorry that it's taken a while to get back to you.
puppyinstaller wasn't quite ready for the "Partition Name . . ." and "Partition GUID . . ." lines that disktype prints out when it encounters a GPT partition map.
The following small change should allow puppyinstaller to correctly identify your partitions.
Please make a backup of /usr/sbin/puppyinstaller, then open the original in a text editor.
Line 475 will currently look like this.
Code: Select all
xPARTNUM="`echo "$ONELINE" | grep '^Partition ' | tr -s " " | cut -f 1 -d ':' | cut -f 2 -d " "`"
1. Add a space and -E just after grep.
2. Change '^Partition ' to '^Partition ..?:'
The line should then look like this:
Code: Select all
xPARTNUM="`echo "$ONELINE" | grep -E '^Partition ..?:' | tr -s " " | cut -f 1 -d ':' | cut -f 2 -d " "`"
I have done some preliminary testing using your output from "disktype /dev/sda", but don't have a GPT drive, so can't test it thoroughly. So please let us know if this solves the problem for you.
http://en.wikipedia.org/wiki/GUID_Partition_Tablegcmartin wrote: Unless I'm mistaken, I don't remember disk architecture expanding for system software to consistently and correctly address HDD which violate the original standard
Thanks. Yes, I know this. But, the point I'm sharing is that there is still a bit of confusion in best practices, while most all continue to respect the partitioning that is still afforded in OSes and tools today.rcrsn51 wrote:http://en.wikipedia.org/wiki/GUID_Partition_Tablegcmartin wrote: Unless I'm mistaken, I don't remember disk architecture expanding for system software to consistently and correctly address HDD which violate the original standard
But, I will step back and observe.
RIght now I think the upper limit on partitions on a GPT drive is 128. Five will not be a problem at all. Also GPT usually implements multiple partition tables, so even if one becomes corrupt the drive will continue to operate without any problem.gcmartin wrote:Thanks. Yes, I know this. But, the point I'm sharing is that there is still a bit of confusion in best practices, while most all continue to respect the partitioning that is still afforded in OSes and tools today.rcrsn51 wrote:http://en.wikipedia.org/wiki/GUID_Partition_Tablegcmartin wrote: Unless I'm mistaken, I don't remember disk architecture expanding for system software to consistently and correctly address HDD which violate the original standard
But, I will step back and observe.
Any confusion someone may have regarding this information would be due to their lack of knowledge about GPT and any assumptions they incorrectly mke based on Legacy MBR based disks.
Its always best to research new technologies before assuming how they work and operate.
Prior information shared in my post is "old school". GPT disk have removed the need for EXTENDED partitioning.
I believe there is a better position of the OS, and the supporting utilities, today, than before. This is due to current reports I found today.
Old school (MBR-LBA) is out, "GPT drives and EFI understanding is in."
Old post, by me, is removed to not distract.
I believe there is a better position of the OS, and the supporting utilities, today, than before. This is due to current reports I found today.
Old school (MBR-LBA) is out, "GPT drives and EFI understanding is in."
Old post, by me, is removed to not distract.
GPT Problem SOLVED
The suggestion of npierce works. Thanks. I face another little problem (not big enough to open a new discussion) with Slacko 5.5, the command "poweroff" executed from "urxvt" freezes the machine. Happened in my PC, some netbooks and one Old Amd machine.
- Attachments
-
- PuppyGPT.pdf.gz
- (105.56 KiB) Downloaded 336 times
Re: GPT Problem SOLVED
Try "wmpoweroff".souliaq wrote: with Slacko 5.5, the command "poweroff" executed from "urxvt" freezes the machine.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
npierce, Karl Godt,
Thanks very much, fixes applied.
Blog:
http://bkhome.org/blog2/?viewDetailed=00265
Thanks very much, fixes applied.
Blog:
http://bkhome.org/blog2/?viewDetailed=00265
[url]https://bkhome.org/news/[/url]
npierce, I had no solution that time as the output formatted looks like
and all the other "Partition" lines except for the "Partition 1:" line don't start with ^Partition .
But the loop seems to eliminate the preceding spaces, does not even squeezes them to one space .
Learned something new
Also the grep -E ..? option is something new to me. Was wondering why such " -e, --regexp=PATTERN use PATTERN for matching" did not work for me many times . Now I am able to understand
much better .
Code: Select all
- - - - disktype /dev/sda
--- /dev/sda
Block device, size 2.729 TiB (3000592982016 bytes)
DOS/MBR partition map
Partition 1: 2.000 TiB (2199023255040 bytes, 4294967295 sectors from 1)
Type 0xEE (EFI GPT protective)
GPT partition map, 128 entries
Disk size 2.729 TiB (3000592982016 bytes, 5860533168 sectors)
Disk GUID B50762CF-A490-D244-B71B-4F3B7566A89B
Partition 1: 2.681 TiB (2948162650112 bytes, 5758130176 sectors from 2048)
Type Basic Data (GUID A2A0D0EB-E5B9-3344-87C0-68B6B72699C7)
Partition Name ""
Partition GUID D1F83576-69C7-D34D-8C15-D32626745ED6
Ext4 file system
Volume name "SAYAN_DISK"
UUID 652BDBEA-CB51-492F-B4DD-0EA0517071D6 (DCE, v4)
Last mounted at "/home"
Volume size 2.681 TiB (2948162650112 bytes, 719766272 blocks of 4 KiB)
But the loop seems to eliminate the preceding spaces, does not even squeezes them to one space .
Learned something new
Also the grep -E ..? option is something new to me. Was wondering why such " -e, --regexp=PATTERN use PATTERN for matching" did not work for me many times . Now I am able to understand
http://www.gnu.org/software/grep/manual ... s-ExtendedIn basic regular expressions the meta-characters ‘?’, ‘+’, ‘{’, ‘|’, ‘(’, and ‘)’ lose their special meaning; instead use the backslashed versions ‘\?’, ‘\+’, ‘\{’, ‘\|’, ‘\(’, and ‘\)’.
much better .